Geoff Howard <[EMAIL PROTECTED]> writes: > Sent: Friday, August 08, 2003 6:22 PM > To: [EMAIL PROTECTED] > Subject: Re: [RT] Updating our marketing strategy > > > Hunsberger, Peter wrote: > > Geoff Howard <[EMAIL PROTECTED]> asks: > > > > <snip on Cocoon positioning/> > > > >>Related to positioning ourselves as glue/duct tape: > >>Speaking of J2EE, I think we are really missing the boat by > >>not offering > >>really dead-simple integration with EJB (even though so > many here are > >>waiting for its carcass). The fact is that EJB for now is > >>the reigning > >>king and needs a good front end. I know Cocoon works well > >>with EJB but > >>it isn't dead simple for a newbie to see how. > >> > >>Unfortunately, I am not currently using them and didn't even have a > >>container installed at home until recently. Anyone want to > >>work on some > >>examples/code with me? > > > > > Peter, > > Just saw a post from you and remembered I lost this one. > > > > > I've been starting to gather a little support for > contributing some of > > our stuff to the project. I know I can't do much of > anything soon, but > > perhaps could do a lot more come this fall. > > > > In particular, I've got some relational DB "Hedge > generator" code that > > might work well as an example: if you're familiar with Joe > Celko's (SQL > > for Smarties) set/subset algorithms for managing > hierarchical data in a > > relational database it exploits that structure directly to > produce XML > > hedges with roughly O(N) memory and processing time (in > proportion to > > the max hedge depth). (An XML Hedge is a collection of XML tree's > > sharing a common root.) > > > > The interfaces and abstract classes could be generally useful within > > Cocoon for Hedge production (and just need refactoring into > the Cocoon > > package hierarchy which I could in an hour or so if I get permission > > from my Boss). Working up a concrete implementation against some > > database would take a little more work. If you're ok with > just Session > > beans (no update, read only) I could maybe get an example together > > within a week or two if I get the ok. > > > > Would this be the kind of thing you're interested in? If > so, I'll push > > for permission to contribute it... > > This sounds great - more advanced than I was envisioning, but that's a > Good Thing (TM). Let us know if you have any luck. > > If that doesn't work, perhaps a simpler example of just getting a > reference to a Session or Entity bean within Cocoon and > producing some > xml out of it in a brain-dead way, or calling Session beans from flow > would be a good start. XSP would seem to be a very inviting and > intuitive way in for those used to JSP fronting EJB (which it > seems an > awful lot of people are).
Thinking about this last night it occurred to me that for any of this to work as Cocoon sample code you need to have an EJB container. Do we include a new build option to deploy as an EAR under JBoss (the option would perhaps be the path to the JBoss deploy directory)? Any other Open Source EJB containers to consider? I'm still trying to get permission to distribute the hedge code. It's most useful for building menu's or similar tree structures. Currently, (among others) I've got a page that allows tree traversal of tissue sample storage locations for assigning them (see attached screen capture). Since I'm not yet using flow it would be up to someone else to tie this into a flow app. The code I might be able to contribute would just call the EJB to get the tree structure XML, and then bounce it through a couple of XSLT to produce a HTML tree. Our current code requires JavaScript, but a flow version could round trip the tree traversal (node expansion/collapse) to make it cross browser compatible and demo flow? Again, someone would have to hook that together unless you want to wait until next year when we start work on this... We have other menu code that might work with flow. Again just expanding collapsing tree structures. If you'd prefer to attack something like an Organization, Application, Service admin menu hierarchy that would be doable (and perhaps more applicable to the general Cocoon user base)? Flow in such a case would be pretty straight forward: just page selection based on which branch of the tree was selected, though again you could round trip tree expansion and collapse.
<<attachment: Capture_1.gif>>
