cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mats Norén <m...@alma.nu>
Subject Re: [FFT] Kitchen Sink
Date Wed, 14 Dec 2005 14:24:22 GMT
Hmmm...have you looked at JBoss SEAM?  ;)

Leo Sutic wrote:
> I pretty much agrees with what Berin has been saying - and I also
> agree with Stefano.
> 
> Berin is right in that we must strive for simplicity.
> Stefano is right in that a (somewhat) complex system is required to
> solve even more complex problems.
> 
> The problem with Cocoon as I see it is this:
> 
> Think about Java. It is a fairly simple language, right? You can do a
> "Hello World" pretty easily. But you can also do some fairly complex
> things with it.
> 
> The thing is this: You don't need to know the internal workings of the
> JRE or compiler in order to do this. You are abstracted away from it.
> Sometimes you have to look a thing or two up, but then you're doing
> some pretty advanced stuff.
> 
> Cocoon lacks this abstraction. You need to know about its internals to
> do even basic stuff.
> 
> If I can write both a blog and Cocoon in Java, why can't I use Cocoon
> for writing a blog? Why this "that problem is too simple for Cocoon."
> Maybe it is, but is that the problem's fault?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> So what's my recipe for success? Get that abstraction in place. Cocoon
> should be *a language for writing web apps*. Now we have XML, XSL,
> Javaflow, JSFlow, and a host of other languages. What if Java wasn't
> one language, but you had to write a JCL file to go with you java
> Hello World, a bunch of headers, and so on.
> 
> That language can then be modularized so that it can be extended, or
> so that parts of it can be reused - but I think the facade that has to
> be presented to the user has to be focused on one thing, and the user
> shouldn't have to look behind it (in 99.9% of the cases).
> 
> 
> package sample;
> 
> @website
> class MyHomepage {
> 
>     // Set by runtime execution environment.
>     @dependency
>     protected Translator translator;
> 
>     @uri ({"/", "/index.html"})
>     public Response mainPage () {
>         return new StreamResponse (new File ("index.html"));
>     }
> 
>     @uri ({"/hello"})
>     @pipeline (MyLookAndFeel)
>     public Response helloWorld (String who, String language) {
>         // Must be called /hello?who=...&language=...
>         return new StringResponse (
>             translator.translate ("Hello " + who + "!", language));
>     }
> }
> 
> @pipeline
> class MyLookAndFeel {
>     ...
> }
> 
> I skip things like "how do you use XSL" and so on - I'm making this up
> as I type, and it will take months to architect a proper language.
> 
> I see the system as having two parts:
> 
> 1. A language for writing webapps. It can (should perhaps) be java
> with annotations or other facility for extending it.
> 
> 2. An *embeddable* execution environment that will run webapps written
> in (1). This ***must*** be decoupled from any specific servlet
> container, and should not try to be an app server in itself. For
> example - class loading should not go here.
> 
> 
> By having this one language, writing tools for it is simpler. If an
> AST parser is provided for tool writers, it is even easier, and
> anything you can do in XSL with the current XML sitemap or xsp or ...
> can be done. You can also have code generators for websites.
> 
> 
> I think this is what Cocoon has been evolving toward, and a lot of the
> pain is that the problem ("make up a language for webapps") is just so
> *hard*. Cocoon has gone from XSP to Logic Sheets (which I never
> understood) to XSL to JavaFlow to... We have tried to create the one
> language for the web, but done so incrementally and under pressure to
> deploy. "Let's take C. Let's add some macros... let's add some more
> macros..."
> 
> Stefano also noted that there is a whole lot of talk and not much code
> being hammered out. True. In no way am I demanding that you develop
> the above. I might write it myself, given time. See this as just food
> for thought.
> 
> Anyway, my two cents.
> 
> /LS


Mime
View raw message