Arron - fantastic extension! I've just started to use struts and have a
question about how to pass the nested objects back to a data layer. I've
setup a form with 1 simple property and a list property.
All of my forms up to now have included specific properties and I'm trying
to add a List type property so that I can use your nested tag
feature. I've gotten a simple example to work where I basically use a
similar concept as the keyboard Monkey example of embedding the model in
the Form.
My next step is to copy myForm into a modelBean object (both have the same
property and getter/settter methods). Up until now, I've been using
BeanUtils to populate the modelBean. I use BeanUtils to transfer data
between the Form and the ModelBean:
public void populate(Object o) throws ModelException {
try{
BeanUtils.populate(o,BeanUtils.describe(this));
} catch (Exception ex) {
log.fatal("ModelBase: BeanUtils.populate Error",ex);
throw new ModelPopulateException(ex);
}
}
Where o=myForm and this=modelBean. When I add the List property,
BeanUtils.populate is now giving the following error:
java.lang.IllegalArgumentException: argument type mismatch
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.java:1408)
at
org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.java:1314)
at
org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java:1343)
I'm assuming this is because BeanUtils can't populate a List property or am
I doing something wrong?
How have you moved the nested value objects to the data layer?
public class myForm extends Form {
private String id = null;
public void setId(String s){ id=s; }
public String getId(){ return id; }
List list = new ArrayList();
public void setList(List value){
list.clear();
list.addAll(value);
}
public List getList(){ return list; }
}
public class ModelBean {
private Integer id = null;
public void setId(Integer i){ id=i; }
public Integer getId(){ return id; }
List list = new ArrayList();
public void setList(List value){
list.clear();
list.addAll(value);
}
public List getList(){ return list; }
}
Thanks,
Chris....
At 11/29/2001 10:52 PM, Arron Bates wrote:
>That's exactly what it does!
>(My example is that there's an organisation that has teams, that have
>monkeys that pick bunches that hold bananas. But it's all the same).
>
>The extending class that represents a tag, implements
>"NestedParentSupport" and two other interfaces that tell the helper static
>method that the name and the property can be set by the nesting mechanism.
>But NestedParentSupport means that the tag is a parent, and that any
>property beneath it nests under that property adding it's property to the path.
>
>eg: Last night I just finished off making extensions to all the new logic
>and bean tags in the nightly build that were relevant. But as for the
>example... the nested version of the equals tag, needs to use it's current
>nesting level to check against, but the tags that it contains don't want
>it to interfere in the path, so it doesn't implement the
>NestedParentSupport and all the tags in it's contents will jump its
>property. I've adapted my example to use some of the nested logic tags...
>and damn... so fun. I'll be polishing it tonight/tomorrow and post it back
>to the group. A couple of bugs fixed (to do with the parenting) and all
>the tags in struts that could benefit from it.
>
>We're using it as a front to a full enterprisy app, but I have my smaller
>Monkey example serializing to a file defined as a static string in a
>class. It works. The only "slightly" tricky part is that it relies on one
>of the constructors load from a "getInstance()" singleton style so that it
>fetches from the disk. I'll clean it up for presentation, as it was a 15
>minute hack for scientific curiosity, but running out of a static instance
>works a treat for a simple system. I think that it could redefine what
>tools are used to make speedy developed tiny apps.
>
>The abbreviated syntax is simply removing the need for the "name" property
>in the tag. It is set. Every time. But it's internal in the tag. This is
>because we can assume that all nesting tags have to use the same bean,
>therefore just do enough work to fix it's name property for strut's super
>class. It does make the tags nice, small and sexy though. :)
>
>There's one other feature that I've written, but have to finish the
>example tonight, is the ability to drop down levels in the properties.
>For example, you want options in a child class that you want to provide in
>a parent class... to use the familiar "../../" directory style to step
>down levels to get to a parent, or parent's parent etc. Would allow for
>ultimate flexibility in it's usage.
>Also need to spend 5 minutes making a tag that can define the bean at the
>top without the need for a form. Real easy, will be in my stuff tonight.
>
>Re the docco... the great thing is, is that the tags *are* the struts
>tags, with all the documentation on them where the "name" and "property"
>properties are set is true for the nested extension. I'm in the middle of
>a document that is outlining some nice usage, do's, don'ts etc. But this
>will be stuff that differs from the taglib docco that is already there for
>the super tags.
>
>As for the O/R tooling. No, haven't had the chance, not unless one of the
>boys that pulled it off this mail list has.
>
>For the persistent storage... nothing to suggest besides a "roll your own"
>solution. It's easy to set collections of objects from recordsets. That's
>fantastic. I think that this'll all come into its own when JDO
>implementations start rolling.
>
>
>Arron.
>
>
>Ted Husted wrote:
>
>>Arron Bates wrote:
>>
>>>If you want to go this way, I've heard that there's a nesting extension
>>>to make this easier too.
>>
>>So, the underlying purpose of the nested tags is to render the full
>>"path" to an element when it is situate on a nested bean. Given a
>>structure like
>>+Grandparent
>>++Parent
>>+++Child
>>----property
>>
>>With properties like
>>grandparent.getName()
>>grandparent.getParents()
>>
>>parent.getName()
>>parent.getChilds()
>>
>>child.getName()
>>child.getAllowance()
>>
>>We can write something like
>>
>><nested:nest property="grandparent">
>> <nested:write property="name">
>> <nested:iterate property="parents">
>> <nested:write property="name">
>> <nested:iterate propery="childs">
>> <nested:write property="name">
>> $<nested:text property="allowance">
>> </nested:iterate>
>> </nested:interate>
>></nested:nest>
>>
>>With visible output like
>>Lou
>>Stu
>> Tommy
>> $1
>> Dill
>> $0
>>Drew
>> Angelica
>> $10
>>
>>And have Tommy's allowance element be represented in the HTML as
>>$<input type="text" name="grandparent[1].parent[1].child[1].allowance"
>>value="1">
>>
>>When submitted back to the ActinForm, the BeanUtils will then walk this
>>path so that the allowance property for the first child element of the
>>first parent element of the first grandparent element (Tommy) is
>>updated.
>>And, it also allows for an abbreviated syntax, since the nested versions
>>of iterate look to the "enclosing" bean for its "name" property, as the
>>html form tags look to the ActionForm bean.
>>
>>Given the support for indexed and nested properties, I can see that we
>>need a taglib like this to "close the loop". I take it that the
>>nested-taglib-src is ready to commit as is (it looks that way to me).
>>
>>Meanwhile, are you updating a JDBC database from a bean like this?
>>I agree that this is a valid representation of a model, but most
>>developers need to persist something like this to a conventional
>>database.
>>
>>We typically add a Developers Guide to a taglib, where we could put
>>notes about your serialization example, alogn with any notes on mapping
>>this back to a database.
>>Is anyone using an O/R tool that would work well with nested beans like
>>this?
>>
>>
>>-- Ted Husted, Husted dot Com, Fairport NY USA.
>>-- Custom Software ~ Technical Services.
>>-- Tel +1 716 737-3463
>>-- http://www.husted.com/struts/
>>
>>--
>>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]>
