cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: sexy open source
Date Thu, 15 Aug 2002 14:27:24 GMT
> <OK_now_im_getting_personal_others_should_skip_this_tag>
> Honestly, I went through stjude.org, nice idea, but if
> you'd decipher my nick, I'm quite uncomfortable with
> basic research exploiting animals with little or no
> actual use at all for all those unfortunate children -
> probably dictated by industry-driven NCI and others. I
> hope you work to catalogize only really valuable
> clinical research e.g. non-invasive statistical
> environment observation to help to discover most
> valuable prevention possibilities. Worth a quarrel
> between us...
> Moreover, I'm (fortunatelly) not the one giving money
> out here. Nevertheless, although miles away, you are
> looking like to be a suitable consultant for us with
> enough spare time. Wait till I discuss your possible
> involvement with those sitting on cash, then I'll
> contact you directly. Quick but informed expertise is
> awaited.
> </OK_personal_tag_is_over_though_not_well_formed>

I realize this is very far off topic, but this is important so please bear
with me: I think you may have misinterpreted what St. Jude does.  It is the
leading institution in the world for research into Childhood diseases.
Everyone that is treated here is treated regardless of their ability to pay,
often for free.  If you ever get a chance to see a 3 year old kid with
operational scars all over their head, attached to an chemo IV drip looking
as happy as can be because they've had just one more month to live you will
never, ever, again feel sorry for the sacrifice of some animal in the name
of clinical research.  Most of these kids would not have a chance to live at
all if it where not for St. Jude; we are now tracking 30 year survivors.
Basic research is critical to the 1000's of children that we treat each
year.  Yes many animals may die in related experiments.  They will do so
painlessly and humanely.  Many children will also die because we have not
yet figured out how to save them. The clinical research is invasive, dirty,
hands on real life medical research; that's the way lives are saved.

> Going on 

Yes please... [snip]

> You mean J2EE was too big calibre for your
> requirements but after you got into it, you wanted not
> to give up on possible features? 

In this particular case we probably won't have to scale to the point that we
really need most J2EE features for another year or so.  We could have held
off on the J2EE learning curve until the rest of the application was more
mature and stable. In particular, when you realize that many of our
developers are contract and that they will have moved on by the time we
really need the J2EE features.  We paid to educate them on something we
didn't necessarily need at the time.  OTOH, we did get a core group of
developers up the learning curve and we now have a running J2EE system to
eliminate most of the learning curve for new developers.

> Accepted. Seems like solutions implemented in Cocoon
> are, at this stage of Cocoon in general, hardly
> universal enough to be taken over (even in part) by
> another business models. That's the deal, I think.
> Cocoon is easy to customize, but then it is hard to
> find reusable patterns, till some next evolution
> comes. 

I'm slowly starting to see a generalized architecture fall out of the work
we do.  It's rather different from what seems to be a main thrust of Cocoon
(XSP), and it may be worth outlining:

1) exploit the ability of Cocoon to chain transformations together and
separate transformations into separate passes of object assembly and output
rendering;

2) separate and encapsulate the differing concerns of handling the
application work flow into well defined XML: request parameters; application
information (session level); object metadata specific to the current
context; object data specific to the current instance.  Use aggregation
(conceptually within a single generator, or explicitly within the sitemap,
exploiting caching) to combine these for the object assembly pass.

3) resolve (using XSLT) the combined application state data, session state
data, request state data, object meta-data and object data based on the
users current authorization into an abstract object tree populated with all
information required to generate any output.

4) render the object tree to the currently required output format.

This architecture exploits the functional programming model of XSLT and uses
meta-data to essentially create rules about how to resolve and render the
current object tree.  If you "get" functional programming you will see that
this keeps the basic processing model pretty simple and eliminates
non-standard processing extensions (read XSP) from the flow.  If you get
stuck on procedural approaches and can't see how you'd ever give up your
logic sheets you'll be missing much of the power of XML and XSLT in my
opinion.

We didn't start out with architected XML for each of these concerns and so
hadn't thought about when and how to persist each of these pieces of
information in a standard way.  By instead architecting ways to explicitly
handle the differing dimensions of information I think we can build a much
more generalized way of generating web sites from business objects.  The
work on this architecture will generally fall out of our current work as a
prototype and start to get formalized for the next release in near the end
of the year.  If I get the chance I'll be posting more thoughts about how
this should look as we proceed. 

As it sits, we do have a pretty generalized object repository using standard
relational technologies that is portable to any ANSI standard SQL database.
We also have a fairly generalized application framework that is applicable
to data collection for areas that have to share information among many
diverse groups with very strict privacy, security and audit requirements.
The architecture has a high run time overhead so it's not a general way to
build high traffic volume web sites, but as I say, a more general approach
for solving some of those issues may fall out of it.


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message