Finally after 3 days of googling and a trial-and-error approach I've found out how to overcome the problem with links in a table being stripped from javascript code after an Ajax call (for example for pagination or sorting columns).
The answer to that is a4j:htmlCommandLink (instead of h:commandLink) inside an a4j:form (instead of h:form). Don't ask me why - it's to complex to describe the actual bits and pieces behind some sick concepts in those libraries. The final fact is that h:commandLink ain't working but the a4j:htmlCommandLink is. Period.
Later today I'll attach a working project with the solution. For now you're just going to have to trust me on that one :D
Tuesday, July 14, 2009
Monday, July 13, 2009
RichFaces 3.3.1 Bug
Another day got lost because of some guy trying to make things that work better. This time it's sorting of columns generated from list. All used to work until version 3.3.0.CR1 and then, all of the sudden, it stopped. You can click the damn header all you want and nothing happens.
Components involved: rich:dataTable and rich:columns
O my gosh how I hate those days...
Components involved: rich:dataTable and rich:columns
O my gosh how I hate those days...
Saturday, July 11, 2009
RichFaces + Trinidad = problems
I've been fighting for over 3 days on that so you might wanna listen to the story not to make the same mistake I did.
Some time ago someone decided to use JSF libraries in our project. That same someone decided to use RichFaces (a nice library indeed) and Trinidad (the most terrible piece of code I've ever encountered) in one project.
As the story continued we've been using both of those libraries and it worked quite nice right up to the point where I wanted to use rich:datascroller on a rich:dataTable component containing some action links.
Just so that you know what I'm talking about I'm giving you 2 small projects that show the problem. One without Trinidad configuration (this one is working just fine) and the other one with Trinidad.
example-01-working.zip
example-01-not_working.zip
Basically the Ajax rendering engine from RichFaces is being crushed down with the one from Trinidad. They just hate eachother!
I've never ever expected that 2 libraries might have such a negative impact on eachother! What a waste of time!!!
Some time ago someone decided to use JSF libraries in our project. That same someone decided to use RichFaces (a nice library indeed) and Trinidad (the most terrible piece of code I've ever encountered) in one project.
As the story continued we've been using both of those libraries and it worked quite nice right up to the point where I wanted to use rich:datascroller on a rich:dataTable component containing some action links.
Just so that you know what I'm talking about I'm giving you 2 small projects that show the problem. One without Trinidad configuration (this one is working just fine) and the other one with Trinidad.
example-01-working.zip
example-01-not_working.zip
Basically the Ajax rendering engine from RichFaces is being crushed down with the one from Trinidad. They just hate eachother!
I've never ever expected that 2 libraries might have such a negative impact on eachother! What a waste of time!!!
Thursday, June 25, 2009
JSF + HTML - a sudden divorce
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!
FYI: that works just fine on multiple level of nesting in ASP.NET!
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)?
Subscribe to:
Posts (Atom)