cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [RT] Updating our marketing strategy
Date Tue, 12 Aug 2003 14:31:57 GMT
Geoff Howard <> writes:

> Sent: Friday, August 08, 2003 6:22 PM
> To:
> Subject: Re: [RT] Updating our marketing strategy
> Hunsberger, Peter wrote:
> > Geoff Howard <> 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.

View raw message