Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
AFAIU only some work on cForms is missing (flowscript API and
repeater binding)
That's far from the only work to do IMO, as there are a lot of
semi-finished core features. Some that come to mind: refactored
object model,
Here the main problem is that JXTG and flow have some differences in
behaviour, see
http://marc2.theaimsgroup.com/?t=111648265000001&r=1&w=2 and
http://marc2.theaimsgroup.com/?l=xml-cocoon-dev&m=111666682531907&w=2
for description and possible solutions. We need to decide: should we
keep trhe direct access of request params as properties of
cocoon.request and session/context attributes as properties of
cocoon.[session|context] or not. Should we support the direct usage
of org.*, javax.* and com.* whithout needing the Packages. prefix in
flow?
On that point, I proposed to write a new implementation of the
flowscript implementation. This is certainly not a total rewrite, but
a refactoring of the existing code to have an overally consistent
object model, and also introduce a "flow" object that would separate
the flow-specific operations out of the "cocoon" object that should be
the common base for the object model, and therefore be identical in
all places (flow, templates, form event listeners, etc).
Would be nice!
Having thought a little bit more about it I think that we, for the
moment, just should make JXTG compatible with flow and independent of
it. I take care of that if not anyone else feel like doing it. Then we
can discuss refactorings, deprecation of confusing behaviour etc. But we
need to support the behaviour of JXTG from 2.1 in 2.2 even if we
hopefully can deprecate some stuff.
<snip/>
As discussed in the relases thread I don't think it is realistic to
stop adding features, we need a way to let rock stable core
functionality coexist with new features. Otherwise the defacto "no
release" policy will continue.
Agree. That this "rock solid core" state that I'm currently not sure
about, as many changes have occured there.
I'm certainly not saying that the core in trunk is rock solid rigth now.
What I'm saying is that when we have managed to get the core "rock
solid" again, we should keep it that way in trunk. Marking something
that is stable as unstable seem to be self fullfilling. People might
become less carefull in the hope that it can be fixed later and most
user testing and feedback dissapears.
/Daniel
- Re: [RT] Micro kernel based Cocoon Daniel Fagerstrom
-
