(Yet Another) Wicket Misadventure...

Posted Wed, 22/07/2009 - 16:15 by adi
, ,

What, in Grimm's name, can be the cause for Wicket to change its output?

 

Example:

    Yesterday, the HTML output was:

              <table><thead></thead><tbodies></tbodies><tfoot></tfoot>

 

    Today, the HTML output is:         

              <table><thead></thead><tfoot></tfoot><tbodies></tbodies>

 

What? When? Why?

 

(Hints: Built with almighty maven, same wicket version, other dependencies might be different due to new 3rd party libs)

 

Please help... we're slicing wrists here...

‹ Is there a way to see what the values of the arguments that are sent into a method in Java? (source or bytecode) Online pre-configuration of JEE web applications ›

Comments

by lior.kanfi - 22/07/2009 - 16:28

Some how, a usage of internal Collection which is ordered by object id's?

by ittayd - 22/07/2009 - 16:58

what does the template html look like? what is the component that is associated with the containing markup?

in general, wicket (more accurately, wicket components) does not render markup. it simply takes the markup from the template and substitutes values in it.

by adi - 22/07/2009 - 17:26

It's a sub-class of DataTable. The markup is obviously <table ... />

The content is being filled by Wicket.



I've got the same feeling as Lior's... I truly hope this isn't a transitive dependency issue...



by ittayd - 22/07/2009 - 17:57

does the subclass have its own associated markup?

if not, then maybe a change of wicket version?

DataTable's associated markup has <thead>...<tfoot>...<tbody>, so that is the order they should be output. wicket does not reorder elements in the markup and DataTable doesn't either.



by adi - 22/07/2009 - 18:39

1. The subclass' associated markup doesn't interfere with the DataTable's work. It does, however, add some of it's own.

2. The wicket version is the same...

3. It's true! HTML tables do render in this order (<thead>...<tfoot>...<tbody>). I wrote tbodies as a hint for accessing the content from JavaScript (sorry).

4. The only changes I can think of are: I) Some wicket dependency was changed (due to maven's resolving policy). II) The application that was used to be deployed on Jetty is now running on Tomcat.


Wicket depends on commons-collections. I wonder if a change of version might cause Wicket to loose order of components collections before it prints their markup out...






by ittayd - 22/07/2009 - 18:39

maybe this is the reason: https://issues.apache.org/jira/browse/WICKET-1496?

it was opened for wicket 1.3.3 and fixed in 1.3.5



by adi - 22/07/2009 - 18:48

I'll need to take a closer look at the deployed versions...

You see, the problem is that the old (1.3.3) and bad output (head...body...foot) is something the developer who wrote the code was relying on...

Now, when a well formed html is printed, the JavaScript code fails (he did a terrible work here...).



I think you solved it. I bet somehow we get a newer version of wicket at deployment, and that this is the reason for the whole mess.



I'll get back to you as soon as I have the answer.


Thanks (!!!)







by adi - 22/07/2009 - 18:56

That's it! You've got it right!


A dependency on wicket-datetime (since V1.3.4) was added with V1.3.6. They need it here for the YUI date-picker.



Thanks for the help!