[collections] - Few more collections for the masses... (important for Struts view objects, maybe other projects)

[Arron Bates <ar...@keyboardmonkey.com>]

Peoples,

Have a couple of handy collections ready to fly, built and tested.. I 
couldn't find duplicate functionality in those already there, but you 
guys are the better judge of that.

---
Problem (if you want the reason for their existence)...
Struts (maybe you've heard of it) has this neato ability to create a 
requested bean for an action when it comes in from the request from the 
browser. Populates the top level bean really well. It will also populate 
any other object you put in its path. Great for most things. But... 
along comes nesting which allows for some wild data structures, and it's 
hard to assume their form when they come in, so this place holder thing 
gets a lot trickier. Add to this the fact you can now do funky trees, 
and it all goes to hell.

Easily solved with a server with at least gig of ram (virtual ram?) 
because you can just leave it all in the session. Some people don't take 
it all that well when I tell them this. Stroppy sods. So...

---
Solution (what the collections are)...
If the collections of objects and such could be constructed and set no 
matter what index or mapping they're built against, it would all work. 
This is what the collections do. Build objects and put them at whatever 
spot is asked for. Pass the bean's class (argument details optional) to 
the constructor, and it will build said object if need be. For the map, 
if n object is requested for a key that's not there, it will create the 
object, store it at the key and return the object. Sweet.

List does much the same thing, but with a couple of issues. If an object 
for an index is requested, the collection makes place-holders out to 
that index, creates and sets the new object. If more objects are set at 
lesser ones, then it swaps the place-holder for the new object. This 
potentially leaves place-holders in our collection. In the Struts use 
case, all things being equal, all the positions should fill up. But if 
they're not, then there's a "clean()" method provided to rip out all of 
the bad place-holders leaving a clean collection, ready to play.

They're proxies, so you pass them your concrete java.util.Map, or 
java.util.List implementation in the constructor, and they'll proxy in 
and out of that.

----
If everyone thinks they're cool, as I said they're ready to go.
Except I'm without the kudos to commit them to the commons CVS. I'd add 
them to Struts, but people get mad, red tape, have to take out the 
trash, you know the deal.

So either a committer who wants to support them commit them, or vote me 
into the tribe (my preference :)  I am a nice guy though. really).


Arron.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections] - Few more collections for the masses... (important for Struts view objects, maybe other projects)

[Arron Bates <ar...@keyboardmonkey.com>]

Actually, finished the javadoc during lunch, but anyways...
But I did miss the source code. Just wanted opinions first (or commons
commit kudos?). But the people want code, so here tis...

Obviously, list and map implementations respectively...
http://www.keyboardmonkey.com/next/ReserveList.java
http://www.keyboardmonkey.com/next/ReserveMap.java

As for the approach... ActionServlet only knows about the root bean
because it's configured. Setting up all the properties internally, it's
still victim to the constructor. As for nested beans, the job is easily
done by creating the tree of empty shell objects waiting for their
updates. This is flawed as it's hard to do funky things like the the
lists and such with the nested tags make truly easy (was that a plug?).
Any simple nested bean (ie: simple plain nested property), the parent
bean has to take care of the construction of that, but it's only a tiny
thing. The collections are the tougher part. All these collections do is
make sure there's a valid object waiting to take the incomming data. The
bean internally knows the type of the objects the childs beans have to
be, so it tells these collections the type of bean they have to create
when needed.

The List one is special, in that before you go to use it for your
business logic, you have to run it's "clean()" method to make sure
there's no AWOL place holders.

I found out when I went to test it, is that it forces you even more to
make the beans stupid view objects. It all goes to hell real quick if
they're trying to manage their state also. Dammit. Oh well, pros and
cons... :)

They're also a snap to implement. Just pop your List or Map
implementation into them, and return them from your collection property.
If the List or Map interfaces are to be avoided for some reason (like
something funky ArrayList does or whatever), then you can just wrap it
for the purposes of the indexed or mapped property methods.

Anyways, it's all there in java code...


Arron.



Will Jaynes wrote:

 > Arron,
 >
 > I assume that posting at 4 in the morning your eyes were closed and
 > you missed attaching the code. I'd love to see it.
 >
 > This is just the kind of thing the nested tags need. I've been moaning
 > about the required session scope. But it isn't clear to me how the
 > ActionServlet can know what kind of object(s) to construct if they
 > aren't already in the form. So I'm anxious to see how you're
 > approaching it.
 >
 > Regards, Will
 >
 >
 >
 > Arron Bates wrote:
 >
 >> Peoples,
 >>
 >> Have a couple of handy collections ready to fly, built and tested.. I
 >> couldn't find duplicate functionality in those already there, but you
 >> guys are the better judge of that.
 >>
 >> ---
 >> Problem (if you want the reason for their existence)...
 >> Struts (maybe you've heard of it) has this neato ability to create a
 >> requested bean for an action when it comes in from the request from
 >> the browser. Populates the top level bean really well. It will also
 >> populate any other object you put in its path. Great for most things.
 >> But... along comes nesting which allows for some wild data
 >> structures, and it's hard to assume their form when they come in, so
 >> this place holder thing gets a lot trickier. Add to this the fact you
 >> can now do funky trees, and it all goes to hell.
 >>
 >> Easily solved with a server with at least gig of ram (virtual ram?)
 >> because you can just leave it all in the session. Some people don't
 >> take it all that well when I tell them this. Stroppy sods. So...
 >>
 >> ---
 >> Solution (what the collections are)...
 >> If the collections of objects and such could be constructed and set
 >> no matter what index or mapping they're built against, it would all
 >> work. This is what the collections do. Build objects and put them at
 >> whatever spot is asked for. Pass the bean's class (argument details
 >> optional) to the constructor, and it will build said object if need
 >> be. For the map, if n object is requested for a key that's not there,
 >> it will create the object, store it at the key and return the object.
 >> Sweet.
 >>
 >> List does much the same thing, but with a couple of issues. If an
 >> object for an index is requested, the collection makes place-holders
 >> out to that index, creates and sets the new object. If more objects
 >> are set at lesser ones, then it swaps the place-holder for the new
 >> object. This potentially leaves place-holders in our collection. In
 >> the Struts use case, all things being equal, all the positions should
 >> fill up. But if they're not, then there's a "clean()" method provided
 >> to rip out all of the bad place-holders leaving a clean collection,
 >> ready to play.
 >>
 >> They're proxies, so you pass them your concrete java.util.Map, or
 >> java.util.List implementation in the constructor, and they'll proxy
 >> in and out of that.
 >>
 >> ----
 >> If everyone thinks they're cool, as I said they're ready to go.
 >> Except I'm without the kudos to commit them to the commons CVS. I'd
 >> add them to Struts, but people get mad, red tape, have to take out
 >> the trash, you know the deal.
 >>
 >> So either a committer who wants to support them commit them, or vote
 >> me into the tribe (my preference :) I am a nice guy though. really).
 >>
 >>
 >> Arron.
 >>
 >>
 >>
 >> --
 >> To unsubscribe, e-mail:
 >> <ma...@jakarta.apache.org>
 >> For additional commands, e-mail:
 >> <ma...@jakarta.apache.org>
 >>
 >
 >




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>