I apologize if this a brain dead newbie problem.
I copied the portal-fw folder up to the cocoon root. After adding the portal
pipelines to the root sitemap, I get this when I try to save a profile
change (ie, personalize(guest)--Customize--Save)
My root sitemap is here:
cocoon 2.1-dev march 16 cvs checkout
oops
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=17671.
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=17671.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
1) do we really need the session object? the flow is in fact
deprecating the use of sessions for storing stateful data. I would
love to *force* people to think into this way by not making the
session available to them. We can always add it later
David Crossley wrote:
Stefano Mazzocchi wrote:
David Crossley wrote:
snip/
Found it - there is extra whitespace at the end of these
three lines in block.properties, i.e. after the =true
Thank the lord, i am not going mad. Sounds like we
need normalize-space() whenever properties are read.
Call
Vadim Gritsenko wrote:
Pier Fumagalli wrote:
On 17/3/03 20:15, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
snip/
What about adding a 'content encoding' attribute to the 'pipeline'
instead?
'transfer encoding' attribute would make sense, but content encoding...
wait wait wait
I'm using
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
I don't think this will make it difficult to separate it : the object
model is a Map which can hold any kind of objects, and
instrospection-based accessors such as JXPath don't care about the
actual class of objects.
1) Helper functions like
David Crossley wrote:
I went to try to resurrect the Lucene search sample today.
However, i cannot find it anywhere in CVS. Was it deliberately
removed or this is an accidental victim of the refactoring?
Damn, you're right. Probably an accidental victim of the refactoring. I
probably moved them
Nicola Ken Barozzi wrote:
David Crossley wrote, On 18/03/2003 3.37:
Stefano Mazzocchi wrote:
David Crossley wrote:
snip/
Found it - there is extra whitespace at the end of these
three lines in block.properties, i.e. after the =true
Thank the lord, i am not going mad. Sounds like we
need
Nicola Ken Barozzi wrote:
Vadim Gritsenko wrote, On 18/03/2003 3.52:
Pier Fumagalli wrote:
...
That gets the value out of the serializer configuration itself... So,
per
se, we cannot have a per-pipeline text serializer with different
encodings
per different sitemaps...
That's why we have
Ugo Cei wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
1) do we really need the session object? the flow is in fact
deprecating the use of sessions for storing stateful data. I would
love to *force* people to think into this way by not making the
session available to them. We can
Stefano Mazzocchi wrote:
Nicola Ken Barozzi wrote:
I had moved the properties in xml files, so that the whitespace
there is really easy to see. Why did we resort back to property
files for it?
Because flat properties are much less verbose and much more friendly
to edit.
you have a
Stefano Mazzocchi wrote, On 18/03/2003 10.37:
Nicola Ken Barozzi wrote:
...
Serializers, in the real world I mean, not in theoretical abstrations,
are efectively fisrt class components, not just adapters. IMO they
should be treated as such, because there is no real concrete reason
IMHO why this
I am somehow aware that I am abusing sessions here, and that there
is a better way, but it's not that easy to follow, probably. If you
can show it to me, I'd be glad to abandon sessions, but if you take
them away right now, I'm going to be in trouble ;-).
Great, integration between
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-asciiart.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-databases.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-fop.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-bsf.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-chaperon.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-axis.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-batik.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-deli.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-itext.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-html.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-proxy.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-jfor.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-lucene.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-profiler.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-xmldb.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-naming.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-precept.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-taglib.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-slide.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-web3.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-swf.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-jsp.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-linkrewriter.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-php.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-18/cocoon-block-python.html
Buildfile: build.xml
init:
prepare:
[echo]
Ugo Cei wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
1) do we really need the session object? the flow is in fact
deprecating the use of sessions for storing stateful data. I would
love to *force* people to think into this way by not making the
session available to them. We can
(note: [rt]'s are little [RT]s ;)
In Forrest-land, we are using the ResourceExistsAction to handle the
possibility of different input formats. Eg., if index.ehtml or
index.ihtml is present, it will be used in preference to index.xml:
map:match pattern=**.xml
map:act type=resource-exists
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=17063.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Sylvain Wallez wrote:
Ugo Cei wrote:
This is something that I don't fully understand : when you call
cocoon.createSession(), global variables of the various scripts of a
given sitemap are shared through the session. This means, AFAIU, that
each user has then its own independent set of global
Nicola Ken Barozzi wrote:
When my personal need comes, I surely will, although now I have other
things to do. If others want to write a more detailed proposal (Luca for
example) please do.
The *real* fact is that if I do:
xml data - chart transformer - batik - png
It's 10x SLOWER than
How does AbstractTextSerializer sets the content type header in the HTTP
response? The getMimeType method inherited from AbstractSerializer always
returns null...
Pier
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=17696.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I just read this interesting article about how one hacked into an app
server... be careful guys! ;-)
http://www.eweek.com/print_article/0,3668,a=34324,00.asp
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten,
It gets quite complicated, because for the same URL the client might request
a Japanese, shift_jis, text/html view, while another might request a simple
image/jpeg...
It basically implies that the URL is a resource _for_real_ and that the
Resource - 'semantics' or 'the bit of info'.
Vary: *
which effectively disables any caching...
You bet :-) Though now one said that 'source IP' was a valid vary ;-)
Dw
Stefano Mazzocchi wrote:
Vadim Gritsenko wrote:
Pier Fumagalli wrote:
On 17/3/03 20:15, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
snip/
What about adding a 'content encoding' attribute to the 'pipeline'
instead?
'transfer encoding' attribute would make sense, but content encoding...
Stefano Mazzocchi wrote:
David Crossley wrote:
I went to try to resurrect the Lucene search sample today.
However, i cannot find it anywhere in CVS. Was it deliberately
removed or this is an accidental victim of the refactoring?
Damn, you're right. Probably an accidental victim of the
Jeff Turner wrote:
(note: [rt]'s are little [RT]s ;)
...
So, can I check this in, deprecate ResourceExistsAction, and we all
live happily ever after?
Check in resource-exists selector: +1.
Deprecate resource-exists action: +0.
What about resource-exists matcher? ;-)
PS: RT: 1st rule of
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=17063.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Pier Fumagalli wrote:
How does AbstractTextSerializer sets the content type header in the HTTP
response? The getMimeType method inherited from AbstractSerializer always
returns null...
See AbstractProcessingPipeline.java, and see also related to this bug
On 18/03/2003 15:12 Vadim Gritsenko wrote:
PS: RT: 1st rule of sitemap component equivalency: Every action could be
renamed to/rewritten as a matcher
Hehe.
2nd rule: any selection of Matchers can be combined into a Selector :-D
/Steven
--
Steven Noels
Steven Noels wrote:
On 18/03/2003 15:12 Vadim Gritsenko wrote:
PS: RT: 1st rule of sitemap component equivalency: Every action could
be renamed to/rewritten as a matcher
Hehe.
2nd rule: any selection of Matchers can be combined into a Selector :-D
Bzzzt!!! Funny but wrong :)
Matchers have
Vadim Gritsenko wrote:
Jeff Turner wrote:
(note: [rt]'s are little [RT]s ;)
...
So, can I check this in, deprecate ResourceExistsAction, and we all
live happily ever after?
Check in resource-exists selector: +1.
+1 also.
Deprecate resource-exists action: +0.
+0 also ;-)
What about
On 18/03/2003 15:25 Vadim Gritsenko wrote:
2nd rule: any selection of Matchers can be combined into a Selector :-D
Bzzzt!!! Funny but wrong :)
Matchers have side effect by returning map of values.
Aaargh - you're spoiling my joke :-)
/Steven
--
Steven Noels
Jeff Turner wrote:
Heh.. I think you're right. Matchers, Selectors and Actions are all
switches that can do logic. Actions have an unfair advantage in that
they get passed a SourceResolver. I actually wrote a
ResourceExistsMatcher first, then decided a Selector was more
traditional.
In
Vadim Gritsenko wrote:
Steven Noels wrote:
On 18/03/2003 15:12 Vadim Gritsenko wrote:
PS: RT: 1st rule of sitemap component equivalency: Every action
could be renamed to/rewritten as a matcher
Hehe.
2nd rule: any selection of Matchers can be combined into a Selector :-D
Bzzzt!!! Funny but
Vadim Gritsenko [EMAIL PROTECTED] wrote:
Pier Fumagalli wrote:
How does AbstractTextSerializer sets the content type header in the HTTP
response? The getMimeType method inherited from AbstractSerializer always
returns null...
See AbstractProcessingPipeline.java, and see also related to
Sylvain Wallez wrote, On 18/03/2003 15.43:
Vadim Gritsenko wrote:
...
Matchers have side effect by returning map of values.
What about some super-selector (or multi-match ?) that would be
allowed to return sitemap values ?
And make Matchers and Selectors able to use the a MathcerSelectors as a
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=17671.
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=17671.
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=17671.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
There have been a lot of changes made to DOMStreamer lately and I'm grieved to see
without consideration of backwards compatibity. For instance the method
setContentHandler seems to have been removed completely. I use this class quite
heavily throughout my code and I'm getting errors when
Nicola Ken Barozzi wrote:
Sylvain Wallez wrote, On 18/03/2003 15.43:
Vadim Gritsenko wrote:
...
Matchers have side effect by returning map of values.
What about some super-selector (or multi-match ?) that would be
allowed to return sitemap values ?
And make Matchers and Selectors able
On Tue, 2003-03-18 at 16:25, Unico Hommes wrote:
[...]
For
instance the method setContentHandler seems to have been removed
completely.
re-added in CVS (both 2.0 and 2.1).
Thanks for reporting, and don't hesitate to report any further problems
you may have.
--
Bruno Dumon
Stefano Mazzocchi [EMAIL PROTECTED] wrote:
Ugo Cei wrote:
Sylvain Wallez wrote:
I'm using the flow and I'm using sessions too. The applications I'm
currently developing with the flow are composed of many independent
flows, each with its own entry point. Consider the case of an
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=18109.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Tue, 2003-03-18 at 16:25, Unico Hommes wrote:
[...]
For
instance the method setContentHandler seems to have been removed
completely.
re-added in CVS (both 2.0 and 2.1).
Thanks, that does help.
Thanks for reporting, and don't hesitate to report any
further problems
you may
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=18116.
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=18118.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Ugo Cei wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
1) do we really need the session object? the flow is in fact
deprecating the use of sessions for storing stateful data. I would
love to *force* people to think into this way by not making the
session available to them. We can
Upayavira wrote:
I am somehow aware that I am abusing sessions here, and that there
is a better way, but it's not that easy to follow, probably. If you
can show it to me, I'd be glad to abandon sessions, but if you take
them away right now, I'm going to be in trouble ;-).
Great, integration
Stefano Mazzocchi wrote:
Great, integration between different not-all-flowable parts is a *real*
need for sessions in the FOM.
So +1 to add it.
Anybody against it?
Stefano.
-1 for this reason. As mentioned in other mails, direct access to the
session isn't needed in Ugo's case.
+1 for a
Pier Fumagalli wrote:
On 17/3/03 20:02, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
So, I would go for
global - contains global log methods, no properties
global doesn't have a meaning in IDL, therefore I created the Script
object, which will contain also the reference to the function called
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=17063.
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=17063.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Since I now finally have a *real* operating system under my fingers (one
that comes with a compiler!), I'm now coming back to enjoy the freedom
of native code.
I found this thing called heapprofile, some 100 lines of C++ code that
connect to the Java Native Profiler Interface and provide a
Christopher Oliver wrote:
Stefano Mazzocchi wrote:
Great, integration between different not-all-flowable parts is a
*real* need for sessions in the FOM.
So +1 to add it.
Anybody against it?
Stefano.
-1 for this reason. As mentioned in other mails, direct access to the
session isn't needed
Christopher Oliver wrote:
Pier Fumagalli wrote:
On 17/3/03 20:02, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
So, I would go for
global - contains global log methods, no properties
global doesn't have a meaning in IDL, therefore I created the Script
object, which will contain also the
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=18118.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Stefano Mazzocchi wrote:
Another possibility is to only expose the session at the Java level
(not JavaScript) forcing new JavaScript objects that need access to it
to be written in Java. This might prevent abuse.
Hmmm, if you don't get a hook to the ObjectModel, how can you get a java
session
On 18/3/03 21:00, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I assume, but I'm not sure, that [xx are native internal objects, so
there is not much we can do about those. Still, I would like to know
what is that [10 object that accounts for so much memory.
They should be (might be) arrays...
On 18/3/03 19:06, Christopher Oliver [EMAIL PROTECTED] wrote:
global doesn't have a meaning in IDL, therefore I created the Script
object, which will contain also the reference to the function called from
the sitemap...
How about calling the class of this object just Flow? That's what it
On 18/3/03 21:29, Christopher Oliver [EMAIL PROTECTED] wrote:
Stefano Mazzocchi wrote:
Another possibility is to only expose the session at the Java level
(not JavaScript) forcing new JavaScript objects that need access to it
to be written in Java. This might prevent abuse.
Hmmm, if you
Pier Fumagalli wrote:
On 18/3/03 21:29, Christopher Oliver [EMAIL PROTECTED] wrote:
Stefano Mazzocchi wrote:
Another possibility is to only expose the session at the Java level
(not JavaScript) forcing new JavaScript objects that need access to it
to be written in Java. This might
Sylvain Wallez wrote:
Pier Fumagalli wrote:
On 18/3/03 21:29, Christopher Oliver [EMAIL PROTECTED] wrote:
Stefano Mazzocchi wrote:
Another possibility is to only expose the session at the Java level
(not JavaScript) forcing new JavaScript objects that need access to it
to be written in
Pier Fumagalli wrote:
On 18/3/03 21:00, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I assume, but I'm not sure, that [xx are native internal objects, so
there is not much we can do about those. Still, I would like to know
what is that [10 object that accounts for so much memory.
They should be
On 18/3/03 23:03, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
Pier Fumagalli wrote:
On 18/3/03 21:00, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I assume, but I'm not sure, that [xx are native internal objects, so
there is not much we can do about those. Still, I would like to know
what
my bet? Maybe char Arrays allocated during transforms? I ran some OptimizeIt
profiles awhile back and seem to remember these numbers creeping up,
especially during the i18n transformation.
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 18, 2003
On 18/3/03 23:00, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
But I have the impression i didn't understand what Pier was implying
because I'm sure he would not propose to force people to write that much
java gluecode just for everyday FOM usage.
Pier, can you elaborate more on what you
Pier Fumagalli wrote:
On 18/3/03 23:00, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
But I have the impression i didn't understand what Pier was implying
because I'm sure he would not propose to force people to write that much
java gluecode just for everyday FOM usage.
Pier, can you elaborate more
Christopher Oliver wrote:
Sylvain Wallez wrote:
I like your approach _MUCH_BETTER_... I think we should consider it
for most
of the stuff we make visible to the flow, rather than passing the
real Java
instances to Rhino (obviously removing the construction part when
needed)...
Mmmh, I don't
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
http://cvs.apache.org/viewcvs.cgi/*checkout*/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/xmlForm.js?rev=1.3content-type=text/plain
In order to communicate with XMLFormTransformer and to handle
restarting continuations, this
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=18131.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Wednesday 19 March 2003 04:14, Tony Collen wrote:
Reading this great article [1] (Thanks Pier!), I realized that the
mod_rewrite stuff could possibly be worked around using virtualhosts. I'm
not too familliar with Apache HTTPD 2, but I assume setting up vhosts is
not much different. Would
On Wednesday 19 March 2003 07:10, Pier Fumagalli wrote:
On 18/3/03 23:03, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
Pier Fumagalli wrote:
On 18/3/03 21:00, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I assume, but I'm not sure, that [xx are native internal objects, so
there is not much we
1 - 100 of 107 matches
Mail list logo
