Support for the whole concept of "dynamic" beans (i.e. beans where the properties are 
looked up from an internal collection
rather than having explicit getters and setters) is high on my list for 1.1.  Having 
thought a little about this, there are
*lots* of changes needed to add this concept seamlessly, and I'd prefer to wait until 
then before starting to add capabilities
piecemeal.  Does that sound reasonable?

Craig


Johan Compagner wrote:

> ----- Original Message -----
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, January 22, 2001 7:47 PM
> Subject: Re: PROPOSAL: a User implementation Option for getting and setting 
>property's with PropertyUtils
>
> > Johan Compagner wrote:
> >
> > > Hi,
> > >
> > > I myself really need this implementation so i am hoping that it can be inserted 
>in Struts 1.0.
> > > If not then i must alway's use a slightly altered struts version :-(
> > >
> >
> > Johan, it is not clear to me what you're trying to accomplish with these changes.  
>Is it just that you only want
> > a subset of the properties available to be retrieved or set through PropertyUtils? 
> If so, you might investigate
> > using a BeanInfo class along with your form bean.  This allows you to customize 
>the set of properties available
> > -- and even change method names if you want to.  The Java introspection logic 
>fully supports this, so it will get
> > used automatically by PropertyUtils.
>
> I looked at the source of PropertyUtils a bit more. (BeanInfo in my mind)
> but this doesn't work,
> because PropertyUtils does this when getting a property from a bean.
>   Object value = readMethod.invoke(bean, new Object[0]);
>
> See the new Object[0] (so no arguments!!)
>
> And that doesn't work because the argument of getting a property is a String (the 
>property name)
>
> Look this is my Form Bean (a bit cut down)
>
> class DynamicFormBean {
>         private Hashmap _hmValues;
>
>         // Setting a property. The name of the property must exists
>         public setProperty(String sName, Object value) {
>             if(_hm.get(sName) != null) {
>                 _hm.put(sName, value)
>             }
>         }
>
>         // getting a property
>         public Object getProperty(String sName) {
>             return _hm.get(sName);
>         }
>
>         // Called by the database loader.
>         // The Hashmap is has all the attributes of this Form
>         // Those attributes are loaded from the database (and the values if a object 
>exits for that request are filled in)
>         public void setBeginValues(Hashmap hm) {
>             _hmValues = hm;
>         }
> }
>
> So the a database has the description of what properties a specifiek form (object) 
>has
> So when i want another value i only have to add another attribute in the database 
>form description
> and that value can be entered or asked in the jsp file of that form!
>
> Everything is completly dynamic. I don't know nothing about the properties a 
>specifiek form will have
> at compile time. Only at runtime the database will define what kind of properties a 
>specifiek form has
> (can ask and store back in the database)
>
> So you see that using the BeanInfo or whatever won't work!
> The PropertyUtil methods must just relay all the getProperty(String sName) and 
>setProperty(String sName, Object value)
> to the DynamicForm. No introspection can be used because the properties get's and 
>set's aren't there.
>
> I must have this abillity because i want to/must make a financial theme 'generator'
> (not really a generator because there won't be any code generated)
>
> Every object, attribute, flow, rule must be declerative.
>
> Johan C.

Reply via email to