Stefano Mazzocchi wrote:
Leszek Gawron wrote:
Components are existed before Flow, but Flow is more popular than writing
components, the question is why?
flowscript + notepad vs. components + eclipse. and the winner concerning
development lifecycle time is: flowscript.
Flowscript is:
a) scripted
b) automatically reloaded by cocoon after changes without container restart.
See? *this* is what I'm talking about.
Now we made it easier to write flowscript than to write components, now we have to focus on making it easier to write components than flowscript.
How?
Chris' magic compiler classloader is the way to go, IMHO.
From a users point of view: YES YES YES. I am now porting an application from pure flowscript to Java since I got a headache from looking at the 1000+ lines, 4000+ words flowscript based app. And this was only the framework for the business logic:)
The reason I did this was actually because I didn't want my WEB-INF classes with application specific classes. And re-starting each time I test is also not preferred. I think if the compiler/classloader would have existed for flowscript I would just use that, as Java is very much simpler to develop and maintain.
I think though, that some formal properties of a component (what makes a component a component) should be defined. A bit like the way JavaBeans are defined: A java bean has ...).
Leon
Given a choice, people would like to use eclipse for their business logic, I'm sure, give them autocompletion and autoreload and logic will start floating from flow to components.
keep in mind that with real blocks any class is a component, so no reason to implement the avalon lifecycle if you don't want to.
