-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: Friday, December 19, 2003 11:00 AM
To: Struts Developers List
Subject: RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Quoting [EMAIL PROTECTED]:
> We have a solution for dynamic page content that is component based.
I
> wouldn't say that it stands up to JSF but it's similar in concept.
The
> content of the page is defined using xml metadata.
>
> However, I suppose that you could argue, why not use JSF? I would be
> interested in hearing what advantage you would have using struts with
JSF
> when JSF handles both the view layer and controller?
>
>>Fair question. In the long run, we (Struts) are definitely going to
>>have to "compete" with this combination.
>>The easiest way is to focus on features that are not present in JSF --
>>one approach would be to build on top of the JSF controller
>>infrastructure.
>>Besides the UI components, there are some very useful foundational
>>things there (such as managed beans, which generalize the way that
>>Struts auto-creates form beans on demand, fine-grained navigation
rules, >>and the ability to programmatically evaluate EL-ish
expressions, >>including the ability to plug in new evaluators for the
"." operator) >>that would be nice to use in a controller tier.
I have been struggling to correlate the notion of a struts formbean with a
jsf UI component. Under struts, a single action can be associated with
only one formbean. If the form is a composition of many components,
should each component have its own "formbean"? It sounds as each jsf
component would pull values on its own behalf from the request parameters
thru a converter.
To achieve visual component reuse, it sounds like jsf introduces the
notion of a client id. We have used an underscore as our component
delimiter because the beanutils handles the "." for nested components.
It seems that if you had a single form bean to map to a graph of UI
components, the form bean might get kind of ugly.
<form-bean name="AboutForm" type="com.rustts.action.DynaRusttsForm" >
<form-property
name="aboutForm_BorderLayout_west_dateWidget_selDate"
type="java.lang.String"/>
<form-property
name="aboutForm_BorderLayout_center_calendarWidget_GridLayout_B0_yearWidget_year"
type="java.lang.String"/>
<form-property
name="aboutForm_BorderLayout_center_calendarWidget_GridLayout_A0_monthWidget_month"
type="java.lang.String"/>
</form-bean>
It would be nice if the behavior of the formbean to an aciton could also
be associated with a UI component.
It sounds like the struts chains will be similar to the jsf component
tree? Could a chain command be associated with a individual formbean and
a command be corrolated to a UI component?
> Consider the following DTD and XML snippet:
>
>
> <!ELEMENT display-element (attribute*, set-property*)>
> <!ATTLIST display-element
> displayElementId CDATA #REQUIRED
> type %DisplayElementType; #IMPLIED
> jspName CDATA #IMPLIED
> extends CDATA #IMPLIED
> modelClassname CDATA #IMPLIED
> roles CDATA #IMPLIED
> useContainerNaming %Boolean; #IMPLIED
> >
>
> <!ELEMENT set-property (#PCDATA)>
> <!ATTLIST set-property
> name CDATA #REQUIRED
> value CDATA #REQUIRED
> >
>
> <!ELEMENT attribute (set-property*)>
> <!ATTLIST attribute
> attName CDATA #IMPLIED
> displayName CDATA #IMPLIED
> displayElementId CDATA #REQUIRED
> requiredField %Boolean; #IMPLIED
> sequence CDATA #REQUIRED
> roles CDATA #IMPLIED
> useContainerNaming %Boolean; #IMPLIED
> >
>
> This is an example of building a change password page. The
> "changePasswdForm" is the root "component".
>
> <!-- The "crudForm" definition serves as a base layout for an add or
> update page -->
>
> <display-element displayElementId="crudForm" >
> <!-- will always be placed on the bottom of the form, sequence=99 -->
> <attribute displayElementId="Message"
> displayName="message.required.legend" sequence="99"/>
> </display-element>
>
>
> <!-- The "changePasswdForm" definition only allows you to change your
> password. It inherits the required message legend from
> the crudForm -->
>
> <display-element displayElementId="changePasswdForm"
extends="crudForm" >
>
> <!-- include the user password fields also used by the addUserWidget
-->
> <attribute displayElementId="userPasswdWidget" sequence="1"/>
>
> <!-- The rest of the user information is cached in the html form
> allowing the update handler to be reused for the change password
> page -->
> <attribute attName="cmManagerId" displayElementId="Text"
sequence="10">
> <set-property name="isHidden" value="true"/>
> </attribute>
>
> <attribute attName="cmFname" displayElementId="Text" sequence="11">
> <set-property name="isHidden" value="true"/>
> </attribute>
>
> <attribute attName="cmMname" displayElementId="Text" sequence="12">
> <set-property name="isHidden" value="true"/>
> </attribute>
>
> <attribute attName="cmLname" displayElementId="Text" sequence="13">
> <set-property name="isHidden" value="true"/>
> </attribute>
>
> </display-element>
>
>
>
> <!-- The userPasswordWidget is included by the userAddWidget and
> The changePasswdForm. -->
> <display-element displayElementId="userPasswdWidget">
>
> <attribute attName="cuPassword" displayElementId="Text"
> displayName="cuPassword.display" sequence="1"
> requiredField="true">
> <set-property name="size" value="15"/>
> <set-property name="maxlength" value="15"/>
> <set-property name="isPassword" value="true"/>
> </attribute>
>
> <attribute attName="retypePassword" displayElementId="Text"
> displayName="retypePassword.display" sequence="2"
> requiredField="true">
>
> <set-property name="size" value="15"/>
> <set-property name="maxlength" value="15"/>
> <set-property name="isPassword" value="true"/>
> </attribute>
>
> </display-element>
>
Roll your own templating languages are certainly possible, but it's also
nice to
leverage prior art when you can.
A completely different way to consider using JSF would be to build a
RenderKit
that took input like this and generated the corresponding HTML (or
whatever)
markup, starting from the exact same components as the standard HTML
RenderKit.
In the JSF release, there is the very beginnings of an example how this
can be
done, which uses XUL as the input templating language. Fleshing
something like
this out could leverage the fact that Mozilla has already popularized
this as a
technology for defining page layout, as well as some amount of
interactivity.
Craig
--------------------------------------------------------------------- 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]
