e *-->1 means "many to one relationship through the prototype link".
HTH,
Chris
Christopher Oliver wrote:
> FYI it is not thread-safe to use a static rhino scope. Instead the
> caller of the template should should pass this from his own session. I
> think this same bug also exists in
FYI it is not thread-safe to use a static rhino scope. Instead the
caller of the template should should pass this from his own session. I
think this same bug also exists in the CForms implemenation but I'm not
sure.
Regards,
Chris
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May 8
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May 8 12:25:12 2005
New Revision: 169150
URL: http://svn.apache.org/viewcvs?rev=169150&view=rev
Log:
share root rhino scope
Modified:
cocoon/trunk/src/java/org/apache/cocoon/environment/TemplateObjectModelHelper.java
Modified:
cocoon/tr
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 a
Christopher Oliver wrote:
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 session and context).
This is a tradeoff: by "combining" properties you get easer access to
commonly used properties, but however at the cost of overloading the
identifiers at times. Note that it's always possible to provide an
"escape" mechanism to disambiguate such cases, even if DOM didn't do
that in this case.
Christopher Oliver wrote:
At any rate, I fail to understand how a massively non-backward
compatible change can be made which was not even relevant to the subject
voted on.
yes please, can we discuss this again (with a final vote) as I'm not really
convinced about the pros of this change.
Christopher Oliver wrote:
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
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
Oh, really? The license on my code is (and always was) MIT (i.e. more
lenient than Apache) . If there is a problem with that then you also
have a problem with Torsten's project (which is obviously based on my code).
I don't see any reason why you shouldn't remove it in favor of Torsten's
projec
If you ask me, this is mainly a semantic problem, not a technical one.
If a template is not called from a (Javascript) flowscript, there is no
FOM, and therefore no FOM variables are available in JXTG. For the case
where it _is_ called from a flowscript, then the FOM is and IMO should
be accessi
Christopher Oliver wrote:
>> 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.
>> Your respect/care for the c
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
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-dev&m=110210971210386&w=2
<http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110210971210386&w=2>.
> > I mean, give
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 to mak
I'm no longer particpating in Cocoon development. Please post any
questions regarding Cocoon to the dev mailing list.
Thanks,
Chris
[EMAIL PROTECTED] wrote:
Hello,
sorry to bother you in private, but you're my last hope of finding the
solution to my problem. I've posted my problems on the variou
Bruno Dumon wrote:
I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump right into it:
Form.showForm()
===
I find that this function hides too much of how a form is processed, and
stands in the way of doing more a
Ugo Cei wrote:
Il giorno 24/apr/04, alle 23:35, [EMAIL PROTECTED] ha scritto:
coliver 2004/04/24 14:35:35
Modified:src/java/org/apache/cocoon/generation
JXTemplateGenerator.java
Log:
Allow a nodeset to be returned as the result of xpath evaluation
Before t
Leszek Gawron wrote:
Sorry to bother you privately but I did not get the answer on cocoon group and
I see you're the main JXTG developer.
My question is: Is there any real reason that jx:attribute is not implemented?
Something that would work as xsl:attribute or xsp:attribute to allow
generation o
Tony Collen wrote:
Leszek Gawron wrote:
Say you have this DOM you pass to a template:
template follows:
http://apache.org/cocoon/templates/jx/1.0";>
#{document/root/path/fileset}
The r
This is due to the behavior of JXPath. If you want to process a node set
you need forEach:
http://apache.org/cocoon/templates/jx/1.0";>
#{.}
Your example is equivalent to:
JXPathContext cx = JXPathContext.newContext(document);
Node node = (Node)cx.ge
I've checked in a fix for this. The next event after a
was being ignored. The bug was unnoticeable in many cases however
because in such cases that event was just whitespace. Thanks for
reporting the problem.
Chris
Bruno Dumon wrote:
While using the template.jx macros for CForms I noticed th
There's not enough information in that bug report to determine the
problem. Can you try to debug why a URLSource (with exists() == true) is
being returned by the source resolver for the (presumably nonexistent)
resource "org.java"?
I had no luck debugging this since I can't recreate the problem
I"ve just committed a fix for this.
Regards,
Chris
Leszek Gawron wrote:
On Wed, Apr 21, 2004 at 12:45:46PM -0700, Christopher Oliver wrote:
Leszek Gawron wrote:
Am I wrong or there is no way to handle iterators in JXTG? One can use
forEach
for collections but I sometimes would
Leszek Gawron wrote:
Am I wrong or there is no way to handle iterators in JXTG? One can use forEach
for collections but I sometimes would like to pass and iterator to a view to
process larger result sets.
In Hibernate you can:
var list = session.createQuery("from LargeTable").list() which creates
Reinhard Poetz wrote:
I already said in several mails that we should reduce the recommended
options:
1.) Use O/R-mapper if possible
2.) if you only have publishing tasks use the sqlTransformer
3.) If the learning curve for an O/R-mapper is too steep for you take
(In my opinion this i
Since #{person/traits} and #{values} are Maps (which are treated as "dynamic" beans by JXPath) try this:
#{./name}
#{./name}#{./value}
Chris
[EMAIL PROTECTED] wrote:
I do hope som
Sylvain Wallez wrote:
Christopher Oliver wrote:
I can't say that I fully understand your problem, but I just looked
at o.a.c.f.util.JavascriptHelper, and that appears to have some major
bugs. If it isn't called from a flow script it uses a static
JavaScript object as the top l
No. That won't work. With the current implementation of JXTG XPath
evaluation of absolute paths with a only works if the
expression passed to is an XPath expression. Does this work:
#{//foo/bar}
Chris
Stephan Coboos wrote:
Hello,
I've tried to retrieve an object within a JXTemplate:
Ugo Cei wrote:
Il giorno 17/apr/04, alle 20:28, Christopher Oliver ha scritto:
I think you can use a combination of session attributes and jx macros
to get the effect you want, e.g.
// Flow script
function toSAX(str, consumer) {
...
}
cocoon.session.setAttribute("stringToSAX", to
I think you can use a combination of session attributes and jx macros to
get the effect you want, e.g.
// Flow script
function toSAX(str, consumer) {
...
}
cocoon.session.setAttribute("stringToSAX", toSAX);
function myPage() {
...
sendPage("page.html", {...});
}
// template
Since
I can't say that I fully understand your problem, but I just looked at
o.a.c.f.util.JavascriptHelper, and that appears to have some major bugs.
If it isn't called from a flow script it uses a static JavaScript object
as the top level scope (where JS global variables are created), but does
not e
I just committed a fix to ScriptableWidget to allow you to pass a null
validation error.
HTH,
Chris
Mark Lundquist wrote:
On Apr 14, 2004, at 12:55 PM, Joerg Heinicke wrote:
On 14.04.2004 21:48, Mark Lundquist wrote:
As I wrote before I'm nearly sure it works for me with woody2.js.
How are y
Bruno Dumon wrote:
On Tue, 2004-04-06 at 18:19, Christopher Oliver wrote:
Bruno Dumon wrote:
For the generator-approach, a good starting point would be to commit it
to CVS and add or change an example to show how it works.
I've done this for the V2 flowscript s
Bruno Dumon wrote:
On Mon, 2004-04-05 at 13:28, Sylvain Wallez wrote:
So, I propose the following changes to Cocoon forms:
- add a state to widgets (enabled/disabled/hidden).
- move to a generator approach.
WDYT?
For the generator-approach, a good starting point would be to commit it
to C
Stephan Michels wrote:
Am Mo, den 05.04.2004 schrieb Christopher Oliver um 22:44:
Why don't use (Object obj, Method method, Object[] args) in the
constructor of the continuation object.
That's a possible alternative, but makes prevents making Continuation an
abstract class
Tim Larson wrote:
On Tue, Apr 06, 2004 at 12:30:03PM +0200, Leszek Gawron wrote:
In v2 I have to do something like this:
form = new Form( definition );
form[ "globalAppContext" ] = getGlobalAppContext();
form[ "user" ] = getLoggedInUser();
form[ "userContext" ] = getContextForUser( getLoggedI
Leszek Gawron wrote:
none of these is strictly connected to the form (the only one is the rowset
displayed as the form controls invoke actions that change this part of view).
In v2 I have to do something like this:
form = new Form( definition );
form[ "globalAppContext" ] = getGlobalAppContext
Stephan Michels wrote:
First, I'm glad to hear more input ;-) Your mail took some time
to parse it.
Am Mo, den 05.04.2004 schrieb Christopher Oliver um 18:47:
OK, IIUC there are three modes of execution of the instrumented code:
1) isCapturing
During this mode the JVM call stack is un
ject is invoked we will again unwind the current JVM
stack, but this time there's no need to capture it.
Chris
Christopher Oliver wrote:
Stephan Michels wrote:
Am Mo, den 05.04.2004 schrieb Christopher Oliver um 4:42:
The current implementation needs some work to qualify as
"gener
Stephan Michels wrote:
Am Mo, den 05.04.2004 schrieb Christopher Oliver um 4:42:
The current implementation needs some work to qualify as "generalized
Java continuations". It would be nice to make it work more like Scheme
continuations:
1) When you access the "current&qu
t word), but has been
waiting for generalized Java continuations rather than hack it into
the language.
-Brian
On Apr 4, 2004, at 2:32 PM, Christopher Oliver wrote:
Stefano Mazzocchi wrote:
Antonio Gallardo wrote:
Hi:
Hi:
Some of us wanted to see Groovy support in Cocoon. Now we can
&qu
Stefano Mazzocchi wrote:
Antonio Gallardo wrote:
Hi:
Hi:
Some of us wanted to see Groovy support in Cocoon. Now we can "play" a
little with Groovy using the recently added support for Groovy script
generator under the BSF block. More info about how to use it is here:
http://cocoon.apache.org/2.
Leszek Gawron wrote:
On Sat, Apr 03, 2004 at 01:58:51PM -0800, Christopher Oliver wrote:
These ContinuationsManager API should _not_ be used in a flowscript. Use
the sitemap to invoke your continuation, please.
Is it possible to solve your problem by using a helper function to send
the page
Uh, thanks. But Leszek is talking about the JS function
handleContinuation() defined in fom_system.js - not the Java method that
you point out. That method is not accessible to flowscripts.
Chris
Tony Collen wrote:
Tony Collen wrote:
Christopher Oliver wrote:
Leszek Gawron wrote
Leszek Gawron wrote:
On Sat, Apr 03, 2004 at 03:55:54PM -0800, Christopher Oliver wrote:
Sylvain Wallez wrote:
Christopher Oliver wrote:
These ContinuationsManager API should _not_ be used in a flowscript.
Use the sitemap to invoke your continuation, please.
Although I
Sylvain Wallez wrote:
Christopher Oliver wrote:
These ContinuationsManager API should _not_ be used in a flowscript.
Use the sitemap to invoke your continuation, please.
Although I found this hacky, is there any technical reasons that
prevents this to work?
Sylvain
Yes, the FOM_Cocoon
These ContinuationsManager API should _not_ be used in a flowscript. Use
the sitemap to invoke your continuation, please.
Is it possible to solve your problem by using a helper function to send
the page:
function sendPageAndWait(uri, biz, ttl) {
cocoon.response.setHeader( "Expires", "-1" );
c
Sylvain Wallez wrote:
Bruno Dumon wrote:
I found the possibility to add arbitrairy attributes to widgets, made
possible in the v2 forms flowscript integration, to be a quite nice
feature. However, that feature only exists in the javascript model. This
is a problem when one wants to pass back the
http://marc.theaimsgroup.com/?t=107083319900025&r=1&w=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",
FOM_JavaScriptFlowHelper.getFOM_Req
Stephan Coboos wrote:
Is it a bug? Should I post it in the bugtracker?
It's a bug. The ServiceManager isn't initialized when you run
JXTemplateGenerator as a transformer. I'll commit a fix shortly.
Chris
Sounds like a bug. Can you post the stack trace?
Thanks,
Chris
Stephan Coboos wrote:
Hello,
the element doesnt work in
JXTemplateTransformer. If I'am using this element I got a
java.lang.NullPointerException. In the JXTemplateGenerator instead it
works fine. Is it a bug? Should I add it to
Stephan Michels wrote:
Thank you that you didn't take it wrong :)
Okay here another vote(and I wait more than 24h)
Move java into scratchpad?
[ ] Move it into scratchpad
[+1 ] Leave it where it is
[ ] Rename it to ___
Chris
Torsten Curdt wrote:
Dear friends and folks,
as already announce on the PMC list we now
have another flow implementation for java!
Stephan completed my proof-of-concept and
replaced the Brakes stuff by an own
implementation. So we are now fully in
ASL land.
Cool.
We would like to commit this i
http://schematics.sourceforge.net/scheme-london/nmk-case-study.pdf
Will the new block system allow plugging in a block's documentation? One
of the things I find most annoying about adding code to the Cocoon Forms
block is that there seems to be no reasonable place to put documentation
- or am I missing something?
Chris
-Original Message-
From: Stefano Ma
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Why is there a need to have a different API for widgets when used
from JS than when used from Java? IMO, this is arbitrarily
limiting the features available in flowscript.
But isn't this our design approach? If I remember cor
Sylvain Wallez wrote:
Christopher Oliver wrote:
Sylvain Wallez wrote:
Christopher Oliver wrote:
Tim Larson wrote:
In: cocoon-2.1/src/blocks/forms/samples/v2/forms_flow_example.js
Should this:
// 'wid' is a javascript wrapper of the Cocoon Form widget.
//
// Its subwidg
Sylvain Wallez wrote:
Christopher Oliver wrote:
Tim Larson wrote:
In: cocoon-2.1/src/blocks/forms/samples/v2/forms_flow_example.js
Should this:
// 'wid' is a javascript wrapper of the Cocoon Form widget.
//
// Its subwidgets can be accessed by id.
be changed to this:
//
Tim Larson wrote:
On Thu, Mar 18, 2004 at 02:33:51PM +, Tim Larson wrote:
On Wed, Mar 17, 2004 at 02:31:53PM -0800, Christopher Oliver wrote:
Tim Larson wrote:
On Wed, Mar 17, 2004 at 11:18:35AM -0800, Christopher Oliver wrote:
Tim Larson wrote:
On Tue, Mar
The problem (I think) is that he is trying to use JXTG in a pipeline
called from the Form constructor, e.g.
var form = new Form("cocoon:/whatever");
However, the "cocoon" variable in JXTG is only set up when the pipeline
is called from a Flowscript via cocoon.sendPage*().
Vadim raised this is
Tim Larson wrote:
On Wed, Mar 17, 2004 at 11:18:35AM -0800, Christopher Oliver wrote:
Tim Larson wrote:
On Tue, Mar 16, 2004 at 09:16:38PM +, Tim Larson wrote:
One of the specific questions is in this code:
var wk = cocoon.sendPageAndWait(uri, this.formWidget_, fun, ttl);
var
Tim Larson wrote:
In: cocoon-2.1/src/blocks/forms/samples/v2/forms_flow_example.js
Should this:
// 'wid' is a javascript wrapper of the Cocoon Form widget.
//
// Its subwidgets can be accessed by id.
be changed to this:
// 'wid' is a javascript wrapper of the Cocoon Form widget.
//
Tim Larson wrote:
On Tue, Mar 16, 2004 at 09:16:38PM +, Tim Larson wrote:
I am trying to migrate to the v2 Form.js, but I am having trouble
understanding how the onValidate handling works. From reading to code
it looks to me like it would not work correctly, but the sample form
work proper
Steven Noels wrote:
On 08 Mar 2004, at 23:09, Stefano Mazzocchi wrote:
unless donated by the well-known friendly-neightbor-organization
directly, that is.
I took the plunge and started talking. See my other mail.
Hopefully that will lead to something productive. However, it still
won't so
In order to allow the use of Flowscript on the BEA Weblogic and IBM
Websphere application servers (and possibly in other environments) I
propose that we rename the Rhino packages from org.mozilla to
org.cocoondev. The Rhino codebase used in Cocoon is currently hosted on
cocoondev.org
(http://c
class can be called from the macro.
Chris
Vadim Gritsenko wrote:
Christopher Oliver wrote:
Can we also get rid of the original Woody flowscript API as part of
this process (and replace it with the v2 version)? The original was
clearly not ready for prime time.
This new API, does it allow cre
Can we also get rid of the original Woody flowscript API as part of this
process (and replace it with the v2 version)? The original was clearly
not ready for prime time.
--
Chris
Reinhard Pötz wrote:
In the next few days I'm going to rename Woody to Cocoon Forms. So
please don't commit into th
Stephan Coboos wrote:
Christopher Oliver wrote:
You could use the JXTemplate generator to do this without Java
programming:
--
Chris
Thank you, Chris. But I need to write my own transformer for several
reasons.
Can you explain the other reasons?
So I can't use JXTransforme
You could use the JXTemplate generator to do this without Java
programming:
--
Chris
-Original Message-
From: Stephan Coboos [mailto:[EMAIL PROTECTED]
Sent: Friday, March 05, 2004 11:15 AM
To: [EMAIL PROTECTED]
Subject: Usage of SAXBuffer?
Hello,
I want to write my ow
Can you try reverting the rhino jar to a previous version and see if
that fixes the problem? I may have introduced a regression.
Thanks,
Chris
Jeremy Quinn wrote:
Hi All
I just upgraded my copy of Cocoon to today's CVS version.
A (previously working) site that uses a lot of FlowScript has go
I'm unable to recreate this problem. Can you provide more information?
--
Chris
Mark Lundquist wrote:
Hi,
(I'm using Cocoon 2.1.3...)
I have something like this in a JXTemplate:
and it barfs:
Cannot format given Object as a Date
But if I change the template to
...then I get this:
Fri F
Stephan Coboos wrote:
Hello,
in some discussions I'd heard that actions and XSP should be more and
more replaced by flowscript. I think, this is a good idea because
flowscript is a good way to integrate logic parts into an application.
But with one thing I cant agree. Why shouldn't it be possi
I'm not sure how this got broken in 2.1.4 but one way to fix it is to simply remove the flow-interpreters line from components:
name="jx" src="org.apache.cocoon.generation.JXTemplateGenerator"/>
<<== REMOVE THIS LINE
class="org.a
he repository string. Why does it capitalize the
first r in repository for instance?
Also, this particular flow script imports other packages from different
blocks without this error occurring. It only occurs when using the
repository package.
Unico
-Original Message-
From: Christop
What error did you get with "repository"? It is not a JS keyword.
Chris
[EMAIL PROTECTED] wrote:
unico 2004/02/25 01:48:35
Modified:src/blocks/slide/samples flow.js
Log:
rhino seems to barf on 'repository' keyword
Revision ChangesPath
1.12 +1 -2 cocoon-2.1/src/bl
Christopher Oliver wrote:
Bertrand Delacretaz wrote:
Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a
écrit :
...I did some informal tests and it appears to actually be slower
than interpreted Rhino (not sure exactly why, perhaps because Rhino
bytecodes are higher level
Bertrand Delacretaz wrote:
Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a
écrit :
...I did some informal tests and it appears to actually be slower
than interpreted Rhino (not sure exactly why, perhaps because Rhino
bytecodes are higher level), but was significantly
Bertrand Delacretaz wrote:
Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a
écrit :
...I did some informal tests and it appears to actually be slower
than interpreted Rhino (not sure exactly why, perhaps because Rhino
bytecodes are higher level), but was significantly
I recently took a look at joeq (http://joeq.sourceforge.net/) which is a
Java virtual machine written in Java. Included is a "reflective" Java
interpreter that can run on top of an existing Java virtual machine
(e.g. Sun JRE). It can interpret class files, but can also delegate some
(or all) me
What do you think of renaming the Rhino packages in the cocoondev.org
version of Rhino used by Cocoon? It appears both Weblogic and Websphere
ship their own versions of Rhino that are exposed to the class loader
used by Cocoon. This prevents using flowscript "out-of-the-box" or at
all with thes
ez wrote:
Gianugo Rabellino wrote:
Christopher Oliver wrote:
That is a problem with JXPath. I may be wrong, but if IIRC it
doesn't support namespaces properly or at all.
Bad bad news. Actually it seems to do selections just fine, but
insertions are flawed. OK, time for tricks then
Vadim Gritsenko wrote:
Hi all,
Documentation [1] states that JXTemplate generator has cocoon.request
/ cocoon.session / etc variables declared to access
request/session/etc. And, that it has request / session / etc
variables that also provide access to the similar objects.
Now, the issue is t
That is a problem with JXPath. I may be wrong, but if IIRC it doesn't
support namespaces properly or at all.
Gianugo Rabellino wrote:
... I still consider myself quite a newbie on Woody, but I'm facing a
tough issue. I need to bind a woody form to some namespaced XML (a
SourcePropsWritingTrans
I noticed the Petstore and Linotype samples were both broken _after_ the
release. I'm not sure what caused this but it'd probably be a good idea
to test all the samples before releasing next time. BTW Linotype is
still broken.
Regards,
Chris
IIRC, 2.1.2 contains a Rhino regression (I introduced) that breaks flow
completely.
Bertrand Delacretaz wrote:
Did I miss something, or is there a good reason why 2.1.2 is not
available for download anymore on our mirrors?
-Bertrand
Saw this on lenya-dev:
De: "Gregor J. Rothfuss" <[EMAIL PRO
Vadim Gritsenko wrote:
Antonio Gallardo wrote:
jxforms are deprecated. if you are starting avoid using jxform.
Actually, only xmlform block is officially deprecated (see
block.properties).
Now, if you think that it should be deprecated, you can start
discussion in this thread :-)
Vadim
+1
Ugo Cei wrote:
Christopher Oliver wrote:
Ugo Cei wrote:
I'm experiencing a memory leak in an application we are currently
testing, which uses Flowscript and Woody. Since continuations store
a reference to local variables, and the memory leak does not
manifest itself if I don't
Do you have global variables in your scripts?
Ugo Cei wrote:
Christopher Oliver wrote:
Ugo Cei wrote:
I'm experiencing a memory leak in an application we are currently
testing, which uses Flowscript and Woody. Since continuations store
a reference to local variables, and the memory leak
Ugo Cei wrote:
Dear friends,
I'm experiencing a memory leak in an application we are currently
testing, which uses Flowscript and Woody. Since continuations store a
reference to local variables, and the memory leak does not manifest
itself if I don't create any continuation, I'm starting to su
I don't think Rhino supports overloading of jsFunction_xxx(). The two
jsFunction_setSelectionList() functions need to be merged into one method.
HTH,
Chris
Steven Noels wrote:
Hi,
I have an interesting issue that I'd like to see confirmed, since we
suspect Rhino behaves differently under Ap
Try:
${item['pac_descripción']}
As regards the blank page I just checked in a fix to catch TokenMgrError
(which is an Error, not an Exception) in this case and wrap it in a
SAXException.
I'm completely ignorant about non-ascii environments so I'm not sure if
pac_descripción should be a legal
Sylvain Wallez wrote:
I made no answer to your recent addition to Woody because of lack of
time, but will do it very soon (it contains very interesting stuff).
Ok. No pressure.
I do think, however, that the flowscript integration should just be an
/integration/ and not an extension. By this, I
Sylvain Wallez wrote:
Joerg Heinicke wrote:
My plan is to make some of the most useful Woody classes directly
visible in the JS snippets. This includes ValidationError, among
others.
Seems like a hack, but anyway...
Does this mean like import in Java, so that it is possible to access
the
Seems easy to add:
import java.util.*;
public class Repeater {
...
public void sortRows(Comparator comp) {
Collections.sort(this.rows, comp);
}
...
}
Anyone have a reason not to add this?
Jan Hoskens wrote:
Hi,
Is it possible to do a sort on a pa
Hunsberger, Peter wrote:
Christopher Oliver <[EMAIL PROTECTED]> writes:
Hunsberger, Peter wrote:
Christopher Oliver <[EMAIL PROTECTED]> asks:
sendPage*() is not reentrant in 2.1.3. I believe this has
been fixed in
2.1.4-dev. Can you try it?
Ok, now ha
Hunsberger, Peter wrote:
Christopher Oliver <[EMAIL PROTECTED]> asks:
sendPage*() is not reentrant in 2.1.3. I believe this has
been fixed in
2.1.4-dev. Can you try it?
Ok, now have 2.1.4-dev from last night working. It only runs as an
expanded EAR file (we deploy Cocoon in an
null;
try {
InputStream is = src.getInputStream();
if (is == null) {
return null;
}
...
Hunsberger, Peter wrote:
Christopher Oliver <[EMAIL PROTECTED]> writes:
From your description, sounds like someone extended a class
provid
From your description, sounds like someone extended a class provided by
the container which is declared final in Tomcat but not in Jetty. Can
you set a breakpoint on VerifyError and find out which class it is?
Hunsberger, Peter wrote:
Christopher Oliver <[EMAIL PROTECTED]> writes:
se
Feel free to add it..
Tony Collen wrote:
Antonio Gallardo wrote:
Christopher Oliver dijo:
Antonio, that wasn't a typo. It is supposed to indicate "one or more".
Sorry. I understand now. The "+" was written in the sense of "lex"
tokens
or "regula
1 - 100 of 302 matches
Mail list logo
