Hookom, Jacob wrote:

You threw me for a loop with replying so late to that email--

It just comes down to giving the developer the ability to scale their own
layers with JSF like you said below.  If I want ActionForms, then I will
have JSF update request/session scope beans that are only for the view.  If
I want something simpler, then I can have JSF update my business beans
themselves.

JSP->View Logic/Beans->Business Logic/Beans
JSP->Business Logic/Beans

PS: Craig, did you get my email to Ed Burns and yourself about a new, faster
JSF-specific EL implementation for JSF RI?



I did indeed. I'm sure Ed will look at it next week, after Sun returns to operation from our shutdown this week.

Best Regards,
Jacob Hookom



Craig


-----Original Message-----
From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 08, 2004 7:35 PM
To: Struts Users Mailing List
Subject: Re: Theoretical debate


Hookom, Jacob wrote:



Look at JSF, do you have actions? No, JSF just updates your POJO beans and
calls methods on them.  Why have an ActionForm or have to create all of
these Actions that are simply getter/setter adapters?  Please don't be too
quick to retort to my supposed anti-struts mindset, but there are other
frameworks out there that allow direct interaction with my business objects
and don't require a heck of a lot of framework specific coding.





(Coming into this discussion late, but figured that my experience on both the Struts and JSF side of things might provide some illuminating food for thought :-)

It's instructive, first, to go back to the beginning of Struts development (just over four years ago), and recall why an ActionForm exists in the first place. The only reason we created that abstraction was to deal with some pesky real world problems in designing webapps ... primarily dealing with conversion (where we really punted ... see below), validation, and little things like maintaining the state of checkboxes. Because Struts doesn't have any "user interface component" concept, dealing with those things had to go somewhere -- and a common abstraction at least made it easy to understand.

Therefore, the recommended design pattern for a Struts based app becomes:

- An ActionForm per input <form>, normally with
 String-based properties (so you can redisplay
 invalid input the way users expect you to).

- A set of validation rules that are applied for you
 on the server side, and optionally also on the
 client side.

- If a validation error occurs, Struts takes care
 of redisplaying the page (with error messages)

- If validation succeeds,  the application Action
 is responsibe for performing conversions of the
 String valued things in the ActionForm to match
 the underlying model data types, typically by
 copying them in to DTO/VO type objects and
 passing them to business logic (although, as others
 have pointed out, lots of Struts developers have
 skipped this extra layer).

With JSF, the component model takes care of all the responsibilities that Struts uses an ActionForm for, so you don't need one any more. Indeed, I anticipate people will choose one or more (they aren't mutually exclusive) of at least three different styles for building JSF-based webapps:

(1) You can bind individual *components* to backing bean properties,
    similar to how ASP.Net "code behind files" work.  This will
    be most comfortable to VB developers, and is useful when
    you need to programmatically modify component properties.

(2) You can bind component *values* directly to properties in your
    backing bean, and then provide the business logic as action methods
    in the same class.  Because the components take care of conversion,
    you're free to use model-oriented data types for such properties,
    so you don't need to worry about explicit conversion any more.
    This style will appear to Struts developers like a combination of an
    Action and an ActionForm in the same class, and will also appeal to
    the crowd that likes O-O encapsulation :-).

(3) You can bind component *values* directly to properties on a VO/DTO
object, and bind action events to methods on a separate bean that will
either perform the logic directly or delegate to a business logic class.
This style will feel more like traditional Struts separated ActionForm and
Action classes, but the Action won't have as much to do. It's also a great
way to build a webapp on top of existing application infrastructure that
provides resuabe VO/DTO and business logic classes already.


I believe that all three approaches are valid -- which one you take for a particular application function depends on your use case for that function. You don't have to be exclusive, either. Combine them where it makes sense.

Craig McClanahan


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to