On 11/14/05, Mike Duffy <[EMAIL PROTECTED]> wrote: > > Thx Craig. > > --- > In JSF 1.0/1.1 it is pretty much OK, but there are interoperability issues > trying to put <div> elements inside another JSF component. Most of those > issues have been dealt with in JSF 1.2. However, even there you're *much* > better off designing components that render the <div> elements for you, so > you don't have to deal with all the complexity. > --- > > What if your <div> tags are simply being used for the style and layout of > labels and fields within > a form or for the formatting and display of textual information? There are > cases where it's just > a one time deal for a specific app and it is not a custom component. Is it > good practice to use > <div> tags in that instance?
Technically, it'll work fine if you put the <div> elements *outside* rather than *inside* JSF components that try to do their own child management. That's where you run into interop problems. Philosophically, whether this is a "best practice" or not depends on your viewpoint on the issue of whether components should render *all* the markup, or only the dynamic parts. The advantage of the "all" case is you have things like icky browser-dependent code buried in your component renderers instead of in your HTML pages, so you never have to remember to add it to every page. The disadvantage is that you need to have a component available to render the outer <div> element with sufficient flexibility to let you specify the styles you want, and that you might be restricted in choice of tools to develop the pages (although there are lots of tools that know how to deal with JSP custom tags, and therefore JSF component tags, quite gracefully). To me personally, those restrictions don't seem like too high a price to pay for letting the component developers have to worry about all the nitty gritty details, letting me focus on my application design. Mike Craig --- Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > On 11/14/05, Mike Duffy <[EMAIL PROTECTED]> wrote: > > > > > > There is a difference between specifying CSS attributes and creating a > > > liquid CSS design. The > > > later involves a complete separation of style and content where a web > page > > > or JSP becomes a series > > > of <div> tags that flow; a single style sheet can be used to change > the > > > look and feel of the > > > entire application. In a liquid CSS design, tables are only used for > > > displaying tabular data. > > > > > > In the "old days", complex web interfaces were based on an elaborate > > > layout of tables, nested > > > tables and nested tables within nested tables. In liquid CSS design, > the > > > creation of complex web > > > interfaces is much simpler and far more elegant. If you look at a page > > > created with nested tables > > > and another created with liquid CSS design there is a definite > aesthetic > > > difference. Also, > > > because <div>s are easily manipulated, rich interfaces based on AJAX > are > > > much easier to create > > > using <div> tags. > > > > > > In JSF, if the layout is restricted to panel grids and panel groups, > the > > > design will be table > > > based. In theory, the advantage of this approach is that multiple > > > renderers (HTML, Swing, etc.) > > > can make the application functional in different contexts. > > > > > > Not true. You are free to create JSF components that output <div> tags > with > > appropriate style class names, rather than using things like panel > group. > > Indeed, a library of components organized around this metaphor would > likely > > be quite popular. > > > > Don't presume anything about the power of JSF from the limitations of > the > > standard components. They are basically there so you can write "Hello, > > World" apps without having to write a JSF component first. Instead, the > > promise is that you can enable different styles of component development > > (including your "liquid CSS" approach) on top of a standard API that > allows > > us all to share our components with each other. (And a similar "liquid > > JavaScript" approach might offer an even more flexible way to allow > > customization of dynamically rendered HTML without modifying the source > > pages at all.) > > > > In a JSF page, the <f:view> tag can contain <div> and other HTML tags. > So in > > > theory, you could > > > have a JSF application that encompasses liquid CSS design. I'd like to > ask > > > a question of the JSF > > > experts who monitor this list: Is it considered "bad form" to use > <div> > > > tags within the <f:view> > > > tag? > > > > > > In JSF 1.0/1.1 it is pretty much OK, but there are interoperability > issues > > trying to put <div> elements inside another JSF component. Most of those > > issues have been dealt with in JSF 1.2. However, even there you're > *much* > > better off designing components that render the <div> elements for you, > so > > you don't have to deal with all the complexity. > > > > Like many of the subscribers to this list, I have been struggling with > the > > > decision of whether or > > > not to make the jump to JSF. After reading the Geary/Hortstmann book > and > > > many articles > > > (http://www.jamesholmes.com/JavaServerFaces/), and reviewing the work > > > being done on Shale > > > (http://struts.apache.org/shale/), I think it is time. The promise of > JSF > > > is real. > > > > > > Yep :-). > > > > As someone who started out mapping form fields by using CGI and Perl, I > am > > > very thankful for the > > > contributions made by those who created and maintained Struts. I > sincerely > > > hope that Struts can > > > find a good home in the country where it can run and play in the warm > > > sunshine. > > > > > > Mike > > > > > > Craig > > > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
