Re: General model question ?

[Arron Bates]

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
>
>
>
>
>
>
>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
>
>indexId="index1">
>indexId="index2">
>property='<%= 
>"myListProperty["+index1+"].mySecondListProperty["+index2+"].myLastProperty"%>'
>
>/>
>
>
>
>(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

Re: General model question ?

[David Morris]

Ted,

Thanks, I think that is a real good idea. I know in many cases, what I

thought everyone would be dying to have, others see no value. I'll 
start looking there when I research new functionality.

In our case, we missed opportunities in Struts because our deadline 
prevented anyone from doing the necessary research. I developed 
quite a few tags that don't integrate as well as I would have liked
with 
the other Struts tags. I don't have a good feel for Arron's nested tag

approach; my fear (probably unfounded) is that his solution may fall 
into this category. Now, we have the luxury of going back and reviewing

what we delivered in preparation for our next big development push.

David Morris

>>> [EMAIL PROTECTED] 12/19/01 12:11PM >>>
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:   
For additional commands, e-mail: 

Re: General model question ?

[Ted Husted]

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:   
For additional commands, e-mail: 

Re: General model question ?

[David Morris]

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






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







(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:   
For additional commands, e-mail: 

Re: General model question ?

[Arron Bates]

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






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







(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:   
>For additional commands, e-mail: 
>

Re: General model question ?

[David Morris]

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:   
For additional commands, e-mail: 

Re: General model question ?

[Chris Hane]

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 fle

Re: General model question ?

[Arron Bates]

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.


Don Saxton wrote:

>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.
>
>  
>  
>
> 
>
>
>   indexed="true"/> 
> 
>  
>   
>
>
>Results in
>  
>
>
> Acquisition Cost Efficie
>  
>
>
>
>   
>  
>
>
> Cost Per Mission
>  
>
>
>
>   
>  
>
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: General model question ?

[Don Saxton]

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.

  
  

 



 
  
   


Results in
  


 Acquisition Cost Efficie
  



   
  


 Cost Per Mission
  



   
  




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: General model question ?

[Ted Husted]

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:   
For additional commands, e-mail: 

Re: General model question ?

[Arron Bates]

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
>
>
>  
>  
>
>
>  
>  $
>
>  
>
>
>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 
>
>$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, bu

Re: General model question ?

[Ted Husted]

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


  
  


  
  $

  


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 

$

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:   
For additional commands, e-mail: 

Re: General model question ?

[Arron Bates]

If you're willing to have struts update the model directly, you can nest 
your model under a getter property in an object that extends ActionForm.
eg: getMyDataModel()
 From the property down, there never needs to ba any reference to struts 
again, besides the methods that provide usually simpler object types 
than the ones you need. However, you can usually write simple conversion 
code inside the objects that can turn it into something more useful when 
you need it. This way, the entire process is automatic, and doesn't any 
property copying/transfer.

In the JSP side of things, you can just write the nested version of the 
property.
eg: 

If you want to go this way, I've heard that there's a nesting extension 
to make this easier too.
;)


Arron.


Taylor Cowan wrote:

>Perhaps we should move to the user list, not dev. but to answer briefly,
>
>ActionForm objects, for me, 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]>
>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: General model question ?

[Taylor Cowan]

Perhaps we should move to the user list, not dev. but to answer briefly,

ActionForm objects, for me, 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 ?

[Allen]

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 prope

Re: General model question ?

[Arron Bates]

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 <

Re: General model question ?

[Paul Speed]

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, 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 Wojte

Re: General model question ?

[Arron]

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 

Re: General model question ?

[Craig R. McClanahan]

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
> > 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 ?

[Ted Husted]

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 ?

[box]

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.

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]>

Re: General model question ?

[Craig R. McClanahan]

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:   
For additional commands, e-mail: 

Re: General model question ?

[Ted Husted]

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:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: