On Thu, 7 Mar 2002, Laurent Farcy wrote:
> Date: Thu, 7 Mar 2002 16:50:10 +0100
> From: Laurent Farcy <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: "'Struts Developer's List (E-mail)'" <[EMAIL PROTECTED]>
> Subject: DynaActionFormClass : possible bug / request for enhancement
>
> Hi all,
>
> I 'm trying to use the last great struts 1.1 feature, aka dynabeans, for my
> application. I wasn't able to use it as is because DynaActionForm supposes
> the form bean properties (and so the form fields) are known at configuration
> time.
>
> In my case, the form bean properties are only known at runtime and I want
> the same form bean to handle totally different forms. I don't want the form
> developer to have to declare a new form bean in struts-config for each form.
Sheesh ... I already saved you having to write all the form bean classes
... some people are just never satisfied :-) :-).
> The 'business logic' I'm working upon is able to provide me with an object
> (let's name its class FormProperties) describing both the form properties
> and their initial values. The form page (ie jsp url) to use is also
> retrieved from the FormProperties object.
>
> So, I wrote a DynaActionForm subclass (let's say RuntimeDynaActionForm)
> which embeds the FormProperties object which is similar to an hashtable,
> except it also carries out property type information and is able to handle
> indexed properties by itself. Notice the FormProperties instance may change
> at every request depending on which form is selected by the user. A specific
> action is in charge of adding the FormProperties object in the http session
> and the DynaActionFormClass bound to the RuntimeDynaActionForm bean is
> redefined at each request by building the right form bean config from this
> http session attribute. This takes place in
> RuntimeDynaActionForm.reset(mapping, request).
>
> And you know what, it works ! It has to be enhanced like, for instance, form
> description object in the http session prevents concurrent form handling. My
> idea is very to reuse the maximum of struts (like validation, taglib, ...)
> starting from a slight different assumption.
>
> Now, the bug I think I found out. I had to change a little
> DynaActionFormClass. Apparently, it intends to double check the dynabean
> class is a sub-class of DynaActionForm when creating a new bean but does the
> opposite. Here is the patch I'm proposing.
>
>
> Index: DynaActionFormClass.java
> ===================================================================
> RCS file:
> /home/cvspublic/jakarta-struts/src/share/org/apache/struts/action/DynaAction
> FormClass.java,v
> retrieving revision 1.2
> diff -r1.2 DynaActionFormClass.java
> 326c326
> < if (!beanClass.isAssignableFrom(DynaActionForm.class)) {
> ---
> > if (!DynaActionForm.class.isAssignableFrom(beanClass)) {
>
Good catch ... I just committed the fix for this.
>
> Moreover, since my DynaActionFormClass object changes at every request, I
> have to clear all the already-registered DynaActionFormClass by calling
> DynaActionFormClass.clear() and create a new one by calling
> DynaActionFormClass.createDynaActionFormClass(config) to assign it to
> DynaActionForm dynaClass protected member. This is the only way I can
> replace the DynaActionFormClass associated with my special dynabean.
>
> It would be nice to have a static
> DynaActionFormClass.replaceDynaActionFormClass(config). I can code and
> submit it if you think it is meaningful.
>
> Perhaps, there was another way to do what i'm trying. Like modifying
> struts-config at runtime to add new FormBeanConfigs. But, I understood the
> application config is frozen... Let me know.
>
I can foresee a possible problem with implementing the
replaceDynaActionFormClass() method that you are proposing. It would
cause the set of current properties to change for *all* of the form beans
created from this particular DynaActionFormClass, not just the new
instance you are creating. This will break the actual DynaActionForm
beans themselves, becuse there is no way to go find them all and update
their internal hashmaps of propety values.
Essentially, you are wanting to create a new DynaActionFormClass
dynamically for every single bean. I suppose you could accomplish that by
passing a unique name for the "name" property of each FormBeanConfig that
you pass, but that isn't going to scale very well -- you'll be creating
lots of these instances, but they won't get GC'd unless you call
DynaActionFormClass.clear() periodically. This problem would not be as
bad if you cached the DynaActionFormClass instances you created, and
reused them when the same set of properties was required again later.
It might be feasible to create an implementation of DynaBean and DynaClass
that behaves in the manner you are visualizing (each DynaBean has a unique
set of properties even though they share the same DynaClass), but that
goes pretty much against the grain of what DynaClass was there to do
(share a single copy of the property information so that it doesn't have
to be stored in each individual DynaBean). It's probably better to look
for ways to cache and reuse the same instances.
> Cheers
>
> Laurent Farcy
> [R&D]
> Akazi Technologies
> 6A, chemin des Prés
> 38240 Meylan - France
>
> <http://www.akazi.com/>
> tel +33 (0)4 56 38 2000
> fax +33 (0)4 56 38 2001
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
