the problem with the old taglib is that the html output for the table
was very poor: no thead, th, or tbody like any html table should have,
and lots of useless classes to replace the correct html markup.
I just don't want to keep that approach because I think adding a
tableRowHeader css class instead of using a thead is _wrong_, is bad
code.

Moving to the new html output is a matter of seconds, you just need to
open your css and change:
tableRowHeader -> table thead tr
tableCellHeader -> table thead th
tableCell -> table tbody td 
... and few other css class. I think that a good "search and replace
guide" for users that want to move to the new version can be enough to
solve the problem. Also note the new version add useful css classes: the
ones you need to display the sorted column and the sort order (the
arrows), so users are also encoraged to update their css to take
advantage of the new features

fabrizio




-----Original Message-----
From: John York [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 17, 2003 11:24 PM
To: [EMAIL PROTECTED]
Subject: Re: [displaytag-devel] decorator, moving forward, compatibility


This does bring up a good point. The css implementation in display09 is 
quite different from the previous displaytag. My personal opinion on
this 
is that I would like this update to be a simple drop-in replacement for 
the existing tag. If everyone has to update their css, this would be a 
good reason for not upgrading.

Is there anyway to provide the new css approach, which is much better,
but 
also allow the previous css stylesheets to work? I wrote my tag to be
backward 
compatible with the existing stylesheets for this reason.


On Thu, 17 Jul 2003, Fabrizio Giustina wrote:

> 
> Hi all
> it's nice to see the list so busy :)
> 
> My thoughts on latest mails:
> decorators: I agree decorator can be useful also if sometimes they can

> be replaced by the iterator/column body approach. I'm going to 
> transform columnDecorator into an interface, there is no reason to 
> have an abstract class for that (no problem for backward 
> compatibility, since we will have the abstract implementation in the 
> old package)... just wait few minutes for the checkin. TableDecorator 
> can't be an interface, actually, since it need predefined methods for 
> setting objects and pagecontext. I also think decorators are pretty 
> useless if moved out of the column tags, as John proposed, since in 
> that way the totally replicate the functionality of other standard 
> tag/expressions. The idea of having some standard decorator 
> implementation is nice, just they need to be very simple (I'm thinking

> aboud standard date or number decorators): maybe they can be included 
> in a future version,
> 
> About compatibility:
> my implementation is 100% compatible with heprevious version, with 
> only some small differences in the html output -now standard and 
> cleaned- (but you only need to change your css file). Well, I haven't 
> recently tested the old sample site after latest fixes and improvement

> but, if there aren't any bugs, it should work exactly like in the past

> (anyone wants to help in testing and finding bugs?)
> 
> And moving forward...
> since the 09 module is compatible with the previous version I think it

> will be better to release it as a 0.9 version, which fixes old bugs 
> and can be the start for a better 1.0 version (maybe removing some old

> deprecated features?). Actually the code in display09 is complete: I 
> don't plan to add any new feature before a release, but I think before

> releasing it we still need to:
> - complete javadoc: fix and improve ALL the javadocs (and start to 
> have more rigid code checking on checkin in the future, no code 
> accepted without a good javadoc)
> - update and complete documentation/sample site (a good tag reference 
> is missing, anyone wants to take this task?)
> - finish cleaning up the code if still needed (just be sure there 
> aren't things like thrown new RuntimeException() or something like 
> that)
> 
> ... I'd also like to see junit tests, maven build scripts and so on, 
> but this can be done for the future 1.0 version. Just let's try to 
> release a nice bug free 0.9 now. If we decide to go on with the 
> display09 module I can start closing bugs on sourceforge bug tracker, 
> since most of them are already fixed. But we should decide soon on the

> module to keep: me and john can't vote, we are waiting for other 
> developers thoughts & votes
> 
> fabrizio
> 
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single 
> machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual 
> machines at the same time. Free trial click here: 
> http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> displaytag-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/displaytag-devel
> 

-- 
John York
Software Engineer
CareerSite Corporation



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
displaytag-devel mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
displaytag-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel

Reply via email to