Answer in line ...

> > I'm trying to add regular Javabean style properties, as 
> well as dynamic
> > properties.
> >
> 
> Ah ... then you're not going to like the current implementations of
> DynaBeans very much.  They currently represent themselves as 
> having *only*
> the set of dynamic properties that are defined.
> 
> > an excerpt from the struts-config would be something like:
> >
> > <form-bean name="AddressForm" type="com.xxxxx.XXDynaActionForm"
> > dynamic="true" 
> className="com.xxxxx.struts.config.XXFormBeanConfig" >
> >     <set-property property="voClassName"
> > value="com.xxxxx.AddressTypeVO"/>
> >     <set-property property="converterClassName"
> > value="com.xxxxx.AddressType"/>
> >     <form-property name="add1" type="java.lang.String"/>
> >     <form-property name="add2" type="java.lang.String"/>
> >     <form-property name="add3" type="java.lang.String"/>
> > </form-bean>
> >
> > So in effect, the XXDynaActionForm class simply adds 2 
> properties to the
> > standard DynaActionForm, and likewise for the 
> XXFormBeanConfig class.
> >
> 
> What makes voClassName and converterClassName any different 
> than any other
> dynamic property?  Why can't you just declare them with 
> <form-property>
> elements like "add1", "add2", and "add3"?

The voClassName etc. are set in the struts config file so that we can
determine what type value object to create from each form. In effect, they
are static fields. 

> 
> > According the 1.1 dtd this is allowable.
> >
> > If it's not obvious from the above, what I'm trying to do 
> is to write as
> > little code as possible ....
> > there'll be the one ActionFormClass, using dynamic 
> properties. As the
> > project is using EJB, the Action class will convert the 
> dynamic properties
> > to the relevant Value Object type using the specifined 
> converter, before
> > invoking the required business object.
> >
> > I could have the voClassName, and converterClassName as 
> form-property's with
> > an initial value. But, would these not then get cleared on 
> calling the reset
> > method ?
> >
> 
> If you declared them as standard dynamic properties (with
> <form-property>), they would get initialized (and cleared) to null.

According to the dtd there's an initial attribute on the form-property tag,
I take it I could use this property, and then override the reset method to
ensure that my 'static' fields remain at their initial values ?

I'm not an expert with dtd's, but am wondering if it is possible to not
allow set-property tag's under the form-bean tag, if the form-bean is set to
dynamic ? As it seems they are not supported, this would make sense, if
possible ?

Roy.

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

Reply via email to