Objects are defined in an XML file like so:
<view-configs>
<view-config>
<view-name>address</view-name>
<view-attribute><name>street1</name><type>java.lang.String</type><value></va
lue></view-attribute>
<view-attribute><name>street2</name><type>java.lang.String</type><value></va
lue></view-attribute>
<view-attribute><name>city</name><type>java.lang.String</type><value></value
></view-attribute>
<view-attribute><name>state</name><type>java.lang.String</type><value></valu
e></view-attribute>
<view-attribute><name>country</name><type>java.lang.String</type><value></va
lue></view-attribute>
</view-config>
<view-config>
etc...
</view-config>
</view-configs>
The ViewFactory is initialized when the web app is initialized and uses
Digester to
create a collection of ViewConfig objects. These are just objects that
represent the XML
structure <view-config>. ViewFactory then iterates over the ViewConfigs and
creates instances
of DynaClass objects which are cached under their unique name (<view-name>).
The ViewFactory.getView() just looks up the view using the specified name,
gets the DynaClass
instance and invokes DynaClass.newInstance() to return a new instance of the
DynaClass which
implements the DynaBean interface. Currently the <value/> has no meaning,
but may be enhanced
in the future to allow for "default" values.
robert
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 22, 2003 9:53 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Struts-config.xml and DynaBeans
>
>
> Can you give me an example of your factory?
>
> Regards,
>
>
> PQ
>
> "This Guy Thinks He Knows Everything"
> "This Guy Thinks He Knows What He Is Doing"
>
> -----Original Message-----
> From: Robert Taylor [mailto:[EMAIL PROTECTED]]
> Sent: January 22, 2003 7:56 AM
> To: Struts Users Mailing List
> Subject: RE: Struts-config.xml and DynaBeans
>
> MJ,
>
> using Digester and org.apache.commons.beanutils package, its not
> that difficult to do this.
>
> In our most recent project, we leverage DynaBeans heavily for creating
> view objects to avoid having to physically create them (RowSetDynaClass
> was not around). We define them in an xml file and read them into
> memory at run time. So when we need a view it looks something like this:
>
> ViewFactory vf = ViewFactory.getInstance();
> DynaBean view = vf.getView("myView");
>
> Adding a new view is as simple as adding a few lines of XML. This approach
> allows use to leverage DynaBeans and not necessarily be dependent
> on Struts.
>
> robert
>
>
>
>
> > -----Original Message-----
> > From: MJ McLaren, Information Systems and Computing
> > [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, January 22, 2003 7:30 AM
> > To: [EMAIL PROTECTED]
> > Subject: Struts-config.xml and DynaBeans
> >
> >
> > Hi,
> >
> > This is my very first contribution. I am new to Struts and
> fairly new to
> > JSP (so go easy on me). I am working on a project that is considering
> > using Struts 1.1. So far I am very impressed, anything that reduces the
> > amount of Java code I need to write gets my vote.
> >
> > I have been looking at dynabeans and the struts version of
> > DynaActionFormClass. I noted that in the Struts configuration file the
> > section for describing form-beans. This is great but being a very lazy
> > programmer, what about a section for describing any type of DynaBean and
> > not just form-beans specifically.
> >
> > The temptation is to write any DynaBean that I use in my web
> > application as
> > a "form-bean" in the Struts-Config file even when I have no intention of
> > making it an actual "form-bean" i.e. writing a validate method or
> > using it
> > via a form.
> >
> > Other than that fact that it make my Struts configuration file
> confusing,
> > any reason why I should not be doing this?
> >
> > Thanks,
> >
> > Mark
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
