Christopher Oliver wrote:
getter() and setter() aren't supported by Rhino.
Do you mean this particular syntax or the whole concept of property
getter and setters?
(I found this at
http://devedge.netscape.com/library/manuals/2000/javascript/1.5/guide/obj.html#1018325)
Sylvain
--
Sylvain
Ahh, I see what the issue is in general: there are currently no places
in our app where we've got anything other than a two state flow: GET -
POST jumping to another flow is a completely different GET/POST pair,
thus a new cookie and a new continuation. Two ways around this:
1) concatenate the
Christopher Oliver wrote:
The problem is that x is a JavaScript wrapper of a HashSet. Jexl's
special size() function only support collections and arrays. Perhaps
that can be fixed by unwrapping NativeJavaObject's before adding them to
the Jexl context.
If this solves the problem, I'm +1 for it.
Hi:
The lastest changes in treeprocessor broke the xsp-action. The problem is
in method setup() in o.a.c.generation.ServerPagesGenerator.java this class
needs a SourceResolver. Here is the header of the method:
public void setup(SourceResolver resolver, Map objectModel, String src,
Parameters
On 21.01.2004 04:46, Antonio Gallardo wrote:
Antonio Gallardo dijo:
Sylvain Wallez dijo:
Do you mean you want to remove wd:booleanfield and add a styling
type=checkbox?
Yep. This will be clear and for another part a faster parsing of
definition.
WDYT?
Sounds reasonable.
Joerg
Antonio Gallardo wrote:
Hi:
The lastest changes in treeprocessor broke the xsp-action. The problem is
in method setup() in o.a.c.generation.ServerPagesGenerator.java this class
needs a SourceResolver.
Ooops,sorry! It should be fixed now. Please cross-check!
Sylvain
--
Sylvain Wallez
Any objections on adding following to the FOM_WebContinuations:
* setUserObject
* getUserObject
* display
?
Vadim
The whole concept
Sylvain Wallez wrote:
Christopher Oliver wrote:
getter() and setter() aren't supported by Rhino.
Do you mean this particular syntax or the whole concept of property
getter and setters?
(I found this at
Yes.
Ugo Cei wrote:
Christopher Oliver wrote:
The problem is that x is a JavaScript wrapper of a HashSet. Jexl's
special size() function only support collections and arrays. Perhaps
that can be fixed by unwrapping NativeJavaObject's before adding them
to the Jexl context.
If this solves
Why do you need those? I don't see any reason to add them.
Vadim Gritsenko wrote:
Any objections on adding following to the FOM_WebContinuations:
* setUserObject
* getUserObject
* display
?
Vadim
Vadim Gritsenko wrote:
Christopher Oliver wrote:
Why do you need those? I don't see any reason to add them.
Vadim Gritsenko wrote:
Any objections on adding following to the FOM_WebContinuations:
* setUserObject
* getUserObject
Don't know why they are in WebContinuations in a first place,
Joerg Heinicke wrote:
On 21.01.2004 04:46, Antonio Gallardo wrote:
Antonio Gallardo dijo:
Sylvain Wallez dijo:
Do you mean you want to remove wd:booleanfield and add a styling
type=checkbox?
Yep. This will be clear and for another part a faster parsing of
definition.
Sorry, I don't
Antonio Gallardo [EMAIL PROTECTED] writes:
Hunsberger, Peter dijo:
It appears that if you attempt to close an already closed
stream you
get an IO exception. This means that if Cocoon gets stopped and
restarted it is possible, in at least some circumstances,
for Cocoon
to throw
Torsten Curdt [EMAIL PROTECTED] writes:
Ahh, I see what the issue is in general: there are
currently no places
in our app where we've got anything other than a two state
flow: GET
- POST jumping to another flow is a completely different GET/POST
pair, thus a new cookie and a new
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
AFAIK, that is already the behavior. If you invalidate the parent,
it invalidates all of its children.
Yes, if it has them. But the problem here is that he has got no
children. You have to stick all the different web continuations trees
generated
Hm... I cannot see how this would help. Continuations have
there stack on the server side.
In general you're right it's not useful, you'd only be able to support
this with a back button on the page that told the server to pop the
stack. You wouldn't have browser back button support.
I still
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
AFAIK, that is already the behavior. If you invalidate the parent,
it invalidates all of its children.
Yes, if it has them. But the problem here is that he has got no
children. You have to stick all
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26292.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Vadim Gritsenko wrote:
snip
AFAIK, that is already the behavior. If you invalidate the parent, it
invalidates all of its children.
Yes, if it has them. But the problem here is that he has got no
children. You have to stick all the different web continuations trees
generated by showForm calls
Torsten Curdt [EMAIL PROTECTED] writes:
Hm... I cannot see how this would help. Continuations have
there stack on the server side.
In general you're right it's not useful, you'd only be able
to support
this with a back button on the page that told the server to pop the
stack.
Taking Sylvain's idea of ContinuationLocal variables, I prototyped an
implementation. Since the continuation local variable must be associated
with the object managing the actual continuations, I made FOM_Cocoon
the factory for creating these (but another object could provide this
role). I've
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26292.
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://nagoya.apache.org/bugzilla/show_bug.cgi?id=26292.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
What I mean is that there is no framework for creating multi-page forms
and no automated support back-forward navigation. As a result you were
required to hack...
Chris
Vadim Gritsenko wrote:
Christopher Oliver wrote:
Vadim Gritsenko wrote:
snip
AFAIK, that is already the behavior. If you
Hunsberger, Peter wrote:
Vadim Gritsenko [EMAIL PROTECTED] writes:
Also, one more method is needed:
* addChild(FOM_WebContinuation)
To answer a question why it is needed: you need it to stitch together
different part of the multi-form application, so you can
invalidate all
of them at once
Christopher Oliver wrote:
What I mean is that there is no framework for creating multi-page
forms and no automated support back-forward navigation. As a result
you were required to hack...
True; but this framework will still have to organize WebContinuations,
so addChild() will still be
Ok, as discussed earlier, here goes:
The basic issue is that we don't want to include the continuation id
with the individual page as request data. If you do, you can't cache
the form (server side). For a forms heavy system like ours where 1000's
of forms can be viewed simultaneously by 100's
Christopher Oliver wrote:
Taking Sylvain's idea of ContinuationLocal variables, I prototyped an
implementation. Since the continuation local variable must be
associated with the object managing the actual continuations, I made
FOM_Cocoon the factory for creating these (but another object
Christopher Oliver wrote:
Vadim Gritsenko wrote:
snip
AFAIK, that is already the behavior. If you invalidate the parent,
it invalidates all of its children.
Yes, if it has them. But the problem here is that he has got no
children. You have to stick all the different web continuations trees
Sylvain Wallez wrote:
Christopher Oliver wrote:
Vadim Gritsenko wrote:
snip
AFAIK, that is already the behavior. If you invalidate the parent,
it invalidates all of its children.
Yes, if it has them. But the problem here is that he has got no
children. You have to stick all the different web
Christopher Oliver wrote:
Sorry, I just looked at woody2.js and it actually doesn't do things
this way (woody.js did - btw, why have both?). In woody2.js showForm()
simply calls cocoon.sendPageAndWait() in a loop. It seems to return
the first continuation created. I guess if you save this one,
In the cforms bindings we have wb:insert-node implemented
as a factory. This means that the contained node is only
and always created when a createPath* method is called.
Some side effects of this design are that the regular DOM
factory gets unregistered and there is no way (except by
using a
On 21.01.2004 17:18, Sylvain Wallez wrote:
Do you mean you want to remove wd:booleanfield and add a styling
type=checkbox?
Yep. This will be clear and for another part a faster parsing of
definition.
Sorry, I don't understand that sentence :-/
Faster parsing should mean one widget-type less I
Vadim Gritsenko wrote:
Christopher Oliver wrote:
Sorry, I just looked at woody2.js and it actually doesn't do things
this way (woody.js did - btw, why have both?). In woody2.js
showForm() simply calls cocoon.sendPageAndWait() in a loop. It seems
to return the first continuation created. I
Hunsberger, Peter dijo:
I'm not sure I even see a reason for logging it at INFO? If you've got
an error that occurs because the client closed the socket you're either
going to know this, or if you turn up logging to the INFO level to try
and find this out you're going to need some way to
Joerg Heinicke dijo:
On 21.01.2004 17:18, Sylvain Wallez wrote:
Do you mean you want to remove wd:booleanfield and add a styling
type=checkbox?
Yep. This will be clear and for another part a faster parsing of
definition.
Sorry, I don't understand that sentence :-/
Faster parsing should
Hi,
I am using Apache Cocoon ver 2.1.2. I am developing an app using JXForms and
Flowscript.
I have a simlpe Java file which prints Hello World.This java file does not
have any package name.
Now,from my flowscript, I want to call this java file.
Can you please advise me as to how this needs to be
37 matches
Mail list logo
