A little bit off-toptic, but some time ago I used the pipeline machinery
to generate mail-content for users, somewhere at night by a CRON job.
For each user, the pipeline was called and the results were sent to that
user. Processing such a pipeline from CRON took about 2 seconds for each
mail,
Sylvain Wallez wrote:
So the question is why do we remove the serializer information from the
key and validity for an internal request? Furthermore considering that
calling getInputStream() on a cocoon: source *does* use the Serializer.
I'd like to remove this distinction and have the
The caching algorithm is that smart (or complicated?) that it caches a
pipeline based on the components and their configuration, but
independent of the uri. So, if you have the same pipeline twice with a
different serializer and use the internal protocol it's basically the
same pipeline. If you
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
So the question is why do we remove the serializer information from the
key and validity for an internal request? Furthermore considering that
calling getInputStream() on a cocoon: source *does* use the Serializer.
I'd like to remove this
Sylvain Wallez wrote:
Sorry, I don't follow you here: in my case (as quite often) the sitemap
statements that are executed are exactly the same for the external and
internal requests, including the map:serialize statement. So these are
really the same pipelines.
Yes, in your case, but
Carsten Ziegeler wrote:
Geert Josten wrote:
The caching algorithm is that smart (or complicated?) that it caches a
pipeline based on the components and their configuration, but
independent of the uri. So, if you have the same pipeline twice with a
different serializer and use the internal
Hi,
It is said in the docs that we can use viewData in event handler to access
the data pass through showForm. I saw some messages that said it was
broken. Apparently it doesn't work here. If it's a removed feature what's
the current way of doing this ?
regards
Sorry, I don't follow you here: in my case (as quite often) the sitemap
statements that are executed are exactly the same for the external and
internal requests, including the map:serialize statement. So these are
really the same pipelines.
Yes, in your case, but see my response to Geert :)
Bart Molenkamp wrote:
A little bit off-toptic, but some time ago I used the pipeline machinery
to generate mail-content for users, somewhere at night by a CRON job.
For each user, the pipeline was called and the results were sent to that
user. Processing such a pipeline from CRON took about 2
Sylvain Wallez wrote:
- SitemapSource should be the full key (its hash actually) and full validity
- processing a pipeline to an XML consumer should cache the SAX stream
using the restricted key and restricted validity
- processing a pipeline to an outputStream should cache the byte stream
Is jdtcore.jar only used for compiling Java for XSP pages? I'm not
using XSP currently, so I am
wondering if I can just eliminate that jar file. It doesn't seem to
affect Cocoon. Can anyone confirm?
In trunk jdtcore.jar is only added if you enable the XSP block. Don't
know what
Doesn't Javaflow support serialization?
Javaflow itself does ...but I don't think
our WebContinuation machinery does.
Although this should not be too hard to add.
cheers
--
Torsten
signature.asc
Description: OpenPGP digital signature
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
- SitemapSource should be the full key (its hash actually) and full validity
- processing a pipeline to an XML consumer should cache the SAX stream
using the restricted key and restricted validity
- processing a pipeline to an outputStream
Sylvain Wallez wrote:
IMO these should include the serializer key and validity rather than
stopping at the last transformer (or generator if there's no
transformer). The serializer information cannot be ignored since this
serializer is used when SitemapSource.getInputStream() is called.
Carsten Ziegeler wrote:
Ah ok, thanks - yepp, you're right. I think you're proposed changes
should do now harm, so go ahead.
no or now (Freudian slip? :-p)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Ah ok, thanks - yepp, you're right. I think you're proposed changes
should do now harm, so go ahead.
no or now (Freudian slip? :-p)
LOL, yes no of course...
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
[EMAIL PROTECTED] wrote:
Author: cziegeler
Date: Wed Jun 8 06:43:03 2005
New Revision: 189578
URL: http://svn.apache.org/viewcvs?rev=189578view=rev
Log:
Readd emptyAttributes for compatibility!
But it should be removed in the trunk then - as per versioning guide, right?
Vadim
Modified:
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Author: cziegeler
Date: Wed Jun 8 06:43:03 2005
New Revision: 189578
URL: http://svn.apache.org/viewcvs?rev=189578view=rev
Log:
Readd emptyAttributes for compatibility!
But it should be removed in the trunk then - as per versioning guide,
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
IMO these should include the serializer key and validity rather than
stopping at the last transformer (or generator if there's no
transformer). The serializer information cannot be ignored since this
serializer is used when
I'm in need of a simple URL validator for CForms. It should test
whether a string value represents a well-formed URL and if it doesn't,
prepend http://; and try again.
I think this would nicely cover the use case where you need to specify
a website address in a form but don't want to force
Vadim Gritsenko [EMAIL PROTECTED] wrote on 07.06.2005 14:34:36:
I guess original idea was that text() nodes can be safely ignored,
while
xsp:text nodes are meaningful. It might be still true, haven't
digged deeper...
Hope I'm not too annoying on this issue, but on further work on logic
Ralph Goers wrote:
The problem is that we are recommending (and have been recommending)
CForms as our forms framework for a long time. Even if you haven't
marked it stable, it already should be, based upon those recommendations.
Yes, in an ideal world the API would be fixed, but it seems
Ugo Cei wrote:
I'm in need of a simple URL validator for CForms. It should test
whether a string value represents a well-formed URL and if it doesn't,
prepend http://; and try again.
I think this would nicely cover the use case where you need to specify
a website address in a form but don't
The form definition:
fd:imagemap id=map
fd:sourcetest.gif/fd:source
fd:hint
i18n:textzoomInImage.hint.mapButton/i18n:text
/fd:hint
fd:on-action
javascriptonClickMap(event);/javascript
/fd:on-action
/fd:imagemap
The flow:
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=35273.
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=35273.
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=35273.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Is there an existing solution for a 'select all' / 'deselect all'
button for CForms booleanfield widgets (checkboxes)?
-Daniel
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=35273.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Hi,
Having just passed the discussion on whether or not to ignore the serializer when caching an
internal pipe, the following error message popped into my mind:
Streaming of an internal pipeline is not possible with a reader.
Which is raised by the AbstractProcessingPipeline when the
Ben Pope wrote:
It makes very little sense to mark it stable without it actually being
what is generally considered (by this community) as stable.
You might as well just throw away all semantics, I doubt there are
many people here who want to release something whose API they know
will
Geert Josten wrote:
Hi,
Having just passed the discussion on whether or not to ignore the
serializer when caching an internal pipe, the following error message
popped into my mind:
Streaming of an internal pipeline is not possible with a reader.
Which is raised by the
Ralph Goers wrote:
Ben Pope wrote:
It makes very little sense to mark it stable without it actually being
what is generally considered (by this community) as stable.
You might as well just throw away all semantics, I doubt there are
many people here who want to release something whose API
Ralph Goers wrote:
snip/
The bottom line is you cannot have code sitting around forever telling
people its great but you have to use it at your own risk cause we
might change it anytime we feel like it. This has just been going on
for far too long. The code is never going to be perfect.
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=35275.
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=35275.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
I have committed some initial osgi code in whiteboard (whiteboard/osgi)
so that we can start experiment with a microkernel based Cocoon,
http://marc.theaimsgroup.com/?t=11165964683r=1w=2.
This far we have the following:
OSGi
I decided to use the OSGi framework from
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=33388.
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=33388.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Hi,
I'm looking for a way to use Axis in combination with Cocoon. I
already managed to parse SOAP messages with a higher-level approach
using Axis API's [1] but I still need to automate a few things.
I found a SoapServer interface [2] and a SoapServerImpl [3] class in
Cocoon API documentation,
40 matches
Mail list logo
