struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@apache.org>
Subject Re: [OT] JSF Interface Design - Is it Truly Limited?
Date Tue, 15 Nov 2005 07:01:04 GMT
On 11/14/05, Mike Duffy <mduffy_lists@yahoo.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message