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?
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>
> At 3:47 PM +0000 12/19/03, PILGRIM, Peter, FM wrote:
>>Having spoken with Don Brown, I can see the benefits now
>>of the BeanWrapper and the [Xml]BeanFactory in Spring. Creating
>>a graph of objects from an XML file is pretty handy for certain
>>situations. I can see the light of the joke. Objects just
>>"Spring" into life from literal paper.
>>
>>I guess the decision here will be political. "Can we just take
>>or borrow the org.springframework.beans.* of your framework?"
>>Hmmm.
>
> The thing that looks attractive to me in Spring is the ability to make
> a graph of objects more complicated than a tree. It would be possible
> to do this in Digester, without necessarily even writing custom rule
> classes.
>
> As for PicoContainer, if someone could just show me how you write an
> external configuration file that wires together objects through their
> constructors, I might buy it, but it just doesn't seem to match up. As
> soon as you had one new collaborator that you hadn't planned for, you'd
> have to rewrite some java code somewhere, wouldn't you?
>
> That's another facet of Spring that appeals to me -- it's orientation
> towards JavaBean conventions -- but we can achieve that with
> homegrown processes using (or at least inspired by) Digester if we're
> reluctant to pile on Spring.
>
> If Spring uses an Apache license, then politics or not we can use the
> code just about anyway we like, but I don't know that we need to read
> the Spring code to achieve the few things that seem most useful to me.
> I still haven't found the time to really dig into the various
> microkernel/IoC type frameworks yet, so I hope I'm not just blowing
> smoke...
>
> Joe
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "We want beef in dessert if we can get it there."
> -- Betty Hogan, Director of New Product Development, National
> Cattlemen's Beef Association
>
>
> --------------------------------------------------------------------- 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]
