> <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: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
