struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Java Server Faces stage?
Date Sat, 07 Dec 2002 02:34:42 GMT


On Fri, 6 Dec 2002, Adolfo Miguelez wrote:

> Date: Fri, 06 Dec 2002 16:22:47 +0000
> From: Adolfo Miguelez <pelly69@hotmail.com>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> Subject: Re: Java Server Faces stage?
>
> I have been looking at glance the JSF Tutorial, at my idea idea, is that
> Craig, do the things as they should be done. I mean, I large large thought,
> planning, ordering ideas and short implementation. Sounds goods.
>
> Just a set of very well ordered ideas rather that I huge development.
> Good!!!!.
>
> However, there is a point where I got worried: it seems (correct me, please,
> if I am mistaking) that Craig policy is back in server the components
> running in the client. In Struts, ActionForms back the info introduced in
> the HTML forms, in JSF, it goes beyond and a whole component behaviour
> (events, value, validation) is backed in server, e.g. drown-down lists are
> backed by an UISelectOne class.
>

In simple terms, yes -- UIComponents in JavaServer Faces provide the same
"server side backing" storage for UI state that ActionForms do for Struts
apps.  However, they are actually somewhat more powerful (for example,
you'll be able to choose from different approaches on *how* the state is
saved and restored), and do not require you to encapsulate all your state
into a single bean the way that Struts does.

> Despite it seems a priori, at nice approach, it makes me wonder, if would it
> not be a strong burden for the server to respond every event in every client
> with a new HTML page?
>

JavaServer Faces is primarily a *framework* for building UI components.
As such, it needs to accomodate a large variety of client devices (HTML
browsers are by no means the only target) and capabilities.  Not all of
those client devices have much in the way of client side scripting support
(consider a browser with JavaScript turned off).

Should we design JSF to *require* client side scripting?  No, that would
disenfranchise a pretty large population of potential users.  Should we
design JSF so that it does not take advantage of powerful clients?  That
doesn't make sense either.

Consider the creation of a complex component like a tree control where you
can expand and contract the nodes.  In JSF terminology, clicking on the
node to expand or contract a branch would usually be modelled as a request
event.  It is entirely legal to build a JavaServer Faces version of a tree
control in any of the following ways:

* HTML only, where the request events are handled on the server side

  (for amusement, you might want to look at the Admin Application of
  Tomcat 4.1, which is based on Struts and includes a tree control that
  works this way).

* DHTML+JavaScript where the request events are handled on the
  client side (so node expands and contracts are totally local)

* Java Applet, where the request events are handled on the
  client side

* Lots of other ways I haven't thought of yet.

Note that your application logic doesn't care about how this is
implemented -- all it cares about is configuring the available tree nodes.
It's never bothered by request events, even if they *are* sent to the
server.

JavaServer Faces has to support server side request events in order to
cover the entire universe of possible target devices.  But it's up to the
component designer, and the RenderKit implementer, to decide how a
UISelectOne or UISelectMany will *actually* get rendered.

> Sorry if this question is stupid in some way since I am still understanding
> the JSF philosophy.
>

It's not a stupid question.  It's a pretty good illustration of the
tradeoffs that go into creating a comprehensive framework like Faces.

> Thanks in advance,
>
> Adolfo.

Craig


>
>
>
>
> >From: "Craig R. McClanahan" <craigmcc@apache.org>
> >Reply-To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> >To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> >Subject: Re: Java Server Faces stage?
> >Date: Thu, 5 Dec 2002 18:54:26 -0800 (PST)
> >
> >
> >
> >On Thu, 5 Dec 2002, Adolfo Miguelez wrote:
> >
> > > Date: Thu, 05 Dec 2002 12:13:00 +0000
> > > From: Adolfo Miguelez <pelly69@hotmail.com>
> > > Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> > > To: struts-user@jakarta.apache.org
> > > Subject: Java Server Faces stage?
> > >
> > > Hi All,
> > >
> > > last days I have seen, the availability of the new technology Java
> >Server
> > > Faces. It seems a really promissing technology.
> > >
> > > I have discovered recently that there is already a reference
> >implementation
> > > available apart from the specs.
> > >
> > > I would like to know if if is currently possible to migrate our JSP
> >projects
> > > to JSF.
> > >
> > > Any practical experience to share would be appreciated,
> > >
> >
> >It would be possible, but it's just a little early at this point.
> >
> >When the next release of JavaServer Faces is available (sorry, can't tell
> >you when at this point :-), I plan to make available an integration
> >library that makes integration with Struts very easy.
> >
> >I wrote a message to the mailing list several months ago about the
> >strategic relationship between Struts and JSF (and JSTL as well) -- check
> >the mailing list archives for a subject line that included "Forward
> >Looking".
> >
> > > thanks in advance,
> > >
> > > Adolfo.
> > >
> >
> >Craig
> >
> >
> >
> >--
> >To unsubscribe, e-mail:
> ><mailto:struts-user-unsubscribe@jakarta.apache.org>
> >For additional commands, e-mail:
> ><mailto:struts-user-help@jakarta.apache.org>
>
>
> _________________________________________________________________
> Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
>
>
> --
> To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>
>
>



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


Mime
View raw message