I think that Cocoon *is* on a cutting edge. It is altogether a very different design paradigm, and it is still feeling its way. I am quite confident that the basic elegance of Cocoon's pipeline/component approach is here to stay. I'd also put my money on Flow and continuations. Beyond that, some of these other pieces will succeed and others won't.
A big part of the equation is documentation. The wiki and docs for sitemap design, components, and design patterns are all good. The newer pieces are understandably less documented. Like a lot of things, open source documentation is a bootstrapping process: better documentation on a component means that more people will learn to use it, which means more users, which eventually means more experts, which then translates to even better documentation. So new components with little documentation take a while to get going. And without good documentation, it's hard for most potential users to determine a tool's viability.
-Brent
On Apr 28, 2004, at 5:50 AM, Derek Hohls wrote:
And in the beginning, Stephan Mazocchi created Cocoon. It was based on XML - Programmers used Java and Users used XSLT - and it was simple but good. And it worked and applications were delivered. Everyone understood and everyone was happy.
And then the Users spoke up, saying that Web Publishing was complex and that more Features were required. And so the Pipeline and Pipeline Components and The Sitemap were created, and they too were based on XML and Java and they were good. And, because more Logic was required, XSP was created - a Marriage of XSLT and Java - and it too worked, and applications were delivered. Although some scorned XSP, preferring the purity of the Pipeline Component, most understood and most were happy.
And the Users demanded more; saying that Web Publishing was not enough
and that Web Applications, requiring yet more Logic and Functionality,
were required. And so were created Cocoon Forms (oft-called 'Woody', to
the confusion of the uninitiated) and Flowscript, based on JavaScript.
While some now wondered about the introduction of yet another Language,
some understood and some seemed happy.
But many still spoke up, saying that Cocoon was but one Framework among
many and so insufficient on its own to deliver Real Applications. And
so a great Babel of other languages and tools were taken up and other
approaches, based on the Old Ways of Templating Languages (up to now,
considered a heresy amongst the Cocoooners), were incorporated. Few now
understood the Great Cocoon Universe and many were confused. And the
Users wondered why Developers spent all their time learning these many
and arcane Ways and why applications took so long to deliver...
OK - aside from the rather poor parallel to the original, I guess I am beginning to be concerned about how much is seemingly required to get going and __keep__ going with Cocoon-centred apps.
A brief time capsule for background: I have worked with Cocoon since
version 1 and, while I have not made extensive use of many of its
features, I have been happy to know that these are there and can be
called on as my needs grow. The primary reason I started with Cocoon
was that it gave me a way to readily work with XML, which allowed me to
decouple HTML layout from source data. This single aspect meant I would
never have to handcode websites again and made templating approaches
such as JSP and ASP archaic and redundant (and I am constantly surprised
they still seem so popular). This was rapidly followed by the need to
publish database data; again, the decoupling provided by XML and the
Cocoon framework was a pleasure to work with, and ensured effective,
even parallel, application development.
I am now at the point where I am faced with the possibility to design
and deliver a large, complex, long-term, database application via a web
front-end (as opposed to a traditional client-server front end, written
in a RAD GUI, which is what I have done up to now). I believe that a
web-based solution is the correct long-term approach, even if some of
the technology seems a little clunky right now. To date I have been
content with using XSP / ESQL for small, interactive DB apps, and I
_had_ thought that I should now have to learn Cocoon Forms (or Woody)
and Flowscript, xReporter and, possibly, Java Beans for logic - somewhat
of a learning curve for me but also not impossible. However, recent
discussion on this topic shows that some developers believe a whole slew
of _other_ technologies (outside of Cocoon) need to be learnt and
incorporated before one even starts with the design...
So, my question is:
*** Which solid, well-documented approaches, using primarily Cocoon-based mechanisms, exist to create complex database applications? These approaches need to be at least documented in a detailed article and, preferably, in a well-written tutorial/guide.
** My observation is - if such does not exist, and I still want a web front-end, should I be abandoning Cocoon and going for some old-style, template-based approach, using other frameworks such as Struts, Hibernate, Velocity, PHP etc. etc. [and, of course, the same question applies here - is there something well-documented which lays a solid, detailed foundation/guide for taking a developer through all this?]
* My last thought is - if there is no well-explained answer to either
of the above, does this mean we are on the cutting edge when it comes to
this type of work... because then I will at least know where I stand and
can, hopefully, decide accordingly!
Thanks in advance for any and all observations/comments. Derek
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- http://www.brentfitzgerald.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
