Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE]Unrestricting the FOM)]

Chris: The name JavaScript was just a good marketing meme and the reason why Netscape choosed this name for this language called Javascript. I agree with you. Recently I found a lot of changes to java-zation of the JS Flow code. I see too much verbosity in the "new" changes. The reason to not lik

Re: [RT] CTemplate

On Feb 26, 2005, at 4:01 PM, Ralph Goers wrote: Glen Ezkovich wrote: They will always find a special case where this is most expedient or only solution they see because they don't realize that there are other more appropriate solutions. Making this configurable just adds one more complexity to t

Re: [RT] CTemplate

Leszek Gawron wrote: Vadim Gritsenko wrote: jx:language="jxpath" on the root element can specify the default for a page. IIRC, default on generator level was deemed not granular enough. and if there is: would you first check if there is a jx:language attribute Start element always comes with all

JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]

Sorry to pick on Sylvain again, but he consistently exhibits a common behavior of Java programmers with respect to JavaScript. Because JS syntax is so similar to Java they seem to feel a JS API is somehow "better" the more it resembles what it would look like if it was written in Java. The "sp

Re: [Poll] JXTG vs. CForms

Carsten Ziegeler wrote: But the other valid point remains: the syntax. Now, what about: ${cocoon.session.attributes.user.id} ? ++1 Vadim

Re: [RT] CTemplate

Glen Ezkovich wrote: They will always find a special case where this is most expedient or only solution they see because they don't realize that there are other more appropriate solutions. Making this configurable just adds one more complexity to the equation. I suggest that it be decided one wa

Re: [Poll] JXTG vs. CForms

Carsten Ziegeler wrote: Ralph Goers wrote: Carsten Ziegeler wrote: But the other valid point remains: the syntax. Now, what about: ${cocoon.session.attributes.user.id} ? Carsten That's OK, but does that seems somewhat problematic. Does that mean that the code will search for a getXXX method (in th

Re: JXTG macro calling

Leszek Gawron wrote: Daniel Fagerstrom wrote: Leszek Gawron wrote: We cannot have two instructions bound to the same jx:param or we will again introduce dependencies in Parser. This constraint is, AFAICS, only dependent on that child instructions has access to their ancestor instructions during

Re: JXTG macro calling

Daniel Fagerstrom wrote: Leszek Gawron wrote: Glen Ezkovich wrote: On Feb 26, 2005, at 7:18 AM, Sylvain Wallez wrote: Another question: Do you think this syntax would be useful? Do you mean the "p" param as attribute? Yes, it's useful, because IMO is just as overly verbose as XSLT, to wh

Re: JXTG macro calling

Leszek Gawron wrote: Glen Ezkovich wrote: On Feb 26, 2005, at 7:18 AM, Sylvain Wallez wrote: Another question: Do you think this syntax would be useful? Do you mean the "p" param as attribute? Yes, it's useful, because IMO is just as overly verbose as XSLT, to which JXTG is supposed to p

Re: JXTG macro calling

On Feb 26, 2005, at 2:05 PM, Leszek Gawron wrote: Glen Ezkovich wrote: On Feb 26, 2005, at 7:18 AM, Sylvain Wallez wrote: Another question: Do you think this syntax would be useful? Do you mean the "p" param as attribute? Yes, it's useful, because IMO is just as overly verbose as XSLT, t

Re: [RT] CTemplate

On Feb 26, 2005, at 11:33 AM, Ralph Goers wrote: Daniel Fagerstrom wrote: We should also IMO remove the Java package mechanism from the environment in CTemplate, i.e. the possibillity to do: ${java.util.HashMap()} While I agree that good practice would be to not allow this, I would prefer that t

Re: JXTG macro calling

Glen Ezkovich wrote: On Feb 26, 2005, at 7:18 AM, Sylvain Wallez wrote: Another question: Do you think this syntax would be useful? Do you mean the "p" param as attribute? Yes, it's useful, because IMO is just as overly verbose as XSLT, to which JXTG is supposed to provide a simpler rep

Re: [Poll] JXTG vs. CForms

On Sab, 26 de Febrero de 2005, 8:09, Vadim Gritsenko dijo: > Daniel Fagerstrom wrote: >> Leszek is eager to remove all sorts of counter intuitive constructions >> from JXTG, which is good. Now the question is how we should do this. >> >> I propose that we (in the trunk): >> >> * As soon as we have

Re: [Poll] JXTG vs. CForms

Carsten Ziegeler wrote: Leszek Gawron wrote: Still there is one thing in trunk I do not like which breaks jxtg compatibility. It is the removal of wrappers around request, session etc. Because of that all users will be forced to change from ${cocoon.session.user.id} to ${cocoon.session.getAttri

Re: JXTG macro calling

On Feb 26, 2005, at 7:18 AM, Sylvain Wallez wrote: Another question: Do you think this syntax would be useful? Do you mean the "p" param as attribute? Yes, it's useful, because IMO is just as overly verbose as XSLT, to which JXTG is supposed to provide a simpler replacement ;-) is ove

Re: [Poll] JXTG vs. CForms

Ralph Goers wrote: Carsten Ziegeler wrote: But the other valid point remains: the syntax. Now, what about: ${cocoon.session.attributes.user.id} ? Carsten That's OK, but does that seems somewhat problematic. Does that mean that the code will search for a getXXX method (in this case getAttributes -

Re: [Poll] JXTG vs. CForms

Carsten Ziegeler wrote: But the other valid point remains: the syntax. Now, what about: ${cocoon.session.attributes.user.id} ? Carsten That's OK, but does that seems somewhat problematic. Does that mean that the code will search for a getXXX method (in this case getAttributes - Oh but it is getAt

Re: [Poll] JXTG vs. CForms

Leszek Gawron wrote: Still there is one thing in trunk I do not like which breaks jxtg compatibility. It is the removal of wrappers around request, session etc. Because of that all users will be forced to change from ${cocoon.session.user.id} to ${cocoon.session.getAttribute('user').id}. Took m

Re: [RT] CTemplate

Daniel Fagerstrom wrote: We should also IMO remove the Java package mechanism from the environment in CTemplate, i.e. the possibillity to do: ${java.util.HashMap()} While I agree that good practice would be to not allow this, I would prefer that this behavior be configurable either when the comp

DO NOT REPLY [Bug 33747] - SourceWritingTransforer write only the first node

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [RT] CTemplate

Leszek Gawron wrote: Daniel Fagerstrom wrote: Now that we have decided to call JXTG CTemplate in the future http://marc.theaimsgroup.com/?t=11090886612&r=1&w=2, is it a good opportunity to discuss what CTemplate should become. IMO CTemplate should be close to JXTG but we should remove all of

Re: Guidelines for linked projects from our site

Antonio Gallardo wrote: Hi: Yesterday, on the user list was a post for a link of a project that use a Collaborative License. This kind of license is not OSI aproved. I read about this license and for my eyes is a closed source license. We currently have this page: http://cocoon.apache.org/link/proj

Re: [RT] CTemplate

Vadim Gritsenko wrote: Daniel Fagerstrom wrote: We need to decide if JXPath or Jexl should be the default EL, so that one just need to write: {$a+$b} for the default EL ;). jx:language="jxpath" on the root element can specify the default for a page. IIRC, default on generator level was deemed

Re: [RT] The Silkworm Experiment

Paul Russell wrote: Stefano, taken off list because I think that thread's got long enough already! Hmmm, Paul, I think you hit the wrong button! since (unless I'm out of my mind) this came to me from the list. On Fri, 25 Feb 2005 16:19:56 +0100, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: And co

Re: [Poll] JXTG vs. CForms

Vadim Gritsenko wrote: Leszek Gawron wrote: Still there is one thing in trunk I do not like which breaks jxtg compatibility. It is the removal of wrappers around request, session etc. Because of that all users will be forced to change from ${cocoon.session.user.id} to ${cocoon.session.getAttrib

Re: JXTG macro calling

Sylvain Wallez wrote: what do you think about removing the old syntax in 2.2? For me it is counter-intuitive and leads to accidental mistakes (not so easy to find by newbies). -1 on removing this syntax, as it prevents writing things such as the CForms template language using JXTG (or CTe

Re: [RT] CTemplate

Vadim Gritsenko wrote: Daniel Fagerstrom wrote: We need to decide if JXPath or Jexl should be the default EL, so that one just need to write: {$a+$b} for the default EL ;). jx:language="jxpath" on the root element can specify the default for a page. IIRC, default on generator level was deemed n

Re: [RT] CTemplate

Daniel Fagerstrom wrote: Now that we have decided to call JXTG CTemplate in the future http://marc.theaimsgroup.com/?t=11090886612&r=1&w=2, is it a good opportunity to discuss what CTemplate should become. IMO CTemplate should be close to JXTG but we should remove all of the peculiarities a

Re: [Poll] JXTG vs. CForms

Daniel Fagerstrom wrote: Leszek is eager to remove all sorts of counter intuitive constructions from JXTG, which is good. Now the question is how we should do this. I propose that we (in the trunk): * As soon as we have done some more testing of the refactored JXTG (all help is welcome), we remo

Re: [Poll] JXTG vs. CForms

Leszek Gawron wrote: Still there is one thing in trunk I do not like which breaks jxtg compatibility. It is the removal of wrappers around request, session etc. Because of that all users will be forced to change from ${cocoon.session.user.id} to ${cocoon.session.getAttribute('user').id}. I thi

Re: [RT] CTemplate

Daniel Fagerstrom wrote: We need to decide if JXPath or Jexl should be the default EL, so that one just need to write: {$a+$b} for the default EL ;). jx:language="jxpath" on the root element can specify the default for a page. IIRC, default on generator level was deemed not granular enough. W

Re: JXTG macro calling

Sylvain Wallez wrote: Leszek Gawron wrote: what do you think about removing the old syntax in 2.2? For me it is counter-intuitive and leads to accidental mistakes (not so easy to find by newbies). -1 on removing this syntax, as it prevents writing things such as the CForms template langu

Re: [Poll] JXTG vs. CForms

Leszek Gawron wrote: Daniel Fagerstrom wrote: Leszek is eager to remove all sorts of counter intuitive constructions from JXTG, which is good. Now the question is how we should do this. I propose that we (in the trunk): * As soon as we have done some more testing of the refactored JXTG (all hel

Re: JXTG macro calling

Leszek Gawron wrote: As we have now two ways of calling a macro: http://apache.org/cocoon/templates/jx/1.0";> what do you think about removing t

[RT] CTemplate

Now that we have decided to call JXTG CTemplate in the future http://marc.theaimsgroup.com/?t=11090886612&r=1&w=2, is it a good opportunity to discuss what CTemplate should become. IMO CTemplate should be close to JXTG but we should remove all of the peculiarities and make it as side effect

Re: [Poll] JXTG vs. CForms

Daniel Fagerstrom wrote: Leszek is eager to remove all sorts of counter intuitive constructions from JXTG, which is good. Now the question is how we should do this. I propose that we (in the trunk): * As soon as we have done some more testing of the refactored JXTG (all help is welcome), we remo

[Poll] JXTG vs. CForms

Leszek is eager to remove all sorts of counter intuitive constructions from JXTG, which is good. Now the question is how we should do this. I propose that we (in the trunk): * As soon as we have done some more testing of the refactored JXTG (all help is welcome), we remove the original one and r

Re: svn commit: r155358 - cocoon/site/src/documentation/content/xdocs/link/projects.xml

Vadim Gritsenko wrote: [EMAIL PROTECTED] wrote: +http://osoco.sourceforge.net/cowarp/";>CoWarp + is an open source extension to Cocoon - it provides an improved authentication framework and + useful components for Cocoon. + Well, why not deprecate auth-fw instead? Currently CoWarp is a one-man

Re: JXTG macro calling

Leszek Gawron wrote: As we have now two ways of calling a macro: http://apache.org/cocoon/templates/jx/1.0";> what do you think about removing t

JXTG macro calling

As we have now two ways of calling a macro: http://apache.org/cocoon/templates/jx/1.0";> what do you think about removing the old syntax in 2.2?

Re: JX generates weird NameSpace???

Jean-Baptiste Quenot wrote: * oceatoon: Is anybody aware of such a thing as JX generating a weirds namespaces?? Yes, and this has already been reported. do you happen to know the bugzilla link? I had this once when using views. I'll try to look into that. -- Leszek Gawron