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).
Is there anythimg more?
sitemap listeners,
VPCs,
I'm waiting for community involvement.
If we follow Vadim's suggestion
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111331073205551&w=2,
nothing in core need to depend on vpc code and the vpc code could be
mocīved to an own (unstable) block.
Sounds good.
third-party containers, etc. Not that these features don't work, but
they lack (at least that's my impression) some more use cases and
demos to be strong enough for a stable release.
Sure, we can make an alpha release to give people a sign that we are
doing some progress, but this should be for us the sign that no more
features should be added in that branch.
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.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
