Hi Tibor,
I had the same problems, also with the combination JX template/Cforms. I
couldn't figure out where these namespaces were generated, but I
suspected it was somewhere in the Xalan transformer. I used Saxon and
these namespaces where gone.
HTH,
Bart.
-Original Message-
From:
Christopher Oliver wrote:
Christopher Oliver wrote:
snip/
Mmmh... you're right, there _wasn't_ such a property before my
changes. This explains the lengthy wrapping code that was in
FOM_Request that exposed only functions and no properties except
the request parameters (or attributes for
Daniel Fagerstrom wrote:
Christopher Oliver wrote:
Christopher Oliver wrote:
snip/
Mmmh... you're right, there _wasn't_ such a property before my
changes. This explains the lengthy wrapping code that was in
FOM_Request that exposed only functions and no properties except
the request parameters
Daniel Fagerstrom wrote:
Christopher Oliver wrote:
snip/
JS objects can and do exist without directly wrapping Java objects.
If you had accepted the original design which made FOM_Request,
FOM_Session, etc, first-class JS objects (i.e. _not_ mapped
versions of the Java objects) then there isn't
Reinhard Poetz wrote:
big-snip/
+1: 8
+0: 1
Therefore, we're going to start working on the new documentation.
Firstly, I have brought all necessary changes from 2.1 into the 2.2
docs. So the 2.2 docs can form the starting point for our work.
Secondly, we will convert this documentation to HTML,
I think this might be useful for CForms:
http://raibledesigns.com/page/rd/20050226#table_less_forms_for_your
Using CSS to control the layout of forms could be a big step in the
direction of a better SoC for CForms. Presently, if you want to change
the way fields are layed out in a form, you have
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
Furthermore Chris made it possible to use parts of FOM in a
systematic way from both Jexl and JXPath in JXTG. So that you could
do things like:
${cocoon.session.user.id}
#{$cocoon/session/user/id}
Now after the improvement you must do:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
Furthermore Chris made it possible to use parts of FOM in a
systematic way from both Jexl and JXPath in JXTG. So that you could
do things like:
${cocoon.session.user.id}
#{$cocoon/session/user/id}
Now after the
Sylvain Wallez wrote:
I admit however there is a possibly incompatible change: as JavaBean
properties of the underlying objects are now exposed as JS properties,
those may take precedence over the request parameters having the same
name. I'm of course ready to fix this, so that there is
I've checked-out BRANCH_2_1_X and compiled using 'compile'. While
trying to see Cocoon's main page I received exception. My
configuration is:
WinXP SP1
Tomcat 4.1.18
Java 1.4.2_04
Cocoon 2.1.6 worked fine, so i don't think so that it's problem with
my configuration. Any thoughts? Exception
Daniel Fagerstrom wrote:
I based my comment on:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110942199227672w=2
Ah yes. I was referring to 2.1 and double checked it before sending, and
forgot is had already been removed in 2.2. You therefore had some valid
points. Sorry for the rant, but
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
I based my comment on:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110942199227672w=2
Ah yes. I was referring to 2.1 and double checked it before sending, and
forgot is had already been removed in 2.2. You therefore had some valid
points. Sorry
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
I based my comment on:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110942199227672w=2
Ah yes. I was referring to 2.1 and double checked it before sending,
and forgot is had already been removed in 2.2. You therefore had some
You know what? I'm fed up with this discussion, and will start writing a
new implementation of the JS flowscript engine. People will have the
choice. And Chris will stop popping up as soon as someone touches his code.
Sylvain
Very nice display of community leadership...
I have no problem with
As I've stumbled across this a few times already (and I'm not nearly as
much into Cocoon as you guys), I know what you mean. I'll try and modify
the current XSL code and put it in Bugzilla.
Bye, Helma
-Original Message-
From: Ugo Cei [mailto:[EMAIL PROTECTED]
Sent: Monday, 28
Christopher Oliver wrote:
You know what? I'm fed up with this discussion, and will start writing
a new implementation of the JS flowscript engine. People will have the
choice. And Chris will stop popping up as soon as someone touches his
code.
Sylvain
Very nice display of community
That would be fab, Helma.
Regards, Upayavira
Linden H van der (MI) wrote:
As I've stumbled across this a few times already (and I'm not nearly as
much into Cocoon as you guys), I know what you mean. I'll try and modify
the current XSL code and put it in Bugzilla.
Bye, Helma
-Original
Le 28 févr. 05, à 20:41, Linden H van der (MI) a écrit :
...As I've stumbled across this a few times already (and I'm not
nearly as
much into Cocoon as you guys), I know what you mean. I'll try and
modify
the current XSL code and put it in Bugzilla
You mean changing the forms-styling XSL
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
You know what? I'm fed up with this discussion, and will start
writing a new implementation of the JS flowscript engine. People
will have the choice. And Chris will stop popping up as soon as
someone touches his code.
Sylvain
Very nice
As discussed in various threads we need a common environment model for
flow, templating (both with flow and non-flow input). And it will also
make Cocoon easier to learn if the environment part of FOM (let us call
it OM) and the sitemap environment model, i.e. input modules (IMs) are
put
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
I based my comment on:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110942199227672w=2
Ah yes. I was referring to 2.1 and double checked it before sending,
and forgot is had already been removed in
Daniel Fagerstrom wrote:
API
---
OM is a Map. IMs are like maps but have both construction and runtime
configurations and also interpret the key in much more sofisticated
ways than maps normally do.
WDYT?
/Daniel
Wow. Cocoon already has an ObjectModel Map which is used all over the
place. If
Daniel Fagerstrom wrote:
As discussed in various threads we need a common environment model for
flow, templating (both with flow and non-flow input). And it will also
make Cocoon easier to learn if the environment part of FOM (let us call
it OM) and the sitemap environment model, i.e. input
On Lun, 28 de Febrero de 2005, 15:00, Bertrand Delacretaz dijo:
I'm all for moving to more powerful CSS-based versions, but it might be
good to keep the existing stuff around for people who want to stay with
plain HTML.
We need to solve a problem Some people will add a XUL implementation.
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 36
Le 28 févr. 05, à 23:47, Sylvain Wallez a écrit :
...have you read the end of [1] where I suggest to use JS as the only
scripting language and eventually introduce specialized languages such
as XPath using some additional top-level functions?..
I haven't been following all of this discussion but
26 matches
Mail list logo
