The bean spec has very little to do with the way most people use beans
in a server side environment. Beans were originally intended , as the
spec discusses, as UI components. That's not what they're generally
In the case of WebKit, the Cans are just classes that can be
instantiated when they are needed (requested) and they will remain
persistent on the server for the life of the object that they are
requested for (session, application, etc.), so that subsequent requests
can use the same Can.
In other words, ignore the Sun bean spec.
Chuck, I'll get you an example that will make all this clear.
Chuck Esterbrook wrote:
> Jay Love wrote:
> > > The more I think about indentation, the more dangerous it seems: especially in an XML setting where tools may not always respect whitespace. It seems like indentation is enough trouble in plain text files, especially when tabs are intermixed with spaces. Besides, PSP files should contain a minimum of code, just some
> > > basic display logic. When using JSP, my experience has been that it is best to put all or most of the business logic in JavaBeans. The JSP files then contain mostly a bunch of <%= whatever %> constructs with some loops for iterating over data.
> > We have a bean type of system now, but it's not in the main development
> > tree yet. I'm calling it "Cans", as in Cans of spam, much to Chuck's
> > dismay. Someone please come up with a better name.
> Actually, I'm struggling more with the concept than the names. I've read the beans spec and I wasn't all that impressed. There *are* some good ideas there, although none of them are original.
> In terms of name, I think it's interesting that the spec immediately clarifies that a bean is a component in the common RAD sense of the term:
> "A Java Bean is a reusable software component that can be manipulated visually in a builder tool."
> Also, the 3 most important features according to the spec are: 1. properties, 2. methods, and 3. events.
> 1. is just recognizing that getX() and setX() methods indicate properties. No big deal there. You could write any kind of builder tool that would do that for any object.
> 2. methods? Gee, I thought that was OOP! Apparently, though, that's "Beans". (heavy sarcasm)
> 3. Events. Sure, I believe in events, but check out the mess they make of them:
> "We can solve this problem by interposing demultiplexing adaptors between each source and the listener, where each demultiplexing adaptor takes an incoming method call of one name and then calls a differently named method on its target object."
> It occurs to me that if Jay's Cans aren't centered around the above concepts, then maybe Cans aren't really Beans. On the other hand, maybe he has a grander vision for them.
> It's also notable that Beans have at least 2 constraints we don't: lack of multiple inheritance and interoperability with OpenDoc, OLE/COM/ActiveX, LiveConnect.
> In terms of architecture, I'm not convinced that "cloning" the Java Beans design is a good thing for Webware.
> To be fair, I have not yet researched Enterprise Beans, or beans in the context of JSP pages. I'll do that this week.
> At http://webware.sourceforge.net/JavaBeans.html you will find my distilled version of the spec (e.g., my notes), with my words in italics, as well as links to beans and enterprise beans.
> Webware-discuss mailing list