struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pc leung <pingcheu...@gmail.com>
Subject Re: [OT] JSF Interface Design - Is it Truly Limited?
Date Mon, 14 Nov 2005 09:32:29 GMT
 Ronald

I am also thinking of switching to JSF. Do you use Shale, MyFaces or Sun JSF?
Any reasons your company starts to use JSF as I am standing at the
cross road of Struts and JSF?

Thanks



On 11/14/05, Ronald Holshausen <uglyog@gmail.com> wrote:
> Hi Mike,
>
> I have switched from struts to JSF for our companies product
> development, as I can say that JSF is totally CSS oriented. Each
> control has a CSS class as a property, and a lot of the tomahawk
> components provide their own base CSS classes by default (have a look
> at the tabbed pane from tomahawk as an example).
>
> I agree with you about the mock-ups. With our development, the process
> starts with the graphic artists who do the demos and new product
> concepts in pure html and CSS with tools like Dreamweaver, etc. Then
> the developers convert the HTML to JSPs and write the backing java.
> This works the same with struts and JSF.
>
> Have a look at the clay component from shale, as this supports this
> type of development process more fully as you could then use the
> generated HTML from the graphic artists directly, just add some ids
> much like Tapestry does.
>
> On 12/11/05, Gary VanMatre <gvanmatre@comcast.net> wrote:
> > > I know there are some leading edge JSF and Shale gurus who monitor this list.
I
> > > have a basic
> > > question: Can rich web application interfaces be created in JSF?
> > >
> > > I've looked at MyFaces and Tomahawk (http://myfaces.apache.org/). The source
> > > code that can be
> > > found in the examples at http://www.irian.at/myfaces/home.jsf is perplexing.
I
> > > see data tables,
> > > panel groups, and panel grids for the page layout. I do not see standards based
> > > CSS design. I
> > > don't see how you could create rich web application interfaces with externalized
> > > styles using JSF
> > > components.
> > >
> > > I know the concept is that JSF components can be "rendered" for different
> > > viewing devices;
> > > however, I'm not sure the creators of JSF really thought through the process
of
> > > how most web
> > > applications are created. I think the usual case is that a mock up of the web
> > > interface is
> > > created by marketing execs and web designers, then that mock up is "wired"
by
> > > software engineers
> > > (in our case we use Struts for the wiring). CSS design is very advanced (see:
> > > http://www.csszengarden.com/). It is unrealistic to think companies are going
> > > to retrain their
> > > web designers on a new technology that is less capable then the one they are
> > > currently using.
> > >
> > > As a specific example, the use of such tags in JSF as,
> > > "
> > " is
> > > horrible.
> > >
> > > I think JSF has missed the mark. Rather than tossing out Struts I think Sun
> > > should have enhanced
> > > Struts by creating a simple process for plugging in web components (perhaps
some
> > > sort of enhanced
> > > Tiles strategy) and they should have also enhanced Struts by adding a better
> > > page flow process
> > > (similar to Spring WebFlow).
> > >
> >
> > I think that if you take a better look at JSF, you might see Struts, Spring and
a reusable visual component framework.  To see this you have to look beyond the basic semantics.
 So, maybe a forward is called a navigation rule and validation is component based verses
form based.
> >
> > I've always seen Struts as building blocks for the rest of the application.  It
provides the foundation, a starting point.  Each shop seems to pick and choose different extension
points to exploit.
> > JSF provides the same model where extension points in the framework are configured
via a configuration file.  The framework guts can be swapped with a side of a configuration
files.  JSF expands on this by providing an API for building visual components that have characteristics
of event oriented programming in a request response architecture.  The component API is a
starting point.
> >
> > The fact that the reference implementation delivers a number of vanilla components
is a strength but maybe a weakness.  The component API should be seen as building blocks and
not as absolute offering.  I don't think that Struts would have lead as many projects to success
if the developers could not have seen how to take advantage of is swappable parts.
> >
> > > One of the most promising projects for web application frameworks is a project
> > > named, "Clarity"
> > > (http://www.jsfcentral.com/listings/A6020?link). The goal of this project is
to
> > > consolidate and
> > > enhance existing frameworks. I hope this is the path to nirvana.
> > >
> > > I like the JSF concept of pluggable components. My major problem with JSF is
> > > the design strategy
> > > that states an application is a collection of components and these components
> > > have renderers for
> > > different devices. I suppose that you could try to wrap CSS design around
> > > "" tags if you
> > > are creating a web application, but this seems contrary to the JSF model.
> > >
> > > Please share some guiding thoughts. Especially, if you have a link to some
cool
> > > example pages
> > > created with JSF, I'd like to see them.
> > >
> > You might take a look at the Shale "rolodex" usecases.  You will see some fun CSS
action delivered using a JSF view.  It's all done using only two custom components and  a
few JSF extension points, the rest is vanilla RI.
> > http://svn.apache.org/builds/struts/nightly/struts-shale/
> >
> > > Thx.
> > >
> > > Mike
> > >
> > Gary
> > >
> > >
> > > __________________________________
> > > Yahoo! FareChase: Search multiple travel sites in one click.
> > > http://farechase.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message