Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Date: Thu, 29 Apr 2004 02:46:17 +0300 (EEST)
From: gounis@osmosis.gr
To: users@cocoon.apache.org
Subject: Re: Cocoon: Language Babel -or- Database Development Platform ?
In-Reply-To: <66ED677D-994F-11D8-BAB7-000A95A556A2@highpoweredmutant.net>
Message-ID: <Pine.LNX.4.44.0404290221000.13244-100000@zeus.osmosis.gr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi

we are using cocoon 2 years ago just for publishing static web sites
and we think that its THE perfect choice for that.

further more we have try to use cocoon as a Database Front-End-ReadOnly 
interface. And here cocoon's power to handle SQL select queries in the way 
Query --> xml --XSL--> [presentation] make it THE perfect shoice too.

the problems start when we have to use cocoon to handle user input
Forms / SQL Update queries etc.
and all this because:

- there is no standard (yet) form handling mechanism, CForms maybe will 
give 
a solution but they are to complex and not Production-Ready.

- there is not a standard mechanism to make Database updates. 
ESQL is very powerfull (and simple) for select queries but not for update/delete
Action, some time ago all the people here talking about actions, now 
noone.
Flowscript sounds revolutionary but too complex and to "young".

- and there is no IDE to work.
all the new cocoon technologies(cforms/flowscript) are targeting to solve 
common problems in development of BIG webApplications, but the question 
here is: "When you have to work an a BIG project is it possible to work 
without an IDE?" Has anyoune try to test for example DotNET studio in 
web application development? everithing there are a piece of cake not 
because the technologies this approache offer but because the IDE.

- its not so easy to debug a web application. log files are so verbose 
that become huge and difficult handle in few requests

let me notice that we do the 90% of our web development using cocoon 
but we also think that something is missing

--stavros 

On Wed, 28 Apr 2004, Brent Fitzgerald wrote:

> Derek, you've elucidated what I'm sure is a recurring tension for many 
> cocoon users.  I really identify with you.  My group has been using 
> Cocoon for a little over a year now to publish a huge set of XML 
> content, translated and localized for several languages.  Cocoon has 
> been an excellent choice for such a project.  But if I wanted to take 
> it further, like if I were to develop a "real" web application like you 
> describe, I know I could do it with Cocoon, but the path is definitely 
> not so clear.  Suddenly Cocoon feels stretched, out of place, and less 
> elegant.  Maybe I am wrong.  Maybe Cocoon is just perfect for such 
> applications.  I would like to think so, but I certainly haven't seen 
> examples, and the existing documentation feels pretty thin.
> 
> 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: users-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail: users-help@cocoon.apache.org
> >
> >
> >
> >
> --
> http://www.brentfitzgerald.com/
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
> 
> 


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