Laurie,
The form is largely handled in two parts. The JSP is interpreted and the
form inputs are rendered as properties of a bean. The struts tags uses
reflection to get a hold of the values held by the bean. These property
names are written out as the names of the form elements.
When the
Just a note on this subject
You know that you can get absolutely sweet decoupling from everything
struts for your data model with the use of nesting objects?... And no
messy property copying!
I wanted to get a simple persistence mechanism running for my form
object, so I placed a little
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
USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
Arron Bates wrote:
It doesn't even have to be a careful look at the code. It's not complex
in the least.
I must be missing something with the String or boolean properties that
affect the system
Peoples,
More sleepless ones later, I think that I have the nested extension as
far as it needs to be for true adoption.
All the tags that were applicable (logic and bean), little house
cleaning, a bug fix (that cropped up with the new tags), new example,
testing JSP for the new tags, tidier
class
that provides facilities for testing code based on the Struts framework./p
pa
href=http://husted.com/struts/resources/MonkeyStruts.htm;bMonkeyStruts/b/a by
Arron Bates. An approach to nesting beans./p
pa href=http://www.multimania.com/bist77/struts.php;font
size
Idea...
There was just that too and fro in additional properties needed on
html:image... bug in that there was the argument over what to support
and what not to support... if there was a standard property (ie:
freetext, freeform, uglytext or something) where developers could
add a string to
I really think questions of compliance and properness are out of
context in all truth. You get Html outside that of the struts tags...
let's say... 96% of the markup are you're in the most free text you've
ever seen in your life. You aint seen the fun of free markup until
you've left off a
)
- Original Message -
From: Arron Bates [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Sunday, December 09, 2001 11:27 PM
Subject: Freetext attribute for all tags...
Idea...
There was just that too and fro in additional properties needed on
html:image... bug
It's all reality. Standards and non-compliant realities alike.
Take the new DOM scripting model... NS copied IE in the
getElementById()... why... because it's truly sweet. But it's not in the
spec. It's an example where the spec is not as good as the
implementation. W3C are recommendations,
(I do apologise for this post. It should stop. But for some reason I
just can't handle misrepresentation of trying to get markup to work in
the largest amount of browsers possible (both those inside and outside
the spec). So, if you don't want to hear a rant in reply to a rant, read
another
The only way which I've done such a thing is with a bean nested one
level inside another.
The constructor is called on the root bean, and have getters and setters
there waiting to handle the parameters that you're passing from your
form. In your action, call another method which will then
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
It's already in the system you're using. Just do it!
I made it before I released it the second round. It's the new property
property section of the Package.html
It works off of the tokenizer working off the / character, so you can
have anything in between. I allowed this for the naming
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
The check for NestedSelectTag is no more
(removed last night. It wasn't buggy, just not needed).
The check is replaced by one on an interface which some 14 or so tags use now.
Did you get around the spurious results of the two tags?...
Arron.
Tom Klaasen (TeleRelay) wrote:
-Original
This is really for the struts-user list.
However... the error you have pasted here has nothing to do with the
username property, but with the bean's property for institution. More
specifically, struts can't find it. Could be that you're getter method
for the institution property is not public
Email starting with How do I are for the struts-user list.
This is more for your benefit as it is a community list entirely devoted
to solving problems.
The developer list is entirely devoted to creating them :)
Arron.
The only place I've seen the answer is on the strtus-user mailing list.
Excuse the ignorance, but how will the multiple-servlet controller
change the way JSP views work?...
I could possibly imagine a change to the form tag, but that would be it
wouldn't it?... (yes/no Craig?)
There's been a couple of updates (one is related to the Resin bug that
was just
I could possibly imagine a change to the form tag, but that would be it
wouldn't it?... (yes/no Craig?)
I need to look more at this.
I only mentioned the form tag as I assume you will need to look up the
forwards form beans for the action relative to the app/sub-app.
If Resin is not
I've tried to do this with Castor generated objects. Problem is though,
is that the errors are not fine grained at all.
You validate the document by calling the validate() method on the top
node, and you get a yes or a no.
You can do this for all of the sub objects, but it's just that, you
that to persist the populated beans from within the
Action.
Cheers,
Jon
Arron Bates wrote:
I've tried to do this with Castor generated objects. Problem is though,
is that the errors are not fine grained at all.
You validate the document by calling the validate() method on the top
node, and you get a yes
Peers,
Finally have the resource page at a useful level for the general
developer community.
There's the latest update to the extension, The primer, The tutorial, an
advanced topics page and a whole mess of other stuff.
Hopefully it will answer all questions which are itching people.
Ted,
Take a squizz at the tutorials I put up on my nested extension page.
http://www.keyboardmonkey.com/stats
(thinking of putting up a support group page for blatant traffic
generators anonymous too. You in? :)
Starting off with the war file of everything needed with exception of
files
A note to anyone who's interested...
Just tested the extension against Craig's code to make sure everything
hums along nicely with the Multi-App stuff, and it does.
Runs all my tag tests and the monkey examples as they've always run.
Out of the 3000 hits to my running examples for the past 14
First of all, thanks for the votes peoples.
Need to confirm something and ask opinions on another before I scuttle
the codebase...
(need three +1's or 0's, or some -1's with explanations if you please) ...
1) The nested system is going into the main source tree (not contrib)?...
2) The TLD.
I'm not quite ready for that yet ... how about in contrib first?
No offense, but what's to be ready for?...
It's tested against your multi-app stuff. All works a treat, and being
used by tons of happy campers.
Or I can just wait until you've played with it...
Remember that all the
Oleg V Alexeev wrote:
One point to make it one, because of all nested tags are extends tags
from different taglibs and use its own internal logic, common for all
nested tags. And another point is a little question about adding of
nested logic to the existing tags against of new taglib
Oleg V Alexeev wrote:
AB Making it one with the current library?...
AB It can, but so can the html library. But for many reasons I go against
AB it. One, the simple fact that they're all working off the same basic
AB premise, the same relationships that the html tags work off of. So if
AB
I think the real proof of concept was when the nesting extension
continued to work well after the multiapp changes.
It was a non-event because you guys managed to separate the tags and
such (let's call them view components), from everything else (the
servlet etc. Lets for naming sake, call
Well... there it is.
- Recreated package.html to be more consistent with the rest of them,
provide better developer docco etc.
- To get things done, simply created the tld struts-nested.xml file of
the others, keeping the docco. There's been all this mention of slowing
things down in regards
-
From: Arron Bates [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Friday, January 18, 2002 12:28 AM
Subject: Nested Extension - Committed
Well... there it is.
- Recreated package.html to be more consistent with the rest of them,
provide better developer docco etc
The Taglibs jakarta project ( http://jakarta.apache.org/taglibs ) is
more the place for these tags as it seems as though there's no coupling
with struts, just simply handy functionality. Which is what the taglibs
project is all about.
Arron.
Gerard Weatherby wrote:
I wanted to send email
This should be asked on the users list. They answer and debate this often.
You'll most likely end up running through your result set and populate a
beans in a list. Then it's up to your own primary key management.
Arron.
[EMAIL PROTECTED] wrote:
In a particular scenario im populating my form
I assume that the site update is the hany-work of Ted?...
Is sweet.
However the javadoc process or whatever has yet to be run, as the
Developer Guide link to the usual package.html docco to the nested
tag's is throwing 404's.
The mast-head is so much easier to read now. :)
Arron.
--
To
Sounds fine to me.
Arron.
Ted Husted wrote:
I'm not exactly sure what happened there, but if there are no
objections, I'll proceed along the lines outlined here:
http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg04760.html
-Ted.
Arron Bates wrote:
I assume that the site update
Sorry 'bout that, but that's all of it.
Only a change to the struts.xsl and the nested docco.
If you're hacking the stylesheet, then I can roll it back until your
go-ahead. Yes/No?
Arron.
Ted Husted wrote:
Arron,
Could you hold off any more Commits. I'm in the middle of heavy surgery
on
The tags use direct values or beans themselves to provide values for
offsets and such. Would be quite a bit of work to get them all to work
off bean properties instead, and there's the added decision of telling
the tag that it is to use the values of properties rather than bean refs
and
+1
Ted Husted wrote:
I agree that a beta based on the current nightly build is a reasonable
course of action for now.
My real regret is that we did not get a chance to cut a 1.1 release
before the last wave of improvements came done the pipeline. My concern
is that either the
(if any)
then do it the current way.
johan
- Original Message -
From: Arron Bates [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Thursday, February 21, 2002 1:19 PM
Subject: Re: Nested properties everywhere
The tags use direct values or beans themselves
Martin,
Can I get a simple example bean and markup of its various options, so I
can see how I have to get it nested?...
Ta.
Arron.
[EMAIL PROTECTED] wrote:
martinc 02/02/22 23:10:30
Modified:doc/userGuide struts-html.xml
Just a quick one to say that I think that this tag is a much more
natural fit than the original option tags.
Amazing what can be done in hind-sight.
Nested version works just groovy and is now in there also.
Arron.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional
It's not a final class in the nightly builds.
None of the tags in cvs are final.
A legacy detail.
Arron.
Jeff Goke wrote:
I am curious why the iterate tag is declared as final? I was writing a wrapper tag
to simplify the process of showing pages of information (since this is an extremely
How about the mechanism that comes with JDK 1.4?...
They've added an XML marshalling system to provide an alternative to
serializing objects. You can just pump a bean through the XMLEncoder and
you'll end up with an XML document. Get the same document and run it
through the XMLDecoder and
Currently, there's no example in Struts for use of the nested tags. This
should be fixed.
But to ask the committee's opinion on how... it can be anything from
just packaging up my existing monkey example, or make another which is a
little more straight :)
Another option is to adapt one of
2
That way there's less room for people feeling their intended effort
missed the boat.
Arron.
Martin Cooper wrote:
Through informal discussion, we decided to go to Struts 1.1 Beta 1 on March
4th, which is today. However, I've realised that I dropped the ball, and did
not produce a release
--
Vote:Struts 1.1b1 Release Plan
[X] +1I am in favor of the release, and will help support it
[ ] +0I am in favor of the release, but am unable to help support it
[ ] -0I am not in favor of the release
[ ]
Martin,
Something fuzzy happened here. I updated my CVS without seeing the fixed
status, and all other config files were fixed but the tiles one. I
checked in a change also, two commits shouldn't break something should
it?...
I checked in something last night, that I think missed your beta
+1
Is the beta process here a lock-down, only code going into the full
release on the version being direct patches?... or is code being
committed as usual, just winging it without trying to upset the apple
cart?...
Just curious.
Arron.
Martin Cooper wrote:
First of all, I sincerely
It fails to compile here consistently?...
Compiles fine for me. The NestedIterate does the same thing with its
super.doAfterBody() method use also, it's a surprise that it would only
fail on this one.
Arron.
David Winterfeldt wrote:
v1.3 of
Fixed.
You were right, old servlet.jar did it.
It puzzles me that the other iterate tags work in this scenario, as the
container would have to write in these methods that it wouldn't know
about. Anyways...
Arron.
David Winterfeldt wrote:
I wondered if it might be something like this, but I
Rob,
It implements NestedNameSupport, which is an extension of
NestedPropertySupport. So in a way it does implement it. The statement
is therefore somewhat redundant in the other tags that implement
NestedNameSupport.
Currently, the tags that you can get the name reference from, you can
get
A bug was fixed in BeanUtils a couple of weeks ago after the lock-down,
it's there now and I'd like to use it to make the nested iterate work as
planned when using Map collections.
Is the reference in the commons code going to stay the same, or next
phase going to take new code?...
Craig, I
On the defense of trees in Struts...
...current Struts 1.1 is actually an absolute honey to make trees.
really. One step at a time, and it's a walk in the park.
A while back (a month), the nested tags were made to penetrate a dynamic
include, which allows for true recursion. Which means... oh
This is a user mailing list kind of issue, but anyways...
What happens when you return the Object[] (myArrayList.toArray())
instead of the ArrayList itself?...
Because if you're using Struts 1.0/1.0.1 the ArrayList won't work, but
the Object[] will. Struts 1.1 can run the ArrayList directly.
Yes.
Complete tutorial to create trees with Struts here...
http://www.keyboardmonkey.com/pilotlight
Arron.
Jean Fotovat wrote:
hello community,
has somebody implements a treeview on struts framework ?
thank you
jean fotovat
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For
In a Struts distrib after 15th of January this year.
I assume that you're trying to do something with the nested tags?...
Arron.
Jean Fotovat wrote:
hello community,
where could i find struts-nested.tld ?
i don't find it in struts lib. Is it provided with struts or nobody hears about that ?
Message-
From: Arron Bates [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 01, 2002 10:45 PM
To: Struts Users Mailing List
Subject: Re: Check this out!
Anyone would think that trying to get an opinion on something is an
uphill battle. :)
Instead of creating an entirely new tag, can you take
-
From: Arron Bates [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Cc: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Tuesday, April 30, 2002 3:05 PM
Subject: Re: treeview...
Yes.
Complete tutorial to create trees with Struts here...
http://www.keyboardmonkey.com/pilotlight
Correct. :)
Arron.
Struts-dev Newsgroup (@Basebeans.com) wrote:
Subject: OT: Re: increased JavaScript support in the link tag.
From: Jose Quinteiro [EMAIL PROTECTED]
===
Phase Web and Multimedia wrote:
After some deep thought...
(any HHGTTG fans out there? :)
What's HHGTTG not familiar with
Interesting idea. But I'd really like to get 1.1 out the door before
adding lots of new functionaltiy ...
Not a problem.
One of the things I learned, in watching the development of JSTL, is that
tags with lots and lots of optional attributes, and different operating
modes, can be really
Depends on the type of indexed getter/setter you're using.
public String getMyIndex(int i) {}
public void setMyIndex(int i, String value) {}
...the setter will be called in this case, but in this instance...
public Object[] getMyIndex() {}
public void setMyIndex(Object[] obj) {}
...the setter
And this is a user-list type question, so I've forwarded there.
Arron.
Arron Bates wrote:
Depends on the type of indexed getter/setter you're using.
public String getMyIndex(int i) {}
public void setMyIndex(int i, String value) {}
...the setter will be called in this case
The resources page is getting to the unweildy stage. Are there any
thoughts to pruning it in the future?...
I get twice as many referrers from Ted's site than jakarta. It looks
like Ted's just using the same XML document (besides them hot! and
new! bits ;).
Sounds like we can just prune
No, they don't have to stay in session, but it requires some help to get
the collections to tow the line. I've just created these collections,
and having the discussion on the commons project at the moment to get
them included into the project.
Here they are, but there's no docco yet.
Please note that beginning 2002-June-30, any page linked as a Struts
Consultants on the Resource page must specifically mention that they
offer Struts consulting. Listings that do not reference Struts will be
removed.
+1
Please note that beginning 2002-July-31, any page linked as being
+1
Arron.
Ted Husted wrote:
James is a longstanding member of the Struts community and has been
submitting and vetting a good number of patches for Struts 1.1 beta 1.
He's been distributing and maintaining his own Struts add-in (the
Console) for some time, and has shown he can manage a public
Just curious as to the applicability of the Errors an Messages tags in
the nested context...
Because the nested tags use the one bean reference, I'm finding it hard
to visualise using these tags within context. In the original tags,
everything was an island, so it was all fine, but nesting
That all seems cool, and if the test works, all the better :)
To confirm what's happening there...
It's fetching the nameList.value property off the same bean as the
text fields. To read the markup, the messages and errors would then be
calling on the same property. Internally the name is being
The 'nameList.value' is being used to lookup of the
messages/errors that were stored under this in the
ActionMessages. ActionMessages has an internal Map
and uses a key (normally the property name and there
is also GLOBAL_MESSAGE constant) to store
messages/errors associated with that
If the tag implementation (not including release()) modifies the values of
properties, then yes, we're in big trouble. This is the case I've come
across before.
I thought we had caught all of those, but want to make very sure.
For example, if the second use of a tag sets the same
Meanwhile, I've set up a diff section in the release notes with
pointers to every thing with 1.1 features or deprecations, that could
then be used to help create the 1.1 doc section.
http://jakarta.apache.org/struts/userGuide/release-notes.html#diff
AFAIK, the JavaDocs are all
One thing we do give up (I think) is the implicit nesting of form field
names (specified in the property attribute) inside the variable name of
the form bean itself. I guess the same is true of the with-like
facilities of the entire nested tag library.
It will be interesting to see if we
Craig R. McClanahan wrote:
Can't you just embed your bean:write tag inside a pre element and get
the same effect?
Craig
pre opens a can of worms if the designers/managers are picky. For one,
it roots the browsers ability to word wrap. Use a regex in your action
code or some funky tag and
Thomas L Roche wrote:
WebSphere Studio has Struts tooling, so we'd like to put a
link-and-a-blurb on
http://jakarta.apache.org/struts/resources/guis.html
How should we do this?
Ask nicely. :)
...and log a docco enhancement in bugzilla.
Arron.
--
To unsubscribe, e-mail:
Craig R. McClanahan wrote:
On Thu, 24 Oct 2002, Arron Bates wrote:
Date: Thu, 24 Oct 2002 02:20:12 +1000
From: Arron Bates [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: HTML formatting of newline characters
For one, this is a struts-user mailing list type question.
But give this a bash...
nested:iterate property=variablesThatProducedErrors
nested:write property=name/
nested:write property=value/
/nested:iterate
...the nested tags don't need the name properties in the child tags.
It's all sorted
EmailUser?...
...smells like some moron hasn't configured his webmail properly :P
I looked at this one too, and came out with similar feelings. I think this
needs the eyes of our resident Keyboard Monkey, if he's around.
Calling all Keyboard Monkeys... We need your help...
Job done.
You'd
[
...cut (there was probably copyright issues with copying
that much of the spec :)...
]
I believe these tags are OK. (Disclaimer: I am by no means a nested tags
expert!) In effect, the nested tags do cache the property values, as you
suggest they should, just not in the way you might
--
Vote: Struts 1.1-rc1 Release Plan
[ ] +1 I am in favor of the release, and will help support it
[X] +0 I am in favor of the release, but am unable to help support it
[ ] -0 I am not in favor of the release
[ ] -1 I
Peoples,
I'm waiting on a call in the post below about the nested tags. I know they're
not everyone's favorite component, but I do need committer attention to form
the game plan as it's not the typical bug fix.
It's hard to form a consensus opinion on the one response I have.
Copied below for
Failing responses from people who are actually familiar with the nested
tags and your changes, then I think you'll just have to use your own
judgment. I had to make a similar decision recently wrt the Struts-EL
tags. Test your changes as much as possible, and try to get some
feedback
[...cut...]
http://issues.apache.org/bugzilla/show_bug.cgi?id=18066
Arron (or Antoni). Does it seem like there would be an easy patch
here? Would specifying the type be a reasonable workaround? -- at
least until we can fix it properly in the next iteration.
If we can swat these two, we
-1
Two weeks seems a little tight.
I only say this because the change to the nested tags after RC1 wasn't the
smallest of changes, and I personally feel a little nervous that it would be
shoved out the door with only two weeks on a release. It was a big fix to get
Tomcat 4.1.x going with them,
Already voted. IDEA is being severely robbed, IMHO. And 3000 odd votes from
various users at keyboardmonkey.com would look suss. :P
Eclipse has more users, so I suppose it has to give in, but to JBuilder as
well!??... nah. doesn't bode well.
Arron.
Ok, now that I've got your attention ;)
What if we compromise on 3 weeks? I understand the tag testing issue but we
shouldn't be holding back because of documentation issues.
It's all about getting the tags and other changes tested more completely.
(what's documentation? ;)
I can very munch understand something happening for
Isn't JSF just another spec like Servlets and JSP?...
Any vendor can make a JSP impl based on the spec, so they should also be able
to make a JSF impl. Struts-Faces allows Struts to play with any compliant JSF
implementation. If it doesn't we get to go Craig-bashing. :)
Struts plays with
+1
This puppy's more than stable enough to cut another RC.
I understand why Martin wants the FileUpload to go through the wringer, and it
should, but it's already the most spiffy-est upload component there is. Beta2
of FileUpload has my vote for RC2.
Somehow in all this I get the nagging
Struts is a product of the Apache Software Foundation...
[cut]
...we can learn from our mistakes and cut a release
whenever we add a feature that people can put to good use (instead of
after we have added a large set of new features).
-Ted.
Couldn't agree more (hence my +1), new RC
I've spent some time fixing (recoding?) a proprietary framework which worked
exactly like JSF's component driven nature (In fact, I wrote their grid
control. Craig- all you had to do was ask :P ). Let me say it has some very
clear appeal to the developer, even though that implementation was very
Once a patch is logged against the bug, it waits until a committer has time to
take it on and apply it. This patch will most likely be applied after 1.1,
and before 1.2.
OT: Solnet thrown you into another Struts project?...
At least you don't have to play with RHE's Struts fork we used at
And IDEA may be the best developer's UI ever invented.
Ted, would you mind comparing IDEA to Eclipse a little
bit, if you have time? Not a full blown feature-by-feature
review, just highlights.
I've used the latest Eclipse, and it's ok, but it's not IDEA.
Eclipse has many of the features
-0
Only because there is a bug raised against the nested tags where it's dropping
a reference for included/tiles files in some strange instance.
I would have liked to have confirmed, patched and squished/handled it, but my
last few weeks have been crazy with moving to the US. I wont be able to
Edgar P Dollin wrote:
Everyone has preferences but in my opinion JSTL doesn't hold a candle to the
nested tags, especially customized nested tags.
I do agree however that JSTL for nested tags is not that important. It does
help in environments where there is ZERO tolerance for JSP
--- [EMAIL PROTECTED] wrote:
Back in September, David Karr was threatening to do Tiles-EL and
Nested-EL. I
see that the Tiles-EL has been committed, sweet. Nested-EL seems to be
missing. David, have you started working on Nested-EL? If so, how far
off is
it from being complete?
Peoples (Dave?),
Just curious as to how quickly the EL tag logic identifies that there is in
fact stuff to evaluate?
Any micro-benchmarks?
If there's no real overhead, especially for properties provided without
expression, to just use them in the tags as-is. Or at least the nested tags
where
+1 for the TLP
+1 for Craig as V-Pres.
Arron.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
, then I'll knock on the PMC door as
required.
Cheers,
Arron.
The response to this vote has been unanimous, with all proposed PMC
members responding except for two: Arron Bates and Don Brown. I have
attempted to ping those two directly, but have not yet heard back.
The next board meeting
Guys,
Just got the summary email from the Apache board meeting, and the Struts
proposal went through with flying colours.
Congrats guys, really. So much never-ending quality work.
I guess that with everyone else out driking Irish alcohol I was the first to
see the email, and I got to be the
--- Joe Germuska [EMAIL PROTECTED] wrote:
Whether the classic and el taglibs are one chunk or two isn't
hugely important to me either -- I would prefer that this decision
be
made by developers who've done more work on that code to date.
However, I did find that when I patched
100 matches
Mail list logo
