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

Reply via email to