Now here's a neat one: try mixing HTML and JSF markup in one place. It's all nice and dandy unless there's no html->jsf->html->jsf nesting. In that case the JSF tags are omitted! Here's an explanation why that was the case in JSF 1.1 and that it's supposedly fixed in 1.2 but I've tried it out and it's still not working.
FYI: that works just fine on multiple level of nesting in ASP.NET!
Thursday, June 25, 2009
Friday, June 5, 2009
Trinidad nonsense
Today I've spent almost 6 hours trying to find out the CSS responsible for introducing an 8 pixel top margin for body. The case is even stranger in that the mysterious margin appears only in Internet Explorer. Imagine the 8px disruption in absolute positioning of the elements on the page - it just looks bad.
Finally I've found the problem: Trinidad introduces some stylesheets that do exactly that.
Well it wouldn't be much of an issue if it were not for the fact that this damn CSS is included as the last thing in the head!!! So you can do anything you like - body will always have this damn 8 pixels margin in IE only no matter what.
I'd like to find out who the butthead that invented this piece of sh** is. I mean, come on!!! Someone must have been stoned to do this kind of thing!
The worst thing is I have not damn idea how to fix it other than using some sort of on-load method to correct the CSS for body element. jQuery works well, but this is the ugliest hack I've ever come across.
Finally I've found the problem: Trinidad introduces some stylesheets that do exactly that.
Well it wouldn't be much of an issue if it were not for the fact that this damn CSS is included as the last thing in the head!!! So you can do anything you like - body will always have this damn 8 pixels margin in IE only no matter what.
I'd like to find out who the butthead that invented this piece of sh** is. I mean, come on!!! Someone must have been stoned to do this kind of thing!
The worst thing is I have not damn idea how to fix it other than using some sort of on-load method to correct the CSS for body element. jQuery works well, but this is the ugliest hack I've ever come across.
Tuesday, May 12, 2009
JavaScript and Facelets
Did you know that you're not allowed to use the full syntax of JavaScript language with Facelets? Well, I didn't and it took me over 4 hours to find that out. Let me explain:
Here's a simple JS function that will cause the rendering engine swallow it's own tongue and spit a nasty error message:
First of all the < and > are not valid characters in XML so they are not valid in Facelets as well. And if you substitute them by < it will be rendered as < which makes the usage of < character impossible.
The same situation is with > sign as well as with && operator.
Of course you might say that my doSomething function makes no sense - it's for educational purposes only!
May the spirits protect us from Facelets!
Here's a simple JS function that will cause the rendering engine swallow it's own tongue and spit a nasty error message:
<script>
function doSomething(items) {
if(items.length > 0 && items.length < 5)
return;
}
</script>
First of all the < and > are not valid characters in XML so they are not valid in Facelets as well. And if you substitute them by < it will be rendered as < which makes the usage of < character impossible.
The same situation is with > sign as well as with && operator.
Of course you might say that my doSomething function makes no sense - it's for educational purposes only!
May the spirits protect us from Facelets!
Using Maven's Apache MyFaces archetype with GlassFish v3
I've faced a simple task to create a component that will render a recursive unordered list that can be later on turned into an accordion. Nothing really fancy.
Since there's no such component that I know of to do the rendering in the way I want it to I've decided to create my own component.
Using Maven I've created a new project from MyFaces archetype available in the default Maven repository. Armed with an example application I started my work.
The shock came right after running the generated app for the first time. Here's a snippet of the jsp page:
Using NetBeans (the only freely available IDE that makes sense for Java development) I've started GlassFish v3 and deployed my newly generated application to the server.
The "Run" option on project has opened Firefox with the right address and everything looked OK. So I thought: let's take a look at the generated Html before I start adding something to it. And that was the moment when the fun begun!
The generated HTML has the following structure:
1. Form (as a top-level element) with all the controls
2. Html with Head and Body containing some JavaScript code and nothing more.
Can someone explain to me the reason it is so difficult to produce some proper output even from the simplest application??? Is this something you'd put your money into (I mean like more than one dollar of course)?
Since there's no such component that I know of to do the rendering in the way I want it to I've decided to create my own component.
Using Maven I've created a new project from MyFaces archetype available in the default Maven repository. Armed with an example application I started my work.
The shock came right after running the generated app for the first time. Here's a snippet of the jsp page:
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<html>
<head>
<title>Hello World</title>
</head>
<body>
<f:view>
<h:form id="mainForm">
<h:panelGrid columns="2">
<h:outputLabel for="name"
value="Please enter your name" />
<h:inputText id="name"
value="#{helloWorld.name}"
required="true"/>
<h:commandButton value="Press me"
action="#{helloWorld.send}"/>
<h:messages showDetail="true"
showSummary="false"/>
</h:panelGrid>
</h:form>
</f:view>
</body>
</html>
Using NetBeans (the only freely available IDE that makes sense for Java development) I've started GlassFish v3 and deployed my newly generated application to the server.
The "Run" option on project has opened Firefox with the right address and everything looked OK. So I thought: let's take a look at the generated Html before I start adding something to it. And that was the moment when the fun begun!
The generated HTML has the following structure:
1. Form (as a top-level element) with all the controls
2. Html with Head and Body containing some JavaScript code and nothing more.
Can someone explain to me the reason it is so difficult to produce some proper output even from the simplest application??? Is this something you'd put your money into (I mean like more than one dollar of course)?
Monday, May 11, 2009
...because it's designer friendly
Here's just one quick note that I just couldn't live without sharing.
There's an opinion that it is better to use a more declarative approach to web development (like JSF/Facelets does) because it is easier and more comfortable for the web designers to interact with the page design.
Web Designers are NOT developers! Much less JavaEE developers knowledgeable in JSF technologies. Get over it! NetBeans, Eclipse - those are Developer tools - not designers'! A designer prefers Photoshop for graphics (oh wait - there's no such thing in Eclipse, NetBeans nor in Idea like advanced image editor) and Expression Web or Dreamweaver (again, no viable counterpart in any of the IDEs).
And now for the most shocking part:
Designers don't speak JSF/Facelets nor any of the JSF frameworks like RichFaces or IceFaces. They speak HTML, CSS, possibly JavaScript too (if you're lucky!). For them a div is a div, a span is a span and a a-href is an a-href.
And I distinctly remember someone saying that it is easier to get designers to contribute to the project if you use Java Server Faces...
There's an opinion that it is better to use a more declarative approach to web development (like JSF/Facelets does) because it is easier and more comfortable for the web designers to interact with the page design.
Web Designers are NOT developers! Much less JavaEE developers knowledgeable in JSF technologies. Get over it! NetBeans, Eclipse - those are Developer tools - not designers'! A designer prefers Photoshop for graphics (oh wait - there's no such thing in Eclipse, NetBeans nor in Idea like advanced image editor) and Expression Web or Dreamweaver (again, no viable counterpart in any of the IDEs).
And now for the most shocking part:
Designers don't speak JSF/Facelets nor any of the JSF frameworks like RichFaces or IceFaces. They speak HTML, CSS, possibly JavaScript too (if you're lucky!). For them a div is a div, a span is a span and a a-href is an a-href.
And I distinctly remember someone saying that it is easier to get designers to contribute to the project if you use Java Server Faces...
Ghosts in the browser
It's not a bug - it's a feature
Did you know that you're not where you are? I mean virtually of course. Confused? Read on...
Let's have a simple example: 2 simple views (or pages or however you'd like to call them). One that asks for your name and the other one that says that you're the master and this kind of things. A simple "Hello, world!" application. Nothing fancy.
Now let's assume the obvious which is: you're writing it using Java Server Faces. It's good for everything so why shouldn't it be good for a Hello, world! application?
So we have it, one edit (h:inputText, for whatever reason) and a button (h:commandButton, again like it couldn't be simply a button... nevermind) and we have the next page that shows your name with a nice greeting (using h:outputText for whatever reason, like text nodes were smelly or something... nevermind). Of course we have all the necessary bits and pieces there: a bean with sayHello method, navigation cases set up properly, all the entries in web.xml are there - we're good to go!
Now let's run our glorious application.
1. We're at the start page that kindly asks us to enter our name into the box. Well, we're not that open to mind control so we enter something like "Harry Potter" and click the fancy button that's on the same page.
2. Now we're on another page, this time it's the page saying, that "Harry Potter is most welcome" and "that you can click the back link to get back".
But wait! Have you noticed the address bar? Whatta heck?! It is still pointing to the page where we've had the opportunity to enter our name. We think "something is seriously wrong with our application". But in fact it's not our application that's wrong - it's just how JSF works.
It's not a bug - it's a feature :D And you can't do anything with it. Get over it! Don't look at the address bar - there's nothing of interest to you.
Did you know that you're not where you are? I mean virtually of course. Confused? Read on...
Let's have a simple example: 2 simple views (or pages or however you'd like to call them). One that asks for your name and the other one that says that you're the master and this kind of things. A simple "Hello, world!" application. Nothing fancy.
Now let's assume the obvious which is: you're writing it using Java Server Faces. It's good for everything so why shouldn't it be good for a Hello, world! application?
So we have it, one edit (h:inputText, for whatever reason) and a button (h:commandButton, again like it couldn't be simply a button... nevermind) and we have the next page that shows your name with a nice greeting (using h:outputText for whatever reason, like text nodes were smelly or something... nevermind). Of course we have all the necessary bits and pieces there: a bean with sayHello method, navigation cases set up properly, all the entries in web.xml are there - we're good to go!
Now let's run our glorious application.
1. We're at the start page that kindly asks us to enter our name into the box. Well, we're not that open to mind control so we enter something like "Harry Potter" and click the fancy button that's on the same page.
2. Now we're on another page, this time it's the page saying, that "Harry Potter is most welcome" and "that you can click the back link to get back".
But wait! Have you noticed the address bar? Whatta heck?! It is still pointing to the page where we've had the opportunity to enter our name. We think "something is seriously wrong with our application". But in fact it's not our application that's wrong - it's just how JSF works.
It's not a bug - it's a feature :D And you can't do anything with it. Get over it! Don't look at the address bar - there's nothing of interest to you.
Comments are not comments unless they are comments
The concept of comments is clear to everyone, so it would seem. We developers use them all the time to comment-out code that we'd like to skip temporarily, to better document our intentions. Comments are just plain old descriptions, inactive elements in the code. So it would seem...
Apparently the creators of Facelets didn't think that this is the case. Once you comment out a piece of code (again, for whatever reason) it does not mean it is actually not running!
Some one brave enough decided that the default behavior of comments should be the one of the ordinary template, meaning all the elements that are active (so to speak) are still running! All the references to beans, all the references to resource bundles and what have you are still being used to produce a nice comment!!!
There's of course an option to turn this insane behavior off (facelets.SKIP_COMMENTS) but the default behavior might give you a nice head spin.
Apparently the creators of Facelets didn't think that this is the case. Once you comment out a piece of code (again, for whatever reason) it does not mean it is actually not running!
Some one brave enough decided that the default behavior of comments should be the one of the ordinary template, meaning all the elements that are active (so to speak) are still running! All the references to beans, all the references to resource bundles and what have you are still being used to produce a nice comment!!!
There's of course an option to turn this insane behavior off (facelets.SKIP_COMMENTS) but the default behavior might give you a nice head spin.
Subscribe to:
Posts (Atom)