Re: General model question ?
Arron, You solution sounds much simpler. I was in the process of restructuring my code to work with the iterate tag as written. I used to have rows and columns. I was rewriting to have rows, row, and columns so that I could define and access row attributes. You solution sounds much better. My only reservation is that it is not part of the base package. I don't get to vote on that, but on the surface it sounds better than what is available and I think that nested collection support it should absolutely be part of the Struts base. I think that adding an indexed attribute to the iterate tag would accomplish the same thing. Not sure how hard that would be to accomplish; it seems like all you would have to do is walk up the tree until you hit an iterate that doesn't specify indexed and append its name and current index. If you don't get to an iterate, it would be an error. I am all for your solution or support for indexed on the iterate tag. Did you go down the indexed iterate path? Is it worth pursuing to get something in place? David Morris [EMAIL PROTECTED] 12/18/01 06:34PM The extension means you can forget everything the other tags do and only specify your properties. No need for indexed attribute or otherwise. And the other attributes of the iterate tag(like length and offset) work fine. eg nested:iterate property=listPropertyOne nested:iterate property=listPropertyOne nested:text property=myTextProperty / /nested:iterate /nested:iterate And that is all you'll need. You are right with the original tags. You can do all sorts of awesome nesting, except you can only view and not input. Largely because the indexed attribute will only allow you to penetrate only the one iterate tag to set the nested property correctly. This is what the heart of the nested extension is. Writing the proper nested property correctly. There is a way to do it with the original tags (even without the indexed property)... but it is truly messy logic:iterate name=myForm property=myListProperty indexId=index1 logic:iterate name=myForm property=mySecondProperty indexId=index2 html:text name=myForm property='%= myListProperty[+index1+].mySecondListProperty[+index2+].myLastProperty%' / /logic:iterate /logic:iterate (yes I've been in one end and out the other in terms of nesting stuff). This method also kind of goes against the MVC paradigm. And when you compare it to the simplicity of the nested extension version. There's no comparison. But it did fill a void until I wrote the extension. The extension allows for all kinds of lists within lists and any other kind of nesting you can think of. It also allows for other things to be nested. Like logic tags, and other tags which use a property attribute to access a bean. All tags of this manner have a nested extension counterpart. And that is truly powerful. No longer is it just the text tag, or other input tags which get the indexed property. As for adoption... I would like it to be, but that's not for me to answer :) Even if it was kept separate, the Struts guys would have to paradigm shift their tags to stop the extension from working as expected. And if another tag came out... I think it only takes me 5 minutes to add a tag, and that includes a little testing :) I've finished writing a primer, and it will be on my site in the next day or so, along with a by the hand tutorial. And about a week later I'll post some advanced topics and other specifics of the nested extension. When the Primer's up, it should answer most questions, and the rest will fill in the holes. Here's a pre-release version of my Primer (Please nobody link it. There's still other stuff to be done (like linking a small glossary to various terms) and I'm splitting it to multiple pages)... give it a try for me... http://www.keyboardmonkey.com/BetaPrimer.html As for the build it needs.. it works on any version of struts over release candidate 1.01. Actually works on older ones, but I've extended logic tags which were first released in this build. Maybe I should make a version for the old 1.0, yes?) Any other questions, you know where to find me. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: General model question ?
David Morris wrote: My only reservation is that it is not part of the base package. I don't get to vote on that, but on the surface it sounds better than what is available and I think that nested collection support it should absolutely be part of the Struts base. We're planning on transitioning the TODO list and other proposals into Bugzilla enhancements. If it were listed there, then people could register their votes. http://nagoya.apache.org/bugzilla/ -- 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]
Re: General model question ?
For the indexed property to work, it has to look to its parent. I have to look at the implementation, but all tags which use the indexed property have to rely on the parent iterator to supply the property, otherwise if they put the index on themselves, they wont render their property properly. This will have to be done for every tag. One of the things I considered was to propose placing a nested property in each of the tags to turn on the functionality. But this is an extra property for every tag which are full enough. There are properties already there which are not needed (name attribute), and should be separate. Keeping it separate means cleaning the developer interface, and focusing on the nesting, and letting the tags do what they do best. The nested extension allows you to do more than simply penetrate indexed properties. For the indexed property to do what it is the nested extension does, you would also have to now put them through all the logic tags also. You seen the second example?... and that was just with just using the nested version of the logic:equals tag. Nothing to be scared of either David. The extension integrates very well. I had the benefit of going through two solutions to get to this one. I created an indexed tag which does what the indexed property was meant to do, and also created a tagging system so I could do lists within lists, and ended up with a funky tree structrue managing deal. Then I hooked onto the nesting deal as you see it, and developed it. All three systems are in production, as each one allowed functionality the other couldn't provide. They all work great except the first two have limitations in the Struts framework and required a change to the populate methods in the servlet. Where as the nested extension brought together everything both systems handle and work of logic Struts already handled. There isn't any integration issues at all. They simply fix up the the original tag's inability to see each other to get their nested property sorted out. If all you're after is to get through nested lists, you're down the nesting path. Using the nesting extension means managing it is truly easy, and also allows more possibilities because of it's level of implementation. Arron. David Morris wrote: Arron, You solution sounds much simpler. I was in the process of restructuring my code to work with the iterate tag as written. I used to have rows and columns. I was rewriting to have rows, row, and columns so that I could define and access row attributes. You solution sounds much better. My only reservation is that it is not part of the base package. I don't get to vote on that, but on the surface it sounds better than what is available and I think that nested collection support it should absolutely be part of the Struts base. I think that adding an indexed attribute to the iterate tag would accomplish the same thing. Not sure how hard that would be to accomplish; it seems like all you would have to do is walk up the tree until you hit an iterate that doesn't specify indexed and append its name and current index. If you don't get to an iterate, it would be an error. I am all for your solution or support for indexed on the iterate tag. Did you go down the indexed iterate path? Is it worth pursuing to get something in place? David Morris [EMAIL PROTECTED] 12/18/01 06:34PM The extension means you can forget everything the other tags do and only specify your properties. No need for indexed attribute or otherwise. And the other attributes of the iterate tag(like length and offset) work fine. eg nested:iterate property=listPropertyOne nested:iterate property=listPropertyOne nested:text property=myTextProperty / /nested:iterate /nested:iterate And that is all you'll need. You are right with the original tags. You can do all sorts of awesome nesting, except you can only view and not input. Largely because the indexed attribute will only allow you to penetrate only the one iterate tag to set the nested property correctly. This is what the heart of the nested extension is. Writing the proper nested property correctly. There is a way to do it with the original tags (even without the indexed property)... but it is truly messy logic:iterate name=myForm property=myListProperty indexId=index1 logic:iterate name=myForm property=mySecondProperty indexId=index2 html:text name=myForm property='%= myListProperty[+index1+].mySecondListProperty[+index2+].myLastProperty%' / /logic:iterate /logic:iterate (yes I've been in one end and out the other in terms of nesting stuff). This method also kind of goes against the MVC paradigm. And when you compare it to the simplicity of the nested extension version. There's no comparison. But it did fill a void until I wrote the extension. The extension allows for all kinds of lists within lists and any other kind of nesting you can think of. It also allows for other things to be nested.
Re: General model question ?
Arron, I have been struggling to get the current nested tags to do what I need. My first attempt at this failed when I found I needed the nightly build. Next, I got nested tags working for output and thought this is easy. Then I moved on to input. No support for indexed on the iterate tag. Then I thought I will simply swap the x and y coordinates of my collections. But there is no way I can see to reference a variable of on the length or offset attributes. Now I have come full circle. Does your extension solve this and is it likely to become a standard extension? If the answer to this is no, I guess that I will try adding support for indexed on the iterate tag, seems simple enough, but I haven't spent much time looking at what is available. David Morris [EMAIL PROTECTED] 11/30/01 07:26PM You are right in that the indexed property isn't in the indexed tag. The discussion was more on the new nesting tags that get through all this properly. Go here for the downloads... http://www.keyboardmonkey.com/download/struts/index.html And for a running example... http://www.keyboardmonkey.com/StrutMonkey With any luck they'll be a part of struts soon. You can get the basic iterators to go through more than one level, but it takes some fiddling. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: General model question ?
The extension means you can forget everything the other tags do and only specify your properties. No need for indexed attribute or otherwise. And the other attributes of the iterate tag(like length and offset) work fine. eg nested:iterate property=listPropertyOne nested:iterate property=listPropertyOne nested:text property=myTextProperty / /nested:iterate /nested:iterate And that is all you'll need. You are right with the original tags. You can do all sorts of awesome nesting, except you can only view and not input. Largely because the indexed attribute will only allow you to penetrate only the one iterate tag to set the nested property correctly. This is what the heart of the nested extension is. Writing the proper nested property correctly. There is a way to do it with the original tags (even without the indexed property)... but it is truly messy logic:iterate name=myForm property=myListProperty indexId=index1 logic:iterate name=myForm property=mySecondProperty indexId=index2 html:text name=myForm property='%= myListProperty[+index1+].mySecondListProperty[+index2+].myLastProperty%' / /logic:iterate /logic:iterate (yes I've been in one end and out the other in terms of nesting stuff). This method also kind of goes against the MVC paradigm. And when you compare it to the simplicity of the nested extension version. There's no comparison. But it did fill a void until I wrote the extension. The extension allows for all kinds of lists within lists and any other kind of nesting you can think of. It also allows for other things to be nested. Like logic tags, and other tags which use a property attribute to access a bean. All tags of this manner have a nested extension counterpart. And that is truly powerful. No longer is it just the text tag, or other input tags which get the indexed property. As for adoption... I would like it to be, but that's not for me to answer :) Even if it was kept separate, the Struts guys would have to paradigm shift their tags to stop the extension from working as expected. And if another tag came out... I think it only takes me 5 minutes to add a tag, and that includes a little testing :) I've finished writing a primer, and it will be on my site in the next day or so, along with a by the hand tutorial. And about a week later I'll post some advanced topics and other specifics of the nested extension. When the Primer's up, it should answer most questions, and the rest will fill in the holes. Here's a pre-release version of my Primer (Please nobody link it. There's still other stuff to be done (like linking a small glossary to various terms) and I'm splitting it to multiple pages)... give it a try for me... http://www.keyboardmonkey.com/BetaPrimer.html As for the build it needs.. it works on any version of struts over release candidate 1.01. Actually works on older ones, but I've extended logic tags which were first released in this build. Maybe I should make a version for the old 1.0, yes?) Any other questions, you know where to find me. Arron. David Morris wrote: Arron, I have been struggling to get the current nested tags to do what I need. My first attempt at this failed when I found I needed the nightly build. Next, I got nested tags working for output and thought this is easy. Then I moved on to input. No support for indexed on the iterate tag. Then I thought I will simply swap the x and y coordinates of my collections. But there is no way I can see to reference a variable of on the length or offset attributes. Now I have come full circle. Does your extension solve this and is it likely to become a standard extension? If the answer to this is no, I guess that I will try adding support for indexed on the iterate tag, seems simple enough, but I haven't spent much time looking at what is available. David Morris [EMAIL PROTECTED] 11/30/01 07:26PM You are right in that the indexed property isn't in the indexed tag. The discussion was more on the new nesting tags that get through all this properly. Go here for the downloads... http://www.keyboardmonkey.com/download/struts/index.html And for a running example... http://www.keyboardmonkey.com/StrutMonkey With any luck they'll be a part of struts soon. You can get the basic iterators to go through more than one level, but it takes some fiddling. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: General model question ?
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
Re[2]: General model question ?
Hello Ted, I take a part in developing of application with O/R using. We use Castor as O/R library. I think nested tag model can be useful for it. But if we needs to perform conversion from String values to business object properties then needs to perform some kind of validation at phase of conversion. Ie - BeanUtils must throw some kind of exception at any wrong value. ActionForm setter method can catch such exception and summarize all this stuff to the Errors object. Without it we, in our multilangual application, needs to collect String values in ActionForm, validate and convert it with current locale (date and numeric values) to the business objects. And in Action class we can map such objects via Castor to the database. Friday, November 30, 2001, 6:40:43 AM, you wrote: TH Arron Bates wrote: If you want to go this way, I've heard that there's a nesting extension to make this easier too. TH So, the underlying purpose of the nested tags is to render the full TH path to an element when it is situate on a nested bean. Given a TH structure like TH +Grandparent TH ++Parent TH +++Child TH property TH With properties like TH grandparent.getName() TH grandparent.getParents() TH parent.getName() TH parent.getChilds() TH child.getName() TH child.getAllowance() TH We can write something like TH nested:nest property=grandparent TH nested:write property=name TH nested:iterate property=parents TH nested:write property=name TH nested:iterate propery=childs TH nested:write property=name TH $nested:text property=allowance TH /nested:iterate TH /nested:interate TH /nested:nest TH With visible output like TH Lou TH Stu TH Tommy TH$1 TH Dill TH$0 TH Drew TH Angelica TH$10 TH And have Tommy's allowance element be represented in the HTML as TH $input type=text name=grandparent[1].parent[1].child[1].allowance value=1 TH When submitted back to the ActinForm, the BeanUtils will then walk this TH path so that the allowance property for the first child element of the TH first parent element of the first grandparent element (Tommy) is TH updated. TH And, it also allows for an abbreviated syntax, since the nested versions TH of iterate look to the enclosing bean for its name property, as the TH html form tags look to the ActionForm bean. TH Given the support for indexed and nested properties, I can see that we TH need a taglib like this to close the loop. I take it that the TH nested-taglib-src is ready to commit as is (it looks that way to me). TH Meanwhile, are you updating a JDBC database from a bean like this? TH I agree that this is a valid representation of a model, but most TH developers need to persist something like this to a conventional TH database. TH We typically add a Developers Guide to a taglib, where we could put TH notes about your serialization example, alogn with any notes on mapping TH this back to a database. TH Is anyone using an O/R tool that would work well with nested beans like TH this? TH -- Ted Husted, Husted dot Com, Fairport NY USA. TH -- Custom Software ~ Technical Services. TH -- Tel +1 716 737-3463 TH -- http://www.husted.com/struts/ -- Best regards, Olegmailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: General model question ?
Arron Bates wrote: 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. That would be the developer's guide, then. We've been just annexing it to the package.html file, as part of the overview. http://jakarta.apache.org/struts/api-1.0/org/apache/struts/taglib/html/package-summary.html#package_description So then, like the technical taglib docs, it doesn't become an entirely separate file to maintain. -- 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]
Re: General model question ?
Actually I don't think there is an option, because the indexed=true in the current logic is not an attribute of iterate so that the following has an incomplete result. In other words the the current tag only can do one level. !-- begin ScoreFactor -- logic:iterate id=factor name=category property=scoreFactorTree tr class=authordata tdnbsp;bean:write name=factor property=name //td !-- begin EffectParts -- logic:iterate id=part name=factor property=effectList tdhtml:text name=part property=value indexed=true//td !--ONE LEVEL ONLY -- /logic:iterate !-- end EffectParts -- /tr /logic:iterate !-- end ScoreFactor -- Results in !-- begin ScoreFactor -- tr class=authordata tdnbsp;Acquisition Cost Efficie/td !-- begin EffectParts -- tdinput type=text name=part[0].value value=/td !-- end EffectParts -- /tr tr class=authordata tdnbsp;Cost Per Mission/td !-- begin EffectParts -- tdinput type=text name=part[0].value value=/td !-- end EffectParts -- /tr -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: General model question ?
Hello, Sorry to be coming in so late on this, but I had a couple of basic questions (I have only started using STRUTS, so if this is obvious please slap some links at me and send me on my way :-) ): Which object type are people having their Action's send into their business and/or data layers: ones that derive from ActionForm or ones that implement the Value Object pattern? And how are they converting the business and/or data layer's response back (into Action Forms? or are you sending back the Value Object so that the custom tags can use that?). My initial feeling on this was to only send Value Objects to the business and data layers so that they would not get coupled to what is obviously a presentation layer object (I saw Actions as bridges between the layers, converting between the Action Forms and Value Objects and back again). The problem I hit was that I did not want to have to write a bunch of conversion code (see below) to create my Value Object (since it is immutable and, hence does not have the setValue(object) methods that automatic JavaBean conversion utilities need): MyValueObject val = new MyValueObject(converter.convert(form.getValue(), typeOfConversion)); Where the above code would take the String value from an ActionForm, convert it into the type needed, and pass it into the constructor for the Value Object. Hit the same problem running back the other way (from Value Objects to Action Forms). OR are people making their value objects mutable and maybe having them implement a read-only interface that the business and data layers use when interacting with or returning the object? OR are people passing in the ActionForm to the Value Object so that it can extract what it needs (are you fronting it with an interface?)? OR are people passing in a map of properties and their values to the Value Object for it to pick and choose what it wants? OR something else entirely...? When you are going back from Value Object to Action Form, how are you controlling the output format? I know that the Action needs to understand the format of the data that it would expect to receive from a submitted form... So, I am assuming that all formatting has to happen before it gets to the custom tag (the only exception being when it is writing data that will not come back through a form or query string). Is this what people are doing? The converter objects that Arron spoke about sound like one possible solution to some of this... I was a bit unclear on what code was doing what, though. From what I understand, are you saying that the ActionServlet is configured to use these converters based on the struts-config.xml file? And that it figures out what conversions to try according to a method that is defined in an interface that your ActionForms implement? Could you describe how (from an object level) the data flows back in forth? For instance, does it work like this: Container: Request comes in | ActionServlet: Get list of convertions to run from configured ActionForm | ActionServlet: Run converters | ActionServlet: \ Conversion failed - send error messages back to user \ Conversion worked - continue processing | ... Then what happens? Thanks for everyone's patience with such a long list of questions! Allen In Reference To: From: Arron Bates Subject: Re: General model question ? Date: Tue, 27 Nov 2001 14:51:24 -0800 I didn't code it, but I have to use it. The chaps here did it before I hit the scene. But I have to say that it's quite elegant. You won't find it in the code I've written for nesting extension. I didn't write this, so it's out of my hands to submit it (and I think that their client paid too much for it to give it away), but I can transfer some IP and wouldn't mind working on the actual solution. But back to the story... 1) yes. 2) yes, but the fine grained errors come from another validation mechanism. Where a custom action was made from extending the struts action, and using an interface the the beans implement, fetch's a series of validation rules from the form to run through. This brings the finer grained business driven errors. The Converters themselves however only throw one error per object type. What I'd like to see, and I think that it'd be easy to implement, would be that if a converter failed, that it register an error against the property key that threw it. Then you could write out the errors properly for each instance. 3) No. This would take an extra runtime mapping to say that n inputs go into the one converter. Not currently implemented, but I do agree that it would be some cool functionality. Best I've done is to have a child object that holds the three properties and returns the proper Calendar object when asked
RE: General model question ?
Perhaps we should move to the user list, not dev. but to answer briefly, ActionForm objects, emfor me/em, are strictly view layer. They get data from the view to my model, so they are like glue. They may perform some validation, like making sure a field is numeric or valid date. I place an update method on my ActionForms that update my model, which keeps actions clean. Your model should have absolutely no knowledge of servlets or struts. You should be able to compile the entire model layer without any web oriented classes. Taylor -Original Message- From: Allen [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 29, 2001 12:59 PM To: [EMAIL PROTECTED] Subject: Re: General model question ? Which object type are people having their Action's send into their business and/or data layers: ones that derive from ActionForm or ones that implement the Value Object pattern? And how are they converting the business and/or data layer's response back (into Action Forms? or are you sending back the Value Object so that the custom tags can use that?). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: General model question ?
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]
Re: General model question ?
People reading this thread should also look at the last few in... Re: Fwd: Re: Extensibility of struts... It's touching the same topic. I think that the most important things is what was just raised. The marshaling of strings into more valid objects. One implementation I'm working with has altered the struts servlet to allow the configuration of Converter objects to be mapped to object types, so that you can specify classes that can handle this marshal on a specific need in an automatic process. e.g.: we use BigDecimal for all of our dollar types (financial app), and there's a converter set up to handle the marshaling, and on the inside the model is perfectly fine. A bad marshal also results in an error, and is returned to the input view. Quite neat. Not taking away from skill or intentions, you've all written some sweet stuff, but don't you think (this is more than likely just me. I often think too laterally and get the wrong point on things) that relying on a big property switcheroo from the form object to the data model in the action class is messy and almost defeating the point of struts when it handles everything automatically, excellently and elegantly?... Struts' level of automagic management is something to be beheld, but as a group trying to maintain wads of yukky code that's frizbee-ing data from one object to another. It's like a Ken Done painting hanging on the wall of the Sistine Chapel. Nasty ugly little blemish. Arron. Craig R. McClanahan wrote: On Sun, 25 Nov 2001, box wrote: Date: Sun, 25 Nov 2001 22:53:38 +0100 From: box [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], box [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: General model question ? Thank you Craig, I see the point, You are right it makes a lot of sense. But the behind the scene matter of my question was the performance reason. I have to copy all the properties of ActionForm to appropriate business logic object. The clean way of doing this is using the reflection API, which is rather slow. First, you're going to have to do this type of conversion anyway -- because HTTP parameters come in as strings, you don't want to directly use things like java.util.Date for the properties. Second, have you *yourself* done benchmarks that the cost of reflection even matters? Consider: * This is totally an issue of CPU time - economically, this is an incredibly easy problem to solve (in fact, it's very difficult to buy a new processor that is faster than your current one, but actually costs you more money). * Modern JVMs have ***vastly*** narrowed the performance gap between reflection based calls and direct calls. In the very large majority of cases, it's just not worth worrying about. * If our application is based on EJBs, it is already doing a *lot* more reflection-based processing than Struts is doing. My advice would be focus on reducing developer effort -- this is ***much*** more expensive than whatever hardware you utimately deploy your application on. regards Wojtek Craig - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED]; box [EMAIL PROTECTED] Sent: Sunday, November 25, 2001 7:14 AM Subject: Re: General model question ? On Thu, 22 Nov 2001, box wrote: Date: Thu, 22 Nov 2001 19:36:25 +0100 From: box [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], box [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: General model question ? Hi everybody, I am new to struts, but I find them very usefull. There is one question that bothers me. Wy is ActionForm a class not an interface ? I have got my own application data model and I would just need to implement the ActionForm to update/input the data via html forms. But it's not possible - I must inherit the struts structure, so I have to create ActionForm with get, set methods and after all copy all properties between my data model and the corresponding ActionForm. Am I missing something ? ActionForm is a class in order to *prevent* exactly the behavior you propose :-). The purpose of an ActionForm is to contain the server-side state of the input fields, for the following reasons: * So that you can validate them (you don't want invalid data being scribbled into your application data objects by Struts's automatic bean population) * So that you can reproduce the user's input data in case of an error such as an invalid integer (you would use a String in the ActionForm for an EJB property that is an int). * So that your application data objects can be reused in non-Struts contexts (otherwise, they would always require struts.jar to be around). You *really* don't want to modify anything in your application data model until *after* validation has succeeded. That's why the Struts design pattern is to do this in an Action, by copying the appropriate values from
Re: General model question ?
I didn't code it, but I have to use it. The chaps here did it before I hit the scene. But I have to say that it's quite elegant. You won't find it in the code I've written for nesting extension. I didn't write this, so it's out of my hands to submit it (and I think that their client paid too much for it to give it away), but I can transfer some IP and wouldn't mind working on the actual solution. But back to the story... 1) yes. 2) yes, but the fine grained errors come from another validation mechanism. Where a custom action was made from extending the struts action, and using an interface the the beans implement, fetch's a series of validation rules from the form to run through. This brings the finer grained business driven errors. The Converters themselves however only throw one error per object type. What I'd like to see, and I think that it'd be easy to implement, would be that if a converter failed, that it register an error against the property key that threw it. Then you could write out the errors properly for each instance. 3) No. This would take an extra runtime mapping to say that n inputs go into the one converter. Not currently implemented, but I do agree that it would be some cool functionality. Best I've done is to have a child object that holds the three properties and returns the proper Calendar object when asked by the business logic. The particular system that I work with is robust enough to get the job done, but I think that working in hind-sight would make it a truly nice solution. Arron. Paul Speed wrote: Admittedly, I haven't looked at your code... but can you please verify that it meets the following requirements: 1) All form errors are displayed together. In other words, if more than one field is bad, the user will see all bad fields rather than having to correct them one at a time. 2) The user sees the original data they input. In other words, if the user enters abc into a dollar field, then the form displaying the errors and allowing them to redo their input will also display abc. 3) Data conversion and validation can be done on multiple fields at once. One example is a set of date fields (month, day, year) that together form a single Date object. I always find this topic interesting because I don't think the right answer has really bubbled up yet. That's why I try to understand the different approaches. From my point of view, to meet the above requirements data conversion and validation would have to be done on or within the entire form bean. Since your code sounds like it does this before the data ever gets to the form bean, I just wondered how you solved those issues. -Paul Arron wrote: People reading this thread should also look at the last few in... Re: Fwd: Re: Extensibility of struts... It's touching the same topic. I think that the most important things is what was just raised. The marshaling of strings into more valid objects. One implementation I'm working with has altered the struts servlet to allow the configuration of Converter objects to be mapped to object types, so that you can specify classes that can handle this marshal on a specific need in an automatic process. e.g.: we use BigDecimal for all of our dollar types (financial app), and there's a converter set up to handle the marshaling, and on the inside the model is perfectly fine. A bad marshal also results in an error, and is returned to the input view. Quite neat. Not taking away from skill or intentions, you've all written some sweet stuff, but don't you think (this is more than likely just me. I often think too laterally and get the wrong point on things) that relying on a big property switcheroo from the form object to the data model in the action class is messy and almost defeating the point of struts when it handles everything automatically, excellently and elegantly?... Struts' level of automagic management is something to be beheld, but as a group trying to maintain wads of yukky code that's frizbee-ing data from one object to another. It's like a Ken Done painting hanging on the wall of the Sistine Chapel. Nasty ugly little blemish. Arron. Craig R. McClanahan wrote: On Sun, 25 Nov 2001, box wrote: Date: Sun, 25 Nov 2001 22:53:38 +0100 From: box [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], box [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: General model question ? Thank you Craig, I see the point, You are right it makes a lot of sense. But the behind the scene matter of my question was the performance reason. I have to copy all the properties of ActionForm to appropriate business logic object. The clean way of doing this is using the reflection API, which is rather slow. First, you're going to have to do this type of conversion anyway -- because HTTP parameters come in as strings, you don't want to directly use things like java.util.Date for the properties. Second
Re: General model question ?
The reflection API has been steadily improved with each JVM release, and you may find that the performance difference is now neglible. In fact, weighed against loading scads of custom code just to populate values, it may be more performant. http://husted.com/struts/resources/performant.htm box wrote: I see the point, You are right it makes a lot of sense. But the behind the scene matter of my question was the performance reason. I have to copy all the properties of ActionForm to appropriate business logic object. The clean way of doing this is using the reflection API, which is rather slow. regards Wojtek - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED]; box [EMAIL PROTECTED] Sent: Sunday, November 25, 2001 7:14 AM Subject: Re: General model question ? On Thu, 22 Nov 2001, box wrote: Date: Thu, 22 Nov 2001 19:36:25 +0100 From: box [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], box [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: General model question ? Hi everybody, I am new to struts, but I find them very usefull. There is one question that bothers me. Wy is ActionForm a class not an interface ? I have got my own application data model and I would just need to implement the ActionForm to update/input the data via html forms. But it's not possible - I must inherit the struts structure, so I have to create ActionForm with get, set methods and after all copy all properties between my data model and the corresponding ActionForm. Am I missing something ? ActionForm is a class in order to *prevent* exactly the behavior you propose :-). The purpose of an ActionForm is to contain the server-side state of the input fields, for the following reasons: * So that you can validate them (you don't want invalid data being scribbled into your application data objects by Struts's automatic bean population) * So that you can reproduce the user's input data in case of an error such as an invalid integer (you would use a String in the ActionForm for an EJB property that is an int). * So that your application data objects can be reused in non-Struts contexts (otherwise, they would always require struts.jar to be around). You *really* don't want to modify anything in your application data model until *after* validation has succeeded. That's why the Struts design pattern is to do this in an Action, by copying the appropriate values from the ActionForm into your application data objects, performing any data conversions that are necessary. Making ActionForm a class instead of an interface forces you to do the right thing. regards Wojtek Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Myslisz o otworzeniu wlasnego sklepu internetowego? A moze o wynajeciu stoiska w wirtualnym pasazu? W Centrum e-biznesu mozesz miec jedno i drugie. Juz od 290 zl za rok. Wybierz: e-witryne lub e-sklep. http://handel.getin.pl/ -- Myslisz o otworzeniu wlasnego sklepu internetowego? A moze o wynajeciu stoiska w wirtualnym pasazu? W Centrum e-biznesu mozesz miec jedno i drugie. Juz od 290 zl za rok. Wybierz: e-witryne lub e-sklep. http://handel.getin.pl/ -- 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]
Re: General model question ?
On Thu, 22 Nov 2001, box wrote: Date: Thu, 22 Nov 2001 19:36:25 +0100 From: box [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], box [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: General model question ? Hi everybody, I am new to struts, but I find them very usefull. There is one question that bothers me. Wy is ActionForm a class not an interface ? I have got my own application data model and I would just need to implement the ActionForm to update/input the data via html forms. But it's not possible - I must inherit the struts structure, so I have to create ActionForm with get, set methods and after all copy all properties between my data model and the corresponding ActionForm. Am I missing something ? ActionForm is a class in order to *prevent* exactly the behavior you propose :-). The purpose of an ActionForm is to contain the server-side state of the input fields, for the following reasons: * So that you can validate them (you don't want invalid data being scribbled into your application data objects by Struts's automatic bean population) * So that you can reproduce the user's input data in case of an error such as an invalid integer (you would use a String in the ActionForm for an EJB property that is an int). * So that your application data objects can be reused in non-Struts contexts (otherwise, they would always require struts.jar to be around). You *really* don't want to modify anything in your application data model until *after* validation has succeeded. That's why the Struts design pattern is to do this in an Action, by copying the appropriate values from the ActionForm into your application data objects, performing any data conversions that are necessary. Making ActionForm a class instead of an interface forces you to do the right thing. regards Wojtek Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
General model question ?
Hi everybody, I am new to struts, but I find them very usefull. There is one question that bothers me. Wy is ActionForm a class not an interface ? I have got my own application data model and I would just need to implement the ActionForm to update/input the data via html forms. But it's not possible - I must inherit the struts structure, so I have to create ActionForm with get, set methods and after all copy all properties between my data model and the corresponding ActionForm. Am I missing something ? regards Wojtek -- Myslisz o otworzeniu wlasnego sklepu internetowego? A moze o wynajeciu stoiska w wirtualnym pasazu? W Centrum e-biznesu mozesz miec jedno i drugie. Juz od 290 zl za rok. Wybierz: e-witryne lub e-sklep. http://handel.getin.pl/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: General model question ?
The inheritance is a necessary part of the Struts design. I realize that it seems wasteful at first, but the ActionForm beans have several special needs that may not apply to the other beans in your application. An interface was tried in the earliest instances of the framework, but discarded for several reasons. The biggest one is that we may need to yet add another method, and if the ActionForm was an interface, everything would break ;-( The other reason was that people tried to turn their business beans into ActionForm beans, which is really not a good idea in practice (as seductive as it sounds ;-) For more see http://www.mail-archive.com/struts-user@jakarta.apache.org/msg08070.html and http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01495.html You should also take a look at the BeanUtils for quick and easy ways to populate beans. I add a toMap() method to all my ActionForm beans, which, with BeanUtils.populate() can be an easy way to populate your business beans. In fact, these are so useful, we moved them to theCommons for 1.1 ;-) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/about/struts/ box wrote: Hi everybody, I am new to struts, but I find them very usefull. There is one question that bothers me. Wy is ActionForm a class not an interface ? I have got my own application data model and I would just need to implement the ActionForm to update/input the data via html forms. But it's not possible - I must inherit the struts structure, so I have to create ActionForm with get, set methods and after all copy all properties between my data model and the corresponding ActionForm. Am I missing something ? regards Wojtek -- Myslisz o otworzeniu wlasnego sklepu internetowego? A moze o wynajeciu stoiska w wirtualnym pasazu? W Centrum e-biznesu mozesz miec jedno i drugie. Juz od 290 zl za rok. Wybierz: e-witryne lub e-sklep. http://handel.getin.pl/ -- 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]
