Thanks for those encouraging words, Ted :) But... a) I wasn't lying. It's as complete as it can currently get without developing brand new tags and functionality for it which can leverage the nested context specifically. Current code allows for everything Struts provides which is relevant to the nested context. Only thing on my cards of any importance is to hack into the PropertyUtils code to get indexes working on implementations java.util.List.
b) This week I've been doing nothing else but creating some docco for the extension. Finished a very thorough primer tonight which is now in the hands of my wife who's a copywriter to make sure it's the level that I intend it to be. It will be live on my site in a couple of days. I've now moved on to completing a by-the-hand tutorial which will go via the same process. I thought that being a developer list the stuff which I provided in the Package.html docco would be enough to get developers hooked enough to take it on, but I'm taking that next step and removing all doubt. In regards the "kitchen sink" issue... your point is fair. Just let me know. Before I wrote the extension I *really* needed to get lists working properly (sounds like sven needed it too :). At that time there was no indexed option. Reading the users mailing list I noticed a real need for it. So when I arrived at a solution which more than solved the problem, I felt that Struts or its users would really jump at the functionality. It's no issue to me if it's not taken on. That means I could close the source, package it up in a box to sell it! (then slowly take over the world to hopefully one day be subject to an anti-trust case) :-D As for the "hook for maintaining" it... It'll keep working unless you guys change what the "name" and "property" attributes do in your current tags :) ...or if you add another attribute or take one away, it's just an extra tld to update. Arron. Ted Husted wrote: >>From my perspective, the nesting beans library is still relatively new. >Once we add it to the CVS, we are on the hook for maintaining it. Arron >recently said he was really, really done this time, but, personally, I'm >waiting to see what happens (or doesn't happen ;-). I'd also need to >carve some time to create developer's guide compatible with the rest of >the Struts documentation. > >Meanwhile, I personally do not believe the Struts should be a kitchen >sink and try to be all things to all people. A framework is a place >where you can build things, as Arron has built the nesting tags. The >important thing is that the framework allows for developer extensions. >We go to the effort of providing links to extensions like Arron's on a >resource page, so people can pick and choose the tools they need for >their project. > >In this sense, Struts already provides all the generic functionality >used by everyone for every project. You're already using the nesting >tags, are you not? > >Sven Beauprez wrote: > >>hey guys, >> >>I am just wondering why MonkeyStruts isn't standard available in the Struts >framework? >>Without this package, it would almost have been impossible to implement most of the >>requirement of the project I am working on. >> >>Do you plan to add it to the next release of Struts? >>(my vote doesn't really count here, but I woul definitely say +1) >> >>Yes i downloaded it and yes it worked fine as if the functionality was in Struts >itself, but isn't a >>framework supposed to have it all? I mean all the 'generic' functionality that can >be used by >>everyone for every project? >> >>greetz, >> >>Sven >> >>-- >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >> > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
