struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V. Cekvenich" <v...@users.sourceforge.net>
Subject Re: Java Server Faces stage?
Date Sat, 07 Dec 2002 14:08:59 GMT
Summary: I am considering bypassing JSF for XFORMS.

Details:
Adolfo, I have sent several longish feedback's to JCP/EG, and mostly 
gotten wait till next release. But I do not see them accepting input so 
far, true to the reputation of JCP. After calling Ms. Cleo, here is yet 
another opinion on JSF, with all respects due Craig (my guess is that 
even he can't get them to change):

1. The reference implementation of JSF, and most that follow, it will 
likely be non- scalable, and of no use to sites with large loads. As 
anyone can read the spec., it tends to do most of the "rich GUI" 
processing on the server, not on the browser.  (Because it might not use 
a browser?)

2. JSF seems design seems design by committee, where no one said no. It 
is designed for many exceptions.
- It does HTTP and other protocols.
- It does HTML and other "devices", like the long dead WAP.
Thus, I expect it to be not particularly good at any. The design should 
have been design for the rule, not the exception, so it should have been 
a HTTP/HTML design. Example where they made it complex is this state 
management stuff. If you work mostly on HTTP/HTML, there is a more 
standard way of doing things .* Same as EJB is distributed and cached 
and  local and persistence and does not use SQL, but EQL.
As people in project management know, to succeeds on a project, you must 
be able to say no. (or read about it at why projects succeed at 
softwarereality.com) JSF is sort of like a design for a submarine that 
is also a lawn mower.
State can be managed just fine as is.
See links at: http://jibbering.com/2002/4/httprequest.html

3. http://asp.net/webmatrix/default.aspx?tabindex=4&tabid=46
I asked JCP/EG to have a real client that has production web app that 
have rich GUI be involved in some way. MS I think is closer to being 
useful, yet again. My guess is that EG is more focused on technology for 
the sake of technology.


4. Multiple beans on a page? That is not MVC. That means in the view you 
are creating master detail relationships. In Struts, you have a single 
form bean. That means that you can create a business bean with master 
detail processing, or many to many processing and unit test it and reuse 
it elsewhere, with no code in the view. (you do this by overriding 
iterators next, and CRUD events in the bean). So not very MVC. Also, it 
talks a bit about expression language instead of DAO, making it harder 
to overload/ovreride, which IMO is not OO, thus not productive or reusable.


5. The RI is not open source. Enough said.

Right now, Ms. Cleo thinks JSF will be a flash in a pan, and will go the 
way of EJB.  So I will refer baseBeans and MVC clients to stick with 
JavaScript for now. But I will demo JSF features (and bad Sides) at all 
my public and private training's.
(2 coming up in DC and NYC, and also at each of the training everyone 
gets a FREE AUTOGRAPHED book on Struts by Husted).

So what does Ms. Cleo tell me will win? .NET?

Ever heard of W3.org standards?
http://www.w3.org/2002/11/xforms-pressrelease.html.en
and one plug in
	 http://www.formsplayer.com/introduction.htm

As J2EE vendors jump on, see attached and links at:
http://www.novell.com/xforms (by SilverStream)
* Attached shows drag and drop on XFORMS.
I hope you see how this is much more competitive with .NET.

Can you do JSF with XFORMS? Not sure, it appears that you would then 
process 2 sets of events.

It takes a lot of change management to switch technologies, and JSF 
might be in and out, not worth learning. Keep you eye on XFORMS.


.V
(917) 345 1445

ps: for a preview of new baseBeans.com site see proj.com.
It has XML content in DB, and uses JSTL:X tranform to render, among 
other cool things.








Craig R. McClanahan wrote:
> 
> 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>
>>
>>


Mime
View raw message