[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: [Poll] We need to align on one point (was Re: [Vision] Knowing
From:       Daniel Fagerstrom <danielf () nada ! kth ! se>
Date:       2005-12-07 18:10:34
Message-ID: 4397259A.8000207 () nada ! kth ! se
[Download RAW message or body]

Following the vision that Bertrand and Marc expressed, I'd like to see 
Cocoon becoming less of a xml webapp framework and more of a set of 
reuasble xml webapp components and a set of design patterns. With this I 
measn that you can use the parts of Cocoon that you like, in the way you 
like in your webapp, without having to buy a whole religion.

So following this, the flowscript controller should be less tightly 
integrated than it is today. We have a flowscript servlet that can be 
used stand alone in other projects. When you use it in Cocoon, you just 
inject the Cocoon component model in it and it can call the sitemap 
controller or other controllers through the servlet context (or whatever 
reusable way we come up with).

The Cocoon component model is written in Java and properly POJOfied, so 
it doesn't need to have any JavaScript awareness.

And a JavaFlow controler can work in a similar way. If I understod 
Torsten right, there is allready a JavaFlow servlet.

Given the need for backcompability and the fact that a flowscript 
controller is rather usefull in its own right, for people who happen to 
like JavaScript. It is reasonable that we maintain such a beast during 
the forseeable future. It doesn't have to be part of the core of Cocoon 
though.

                     --- o0o ---

So given that we factor out the flowscript controller from the core, the 
question is what your question bellow will mean. It will be up to the 
application writer what to use. And hopefully our blocks will take of 
more as more independent projects, that do whatever they find best.

Except for in the CForms block, IIRC, I don't think that we have written 
that much flowscript code that is supposed to be reused. Despite that 
flowscripts have been around for quite a long time.

For the actual core of Cocoon I envision that everything have clean and 
well designed Java interfaces, so that you can develop purely in a Java 
world.

If we build reusable webapps, I would have nothing against focusing on 
Java. And also focusing on Java in the documentation would be Ok for me.

                     --- o0o ---

But above all I would prefer if we focused on providing a small, clean, 
stable and reusable set of core xml webapp components and leave it to 
the users to do whatever they want with them.

/Daniel

Berin Loritsch wrote:
...

> Now, my chief goal and my chief vision for Cocoon is to simplify the 
> number of concepts a user has to learn before they are effective with 
> Cocoon.  That might mean that we provide JavaScript as the only way to 
> interact with the core.  All web applications would be written in 
> JavaScript from control to helper functions.  Or all web applications 
> would be written in Java from control to helper functions.  It is 
> incredibly awkward to mix and match as the default way to do things.  
> It is difficult to explain when and where to use which language.  Now, 
> for advanced users who don't mind the mix and match, I have no problem 
> with having tutorials on how to do that properly.
>
> What's your preference for the vision?
>
> [ ] All web apps written in JavaScript
> [ ] All web apps written in pure Java
> [ X ] Mix and match (not as simple, but is status quo with today)
>

[prev in list] [next in list] [prev in thread] [next in thread]