roy huang wrote:
I can do it if current vote process is positive
There already is an ongoing vote.
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67
I can do it if current vote process is positive
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812
* Sylvain Wallez:
Leszek Gawron wrote:
roy huang wrote:
In current 2.1.x svn ,Forms using JXTemplateGenerator is
much slower than FormTransformer
For 2.1.x it is probably true because it still contains
unrefactored version of jxtg.
So what about adding the new
In current 2.1.x svn ,Forms using JXTemplateGenerator is much slower than
FormTransformer
Roy Huang
roy huang wrote:
In current 2.1.x svn ,Forms using JXTemplateGenerator is much slower than
FormTransformer
For 2.1.x it is probably true because it still contains unrefactored
version of jxtg.
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager
Leszek Gawron wrote:
roy huang wrote:
In current 2.1.x svn ,Forms using JXTemplateGenerator is much slower than
FormTransformer
For 2.1.x it is probably true because it still contains unrefactored
version of jxtg.
So what about adding the new Template block to 2.1?
Sylvain
.
Do you mean using CForms's jx-macros.xml with
JXTemplateGenerator?
I alsonoticed thatit's much slower
than using
FormsTemplateTransformer. But Sylvain told me
to use the
JXTemplateGenerator from Cocoon 2.2 (trunk) in
Cocoon 2.1. Has
anyone tried that combination
* Sascha-Matthias Kulawik:
Usual stuff, but Cocoon runs very slow in this environment,
especially CForms and the newer JXTransformer. Tested on Intel
Hardware or using Tomcat would solve the problem.
Do you mean using CForms's jx-macros.xml with JXTemplateGenerator?
I alsonoticed
CForms's jx-macros.xml with
JXTemplateGenerator?
I alsonoticed thatit's much slower
than using
FormsTemplateTransformer. But Sylvain told me
to use the
JXTemplateGenerator from Cocoon 2.2 (trunk) in
Cocoon 2.1. Has
anyone tried that combination?
I did some
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35845.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35845.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35845.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35845.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
/show_bug.cgi?id=35845
Summary: locale attribute in formatDate is not used in
JXTemplateGenerator
Product: Cocoon 2
Version: 2.1.7
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35845.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
/show_bug.cgi?id=35846
Summary: locale attribute in formatDate is not used in
JXTemplateGenerator
Product: Cocoon 2
Version: 2.1.7
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35845.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35846.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35845.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May 8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169view=rev
Log:
JXTG uses cocoon store
Modified:
Leszek Gawron wrote:
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May 8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169view=rev
Log:
JXTG uses cocoon store
Modified:
Sylvain Wallez wrote:
Leszek Gawron wrote:
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May 8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169view=rev
Log:
JXTG uses cocoon store
Modified:
Leszek Gawron wrote:
Sylvain Wallez wrote:
Leszek Gawron wrote:
Vadim Gritsenko wrote:
Leszek Gawron wrote:
I think I have to switch to transient store because
at least for now jxtg template is not serializable.
Is there a reason not to use transient store for jxtg?
none .. but I thought it is
Sylvain Wallez wrote:
The transient store is meant as a cache for objects that aren't
serializable, whereas the regular store has a memory front-end and some
persistent filesystem swap, and therefore can only accept serializable
objects.
Not true. Regular store must accept all objects. See also
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
The transient store is meant as a cache for objects that aren't
serializable, whereas the regular store has a memory front-end and
some persistent filesystem swap, and therefore can only accept
serializable objects.
Not true. Regular store must
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
The transient store is meant as a cache for objects that aren't
serializable, whereas the regular store has a memory front-end and
some persistent filesystem swap, and therefore can only accept
serializable objects.
Not true. Regular store must
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
The transient store is meant as a cache for objects that aren't
serializable, whereas the regular store has a memory front-end and
some persistent filesystem swap, and therefore can only accept
serializable objects.
Not true.
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
The transient store is meant as a cache for objects that aren't
serializable, whereas the regular store has a memory front-end and
some persistent filesystem swap, and therefore can only accept
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May 8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169view=rev
Log:
JXTG uses cocoon store
Modified:
cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java
could
Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May 8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169view=rev
Log:
JXTG uses cocoon store
Modified:
Leszek Gawron wrote:
Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May 8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169view=rev
Log:
JXTG uses cocoon store
Modified:
Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May 8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169view=rev
Log:
JXTG uses cocoon store
Modified:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33836.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
/show_bug.cgi?id=33836
Summary: JXTemplateGenerator cache thread safety problem
Product: Cocoon 2
Version: 2.1.6
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: sitemap components
Christopher Oliver wrote:
snip/
Let's face it: your code is dense as a neutron star and dense of
comments and tests as the the outter space around one.
For what it's worth I do like _your_ writing style above.
Me too, both because of the humorous tone and the message is conveys.
Now you
Le 11 déc. 04, à 00:57, Christopher Oliver a écrit :
...General consensus has turned out to be incorrect on many
occasions. What I see is that some people, such as Stefano, are
looking to build a better templating system while others are
contemplating what appears to be pointless
Bertrand Delacretaz wrote:
Le 11 déc. 04, à 00:57, Christopher Oliver a écrit :
...General consensus has turned out to be incorrect on many
occasions.
I guess many of us have seeked comfort in that idea, when not geting
things our way. But while it might be a relevant idea for describing
Stefano Mazzocchi wrote:.
Everybody here welcomes contributions, not matter how silly, not
matter how technologically savvy, now matter how outrageous and no
matter how sinful and ranting.
But respect for your peers is key.
Without that, any voice, no matter whose, becomes immediately silent,
Christopher Oliver wrote: It's not personal, Bertrand. If someone
does good work or makes a valid point I will give them proper
respect. If not, well, I'm not teaching grade school and it's not my
job to sugar coat it.
Really? Wasn't that you that disliked the way Pierpaolo and myself
Christopher Oliver wrote:
It's not personal, Bertrand. If someone does good work or makes a valid
point I will give them proper respect. If not, well, I'm not teaching
grade school and it's not my job to sugar coat it.
Really? Wasn't that you that disliked the way Pierpaolo and myself
avoided
,
Antonio Gallardo
On Vie, 10 de Diciembre de 2004, 10:29, Christopher Oliver dijo:
I recently took a look at this mailing list after I happened to talk to
Stefano in person (he was in LA) and noticed a _few_ posts about
refactoring JXTemplateGenerator.
Of course you can do what you like, but just so
JXTemplateGenerator.
You should show up a little more often... you know, be a little more
sociable.
The funniest post of all was this
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110210971210386w=2.
I mean, give me break. That is just plain silly.
I never realized inner classes were so _scary_
Le 10 déc. 04, à 17:29, Christopher Oliver a écrit :
...The funniest post of all was this
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110210971210386w=2.
I mean, give me break. That is just plain silly
Can't swallow this one without reacting, sorry - wrong tone, and there
is a general
don't think the effort to refactor and
extend it is being done with anything other then love and respect.
I never realized inner classes were so _scary_. (The reason they are
there is that JXTemplateGenerator predates blocks and also that the
majority of those classes are unencapsulated flyweight
I recently took a look at this mailing list after I happened to talk to
Stefano in person (he was in LA) and noticed a _few_ posts about
refactoring JXTemplateGenerator.
Of course you can do what you like, but just so you know, here is my
point of view:
Obviously it would have been easy
Le 10 déc. 04, à 17:29, Christopher Oliver a écrit : ...The funniest
post of all was this
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110210971210386w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110210971210386w=2.
I mean, give me break. That is just plain silly
Sorry for
Christopher Oliver wrote:
I recently took a look at this mailing list after I happened to talk to
Stefano in person (he was in LA) and noticed a _few_ posts about
refactoring JXTemplateGenerator.
Of course you can do what you like, but just so you know, here is my
point of view:
Obviously
I'm getting a ClassCastException when using the JXTemplateGenerator and passing
bizdata to it:
java.lang.ClassCastException
at org.apache.cocoon.components.flow.javascript.ScriptablePropertyHandler
.getPropertyNames(ScriptablePropertyHandler.java:77
/show_bug.cgi?id=29381
JXTemplateGenerator: ignore start/endDocument when streaming nodes
[EMAIL PROTECTED] changed:
What|Removed |Added
Summary|JXTemplate - Can't process
/show_bug.cgi?id=29381
JXTemplateGenerator: ignore start/endDocument when streaming nodes
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Repost...in the hope that the Jx/Jexl gurus are not on vacation.
When customizing the JxTemplateGenerator we ran into a hardcoded
implementation of the Uberspect in Cocoon-2.1.4. The only way to get our own
implementation of the Uberspect up-and-running was to DIRTY hack the
JEXL-source.
Anyone
Danny Bols wrote:
Repost...in the hope that the Jx/Jexl gurus are not on vacation.
Worse than that: the Jx/Jexl guru has left the project (it's Chris Oliver).
When customizing the JxTemplateGenerator we ran into a hardcoded
implementation of the Uberspect in Cocoon-2.1.4. The only way to get
Hi all,
I think this is a bug, but just to make sure. When copying an attribute
value containing no expressions, the original value shouldn't be used
because \ escapes will change the final value. Patch is against
BRANCH_2_1_X.
Thanks,
Pete
--- JXTemplateGenerator.java.orig 2004-09-16
Michael Gerzabek wrote:
The best thing is - my session parameters are gone after I use
those statements. Before I call the page they are there and
afterwards they are gone.
jx:when test=${cocoon.session.user == null}
works like a charm for me.
--
Leszek Gawron
At 11:23 03.09.2004, you wrote:
Michael Gerzabek wrote:
The best thing is - my session parameters are gone after I use
those statements. Before I call the page they are there and
afterwards they are gone.
jx:when test=${cocoon.session.user == null}
works like a charm for me.
Could it be that the
I debugged JXTG down and found out that seupt() is called twice when you
use cocoon://.
There have been problems in the past with xsp pages that were loaded twice
when using
cocoon:/(/) protocol
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107418715206665w=2
blame on me! An image was missing. Sorry for the noise.
Regards,
Michael
At 13:12 03.09.2004, you wrote:
I debugged JXTG down and found out that seupt() is called twice when you
use cocoon://.
There have been problems in the past with xsp pages that were loaded twice
when using
cocoon:/(/)
Hello,
I'm not sure if this is a bug or me doing wrong:
I'm trying to access session attributes from JXTemplateGenerator as well as
sitemap parameters. I use
1.) test${parameters.getParameter(store)}/test
2.) test${session.getAttribute(store)}/test
3.) test src=${session.store}/
4.) test src
Michael Gerzabek wrote:
Hello,
I'm not sure if this is a bug or me doing wrong:
I'm trying to access session attributes from JXTemplateGenerator as well as
sitemap parameters. I use
1.) test${parameters.getParameter(store)}/test
2.) test${session.getAttribute(store)}/test
3.) test src
/
test0/test
test /
I'm using C2.1.5.1.
Do I need input modules for that functionality?
Thanks,
Michael
At 21:59 02.09.2004, you wrote:
Michael Gerzabek wrote:
Hello,
I'm not sure if this is a bug or me doing wrong:
I'm trying to access session attributes from JXTemplateGenerator as well as
sitemap
:
I'm trying to access session attributes from JXTemplateGenerator as well as
sitemap parameters. I use
1.) test${parameters.getParameter(store)}/test
2.) test${session.getAttribute(store)}/test
3.) test src=${session.store}/
4.) test src=${request.store}/
except of 4.) nothing is working for me.
What
/show_bug.cgi?id=27133
JxTemplateGenerator eats backslash-characters
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |ASSIGNED
/show_bug.cgi?id=27133
JxTemplateGenerator eats backslash-characters
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
/show_bug.cgi?id=29752
[PATCH] Caching JXTemplateGenerator
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |ASSIGNED
/show_bug.cgi?id=29752
[PATCH] Caching JXTemplateGenerator
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
/show_bug.cgi?id=29752
[PATCH] Caching JXTemplateGenerator
Summary: [PATCH] Caching JXTemplateGenerator
Product: Cocoon 2
Version: Current CVS 2.1
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority
/show_bug.cgi?id=29752
[PATCH] Caching JXTemplateGenerator
--- Additional Comments From [EMAIL PROTECTED] 2004-06-23 08:54 ---
Created an attachment (id=11914)
source
Hello,
when customizing the JxTemplateGenerator we ran into a hardcoded
implementation of the Uberspect in Cocoon-2.1.4. The only way to get our own
implementation of the Uberspect up-and-running was to DIRTY hack the
JEXL-source.
Anyone ran into the same problems? Any better solutions?
I would
Here are two new features I would like to try to implement if they were
accepted by cocoon developers:
1. implement jx:attribute (same functionality as xsl:attribute)
Try to implement a table with coloured rows and you'll know why it's needed -
as you cannot place a conditional attribute
Just curious, I just noticed that the JXTemplateGenerator stores
FOM objects in the context that can then be addressed by the expressions,
like this:
cocoon.put(request,
FOM_JavaScriptFlowHelper.getFOM_Request(objectModel));
Why is this so?
Carsten
Carsten Ziegeler
Open Source
http://marc.theaimsgroup.com/?t=107083319900025r=1w=2
Carsten Ziegeler wrote:
Just curious, I just noticed that the JXTemplateGenerator stores
FOM objects in the context that can then be addressed by the expressions,
like this:
cocoon.put(request
Thanks!
Carsten
-Original Message-
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 5:51 PM
To: [EMAIL PROTECTED]
Subject: Re: Why does JXTemplateGenerator use FOM objects?
http://marc.theaimsgroup.com/?t=107083319900025r=1w=2
Carsten
/show_bug.cgi?id=26086
[PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW
/show_bug.cgi?id=26086
[PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator
--- Additional Comments From [EMAIL PROTECTED] 2004-03-08 19:58 ---
Chris, what about this bug and its very simple patch?
We've built a quite large set of Java objects that are handled by flow
and then passed to JXTemplate for presentation. This all works fine,
except when an exception occurs within our java objects. For some
reason, the JXTemplate generator doesn't show or pass on the exception
that occurred,
Can you provide an example stack trace? AFAIK JXTemplateGenerator wraps
an exception it catches in a SAXParseException. The original exception
should still be available through SAXException.getException().
Upayavira wrote:
We've built a quite large set of Java objects that are handled by flow
Chris,
thanks for the info. I need to do some presentation logic
hence the JXTemplateGenerator.
eg: jx:if test=${..}etc../jx:if
I've put the wi:styling stuff on the backburner for the moment.
Were you planning on expanding on the macros any time soon?
Oz
-Original Message-
From
widget.generateSAXFragment() at all,
and replace its behavior with equivalent jx macro code.
Why can't you use WoodyTemplateTransformer?
Regards,
Chris
Oguz Kologlu wrote:
Hi all,
I'm using the latest 2.1 JXTemplateGenerator (cvs tag 1.30) and the JX Macros
Christopher Oliver orignally wrote
Hi all,
I'm using the latest 2.1 JXTemplateGenerator (cvs tag 1.30) and the JX Macros
Christopher Oliver orignally wrote.
There appears to be a problem with widgets that contains styling information
when the jxtemplategenerator processes them.
eg:
wt:widget id=notes
wi:styling type=textarea
that:
widget.generateSaxFragment(cocoon.consumer, locale)
(see below for full macro) is not actually processing the
wt:styling macro...
Any ideas?
Oz
-Original Message-
From: Oguz Kologlu
Sent: Friday, 16 January 2004 1:37 PM
To: [EMAIL PROTECTED]
Subject: JXTemplateGenerator / JX macro bug
Hi all
/show_bug.cgi?id=26086
[PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator
Summary: [PATCH] Dereferencing null TextEvent() argument in
JXTemplateGenerator
Product: Cocoon 2
Version: Current CVS 2.1
Platform: All
OS
/show_bug.cgi?id=26086
[PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator
--- Additional Comments From [EMAIL PROTECTED] 2004-01-13 10:19 ---
Created an attachment (id=9928)
Patch to JXTemplateGenerator.java
/show_bug.cgi?id=26086
[PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator
--- Additional Comments From [EMAIL PROTECTED] 2004-01-13 10:42 ---
The field I'm referring to in Description is location/this.location and not
a locator.
Hello,
I am trying to integrate my own DynamicPropertyHandler into the
JxTemplateGenerator. It seems like JxPath doesn't activate the handler when
needed (I don't see any of my log messages added to the handler).
I registered the handler this way:
JXPathIntrospector.registerDynamicClass
/show_bug.cgi?id=23538
[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
From: Sylvain Wallez
Hi team,
I'd like to add the use of leniency to JXPath expressions in
JXTemplateGenerator: currently, if a path does not exist, a nice
exception is thrown. This may be good in some circumstances (avoids
endless hair pulling sessions to finally discover a small
Giacomo Pati wrote:
On Tue, 21 Oct 2003, Sylvain Wallez wrote:
Hi team,
I'd like to add the use of leniency to JXPath expressions in
JXTemplateGenerator: currently, if a path does not exist, a nice
exception is thrown. This may be good in some circumstances (avoids
endless hair pulling
On Tue, 21 Oct 2003, Sylvain Wallez wrote:
Hi team,
I'd like to add the use of leniency to JXPath expressions in
JXTemplateGenerator: currently, if a path does not exist, a nice
exception is thrown. This may be good in some circumstances (avoids
endless hair pulling sessions to finally
Hi team,
I'd like to add the use of leniency to JXPath expressions in
JXTemplateGenerator: currently, if a path does not exist, a nice
exception is thrown. This may be good in some circumstances (avoids
endless hair pulling sessions to finally discover a small typo), but is
also required
/show_bug.cgi?id=23538
[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively
--- Additional Comments From [EMAIL PROTECTED] 2003-10-07 02:32 ---
Hmm, having a further look, I found that JXFormsGenerator uses the same pattern
and exhibits the same feature in the event loop.
Whilst
/show_bug.cgi?id=23538
[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively
--- Additional Comments From [EMAIL PROTECTED] 2003-10-07 02:35 ---
Created an attachment (id=8473)
tar.gz archive with individual patch files for JX(Template|Forms)Generator
/show_bug.cgi?id=23538
[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively
--- Additional Comments From [EMAIL PROTECTED] 2003-10-06 00:23 ---
Created an attachment (id=8459)
[PATCH] Create facade for locator that is set once on the consumer before
startDocument() as suggested
/show_bug.cgi?id=23538
[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively
--- Additional Comments From [EMAIL PROTECTED] 2003-10-06 00:34 ---
Thanks for your review Chris, I worked on a new patch, I hope it solves the
problem elegantly enough. I had an inkling that my original
/show_bug.cgi?id=23538
[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively
[EMAIL PROTECTED] changed:
What|Removed |Added
Summary|JXTemplateGenerator calls |[PATCH
/show_bug.cgi?id=23538
[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively
--- Additional Comments From [EMAIL PROTECTED] 2003-10-04 05:23 ---
The attached patch is incorrect. Please don't apply it. A proper fix would be to
create a facade document locator that can be reset
/show_bug.cgi?id=23538
JXTemplateGenerator calls setDocumentLocator() excessively
Summary: JXTemplateGenerator calls setDocumentLocator()
excessively
Product: Cocoon 2
Version: Current CVS 2.1
Platform: Other
OS/Version: Other
/show_bug.cgi?id=23171
[PATCH] JXTemplateGenerator doesn't release Source
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
/show_bug.cgi?id=23171
[PATCH] JXTemplateGenerator doesn't release Source
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |ASSIGNED
/show_bug.cgi?id=23171
[PATCH] JXTemplateGenerator doesn't release Source
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
/show_bug.cgi?id=23171
[PATCH] JXTemplateGenerator doesn't release Source
[EMAIL PROTECTED] changed:
What|Removed |Added
Summary|[PATCH] |[PATCH
1 - 100 of 101 matches
Mail list logo
