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. > 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]
