Re: svn commit: r219856 - in /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms: binding/MultiValueJXPathBinding.java flow/javascript/ScriptableWidget.java

anches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/form s: binding/MultiValueJXPathBinding.java flow/javascript/ScriptableWidget.java Hi Giacomo, I guess it is related to commons-jxpath-1.2. Can you add the buggy version number of the JXPath lib? This could help in the future to ch

Re: svn commit: r219856 - in /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms: binding/MultiValueJXPathBinding.java flow/javascript/ScriptableWidget.java

eally removing all elements from a Collection type object Modified: cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/binding/MultiValueJXPathBinding.java cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript/ScriptableWidget.

Re: Sitemap: flow and interpreters

On Jun 12, 2005, at 1:18 AM, Ralph Goers wrote: Glen Ezkovich wrote: 2-Should we want to encourage people to write Javaflow instead of JSFlow? No. While I plan on using Javaflow going forward, JSFlow makes flow available to Javascript programers (web masters). Interesting

Re: Sitemap: flow and interpreters

Reinhard Poetz wrote: 2-Should we want to encourage people to write Javaflow instead of JSFlow? no, I think offering both options is enough. People can decide themselves. Actually, I think we need a third option, but I don't know what it is. I've heard the desire to have something that

Re: Sitemap: flow and interpreters

encourage people to write Javaflow instead of JSFlow? no, I think offering both options is enough. People can decide themselves. 3-Need to be a web glue for flow code too? Do you mean that flows of different languages can communicate with each other? If this is your questions, I'd say that se

Re: Sitemap: flow and interpreters

Ralph Goers wrote: Glen Ezkovich wrote: 2-Should we want to encourage people to write Javaflow instead of JSFlow? No. While I plan on using Javaflow going forward, JSFlow makes flow available to Javascript programers (web masters). Interesting that you should say that because that

Re: Sitemap: flow and interpreters

Glen Ezkovich wrote: 2-Should we want to encourage people to write Javaflow instead of JSFlow? No. While I plan on using Javaflow going forward, JSFlow makes flow available to Javascript programers (web masters). Interesting that you should say that because that is exactly the reason

Re: Sitemap: flow and interpreters

ing to JavaFlow. Well, there is a fact we need still need to solve around rhino. On the other side, I hear there are some troubles using Bcel inside JVM-code for java 1.5 (I never tried, perhaps it was only FUD). >> 2-Should we want to encourage people to write Javaflow instead of >> JSFlow

Re: Sitemap: flow and interpreters

. 2-Should we want to encourage people to write Javaflow instead of JSFlow? No. While I plan on using Javaflow going forward, JSFlow makes flow available to Javascript programers (web masters). 3-Need to be a web glue for flow code too? Don't know yet. What is the use case? I

Re: Sitemap: flow and interpreters

ists or will exists the need to migrate JSflow to javaFlow (legal, convenience, user desire or whatever)? 2-Should we want to encourage people to write Javaflow instead of JSFlow? 3-Need to be a web glue for flow code too? If the answer of one of the questions is true, then we should allow them to

Re: Sitemap: flow and interpreters

Carsten Ziegeler wrote: Glen Ezkovich wrote: The fix appears easy, but is something broken? Has someone expressed the desire to use two languages in a single sitemap or is this just an instance of feature creep? I tend to agree, so I think we should for now just forbid to write different m

Re: Sitemap: flow and interpreters

Glen Ezkovich wrote: > > The fix appears easy, but is something broken? Has someone expressed > the desire to use two languages in a single sitemap or is this just > an instance of feature creep? I tend to agree, so I think we should for now just forbid to write different map:flow sections in a

Re: Sitemap: flow and interpreters

On Jun 11, 2005, at 8:41 AM, Carsten Ziegeler wrote: Bertrand Delacretaz wrote: Le 11 juin 05, à 11:30, Carsten Ziegeler a écrit : ...Ok, so we should decide if we want to support more than one flow language per sitemap, first... Is there a need for this? It might lead to some

Re: Sitemap: flow and interpreters

Bertrand Delacretaz wrote: > Le 11 juin 05, à 11:30, Carsten Ziegeler a écrit : > >>...Ok, so we should decide if we want to support more than one flow >>language per sitemap, first... > > > Is there a need for this? It might lead to some confusion, and IIUC > th

Re: Sitemap: flow and interpreters

Le 11 juin 05, à 11:30, Carsten Ziegeler a écrit : ...Ok, so we should decide if we want to support more than one flow language per sitemap, first... Is there a need for this? It might lead to some confusion, and IIUC there's always the workaround of using several sitemaps if someone

Re: svn commit: r189955 - in /cocoon: blocks/scratchpad/trunk/java/org/apache/cocoon/acting/ blocks/scratchpad/trunk/samples/ blocks/scratchpad/trunk/samples/flow-action/ trunk/src/java/org/apache/cocoon/components/treeprocessor/sitemap/

Carsten Ziegeler wrote: Reinhard Poetz wrote: Have you converted to a Javascript fan ;-) No, not really - but I'm fed up with writing all these unnecessary lines for java (package instruction, imports etc.) :) Flow is *soo* easy, just write cocoon.request.getParameter("something

Re: Sitemap: flow and interpreters

Reinhard Poetz wrote: > > You're right that only one flow language can be used within one sitemap. > Additionally to your reasons, there are two others: > > - we need access to the flow controller of a sitemap > (to make e.g. Flowscript

Re: svn commit: r189955 - in /cocoon: blocks/scratchpad/trunk/java/org/apache/cocoon/acting/ blocks/scratchpad/trunk/samples/ blocks/scratchpad/trunk/samples/flow-action/ trunk/src/java/org/apache/cocoon/components/treeprocessor/sitemap/

Reinhard Poetz wrote: > > Have you converted to a Javascript fan ;-) No, not really - but I'm fed up with writing all these unnecessary lines for java (package instruction, imports etc.) :) Flow is *soo* easy, just write cocoon.request.getParameter("something") and you hav

Re: Sitemap: flow and interpreters

Carsten Ziegeler wrote: While inspecting the current sitemap (tree builder) code for flow, I'm wondering about the support for different languages. The basic question first: do we want to support more than one flow language per sitemap? If yes, imho this isn't supported yet. It

Sitemap: flow and interpreters

While inspecting the current sitemap (tree builder) code for flow, I'm wondering about the support for different languages. The basic question first: do we want to support more than one flow language per sitemap? If yes, imho this isn't supported yet. It's possible to regis

Re: svn commit: r189955 - in /cocoon: blocks/scratchpad/trunk/java/org/apache/cocoon/acting/ blocks/scratchpad/trunk/samples/ blocks/scratchpad/trunk/samples/flow-action/ trunk/src/java/org/apache/cocoon/components/treeprocessor/sitemap/

endPage is required in flow if you use the map:call function, so you can't use it. Actually I want to use flow script for prototyping different things, and not just only flow with continuations. The action is only a prototype to see what is possible and what is not. As long as we provide a clean

Re: svn commit: r189955 - in /cocoon: blocks/scratchpad/trunk/java/org/apache/cocoon/acting/ blocks/scratchpad/trunk/samples/ blocks/scratchpad/trunk/samples/flow-action/ trunk/src/java/org/apache/cocoon/components/treeprocessor/sitemap/

Leszek Gawron wrote: > > Why do we add it at all? Some time ago we did not require flowscript to > sendPage so people used it for actions. Now we introduce a hackish > FlowAction to do what we've banned ourselves. > > Or am I wrong? > Don't know. Currently a

Re: svn commit: r189955 - in /cocoon: blocks/scratchpad/trunk/java/org/apache/cocoon/acting/ blocks/scratchpad/trunk/samples/ blocks/scratchpad/trunk/samples/flow-action/ trunk/src/java/org/apache/cocoon/components/treeprocessor/sitemap/

[EMAIL PROTECTED] wrote: Author: cziegeler Date: Fri Jun 10 06:27:54 2005 New Revision: 189955 URL: http://svn.apache.org/viewcvs?rev=189955&view=rev Log: Add FlowAction that executes a function defined in flow script. Add hack to get the current flow Interpreter - we need a better way

Errors thrown by Flow pages aren't explicit anymore???

Hi every one When dealing with any page coming from Flow, if there's an error(during dev), I used to get very clean explicit error definitions, but since a while I noticed these stop at the sitemap error level by only sending map:function call or continuation, which is the base of my Flow

Flow inputModule

Hi everyone Sorry to still bother with this InputModuel thing, I managed finally to declare my component in Flow but the realpath module getAttributeNames("") returns an attribute called requestURI and when I getAttribute("requestURI", null,null), I get a null pointer exc

Re: synchronization in flow script

Sylvain Wallez apache.org> writes: > > Joerg Heinicke wrote: > > >Hello, > > > >I have a question regarding synchronization in flow script. I need an object > >per session, so the instantiation must be synchronized. Furthermore the > >object &g

Re: synchronization in flow script

Joerg Heinicke wrote: Hello, I have a question regarding synchronization in flow script. I need an object per session, so the instantiation must be synchronized. Furthermore the object is an Avalon component, so I need to call something like cocoon.createComponent(). Now how is it possible in Flow

synchronization in flow script

Hello, I have a question regarding synchronization in flow script. I need an object per session, so the instantiation must be synchronized. Furthermore the object is an Avalon component, so I need to call something like cocoon.createComponent(). Now how is it possible in Flow script? The

Re: Flow Input Modules and sitemap global variable ??

iners docs, it was definitly missing somewhere out there. This is great for all my urls all over our website since it replaces any attributes context, but in Flow there is no attribute and since all my logics are in there, I have quite a few context relative paths. I'm afraid it won't

Re: Flow Input Modules and sitemap global variable ??

oceatoon wrote: Hi devers I posted this in Users, but with no luck I'm trying the devers. Is it possible to call an input module from flow to retreive a value like realpath? I know I could pass it from the sitemap but it's a bit complicated, because this particular variable conce

Flow Input Modules and sitemap global variable ??

Hi devers I posted this in Users, but with no luck I'm trying the devers. Is it possible to call an input module from flow to retreive a value like realpath? I know I could pass it from the sitemap but it's a bit complicated, because this particular variable concerns all my pipelines.

Re: svn commit: r124610 - in petstore/java/org/apache/cocoon/components/flow/javascript/...

seudo code to the quoted diff below for both ideas... Gunnar > --- cocoon/branches/BRANCH_2_1_X/src/blocks/petstore/java/org/apache/cocoon/components \ > /flow/javascript/ScriptableConnection.java(original) > +++ cocoon/branches/BRANCH_2_1_X/src/blocks/petstore/jav

Re: Flow and Sessions???

Pier Fumagalli wrote: On 13 Apr 2005, at 16:05, Reinhard Poetz wrote: Pier Fumagalli wrote: Guys, I'm seeing something odd here... Am I correct in saying that every time the flow is invoked (even if it's simply a sendPage() without ANY sendPageAndWait()) a new session is initiali

Re: Flow and Sessions???

On 13 Apr 2005, at 16:05, Reinhard Poetz wrote: Pier Fumagalli wrote: Guys, I'm seeing something odd here... Am I correct in saying that every time the flow is invoked (even if it's simply a sendPage() without ANY sendPageAndWait()) a new session is initialized in the servlet conta

Re: Flow and Sessions???

Pier Fumagalli wrote: Guys, I'm seeing something odd here... Am I correct in saying that every time the flow is invoked (even if it's simply a sendPage() without ANY sendPageAndWait()) a new session is initialized in the servlet container??? no, that's no correct. A session is

Flow and Sessions???

Guys, I'm seeing something odd here... Am I correct in saying that every time the flow is invoked (even if it's simply a sendPage() without ANY sendPageAndWait()) a new session is initialized in the servlet container??? Any way to disable this behavior? Pier

Re: Spring Flow has continuations

Don Brown wrote: The continuation support is only in Java and then in the flow declaration, not Java action-type code. Geert has a good writeup - http://rifers.org/blogs/gbevin Don On Apr 11, 2005 11:21 AM, Leszek Gawron <[EMAIL PROTECTED]> wrote: Tony Collen wrote: Looks like Spring Web Fl

Re: Spring Flow has continuations

The continuation support is only in Java and then in the flow declaration, not Java action-type code. Geert has a good writeup - http://rifers.org/blogs/gbevin Don On Apr 11, 2005 11:21 AM, Leszek Gawron <[EMAIL PROTECTED]> wrote: > Tony Collen wrote: > > Looks like Spri

Re: Spring Flow has continuations

Tony Collen wrote: Looks like Spring Web Flow has continuations now, too: http://www.jroller.com/page/kdonald/20050411 Interestingly enough they link to an article that uses Cocoon as an example :) Do you happen to know what languages do they support? -- Leszek Gawron

Spring Flow has continuations

Looks like Spring Web Flow has continuations now, too: http://www.jroller.com/page/kdonald/20050411 Interestingly enough they link to an article that uses Cocoon as an example :) Tony

Re: Cocoon Performance Woes, Is it flow? I don't know!

Ralph Goers wrote: So does this mean the problem you are having seems to be with cocoon forms or that specific form? It sounds like you have eliminated flow as the culprit? I don't think it means that completely... I have other pages in my load test that also have cocoon forms (though som

Re: Cocoon Performance Woes, Is it flow? I don't know!

ely 3 second wait time between page requests. Looking with Ethereal, I can seen that the client is not using cookies, and that each thread appears to have it's own keep-alive connection. Note that flow is used even in the case when I removed the refine-search form, as the top-level config

Re: Cocoon Performance Woes, Is it flow? I don't know!

So does this mean the problem you are having seems to be with cocoon forms or that specific form? It sounds like you have eliminated flow as the culprit? Ralph Eric E. Meyer wrote: Using JMeter, 50 threads each requesting the five pages in sequence - with an approximately 3 second wait time

Re: Cocoon Performance Woes, Is it flow? I don't know!

On Mar 18, 2005, at 5:19 PM, Antonio Gallardo wrote: Try to switch to ehcache. I hear some ratings to the slowness of jcs cache (the default cache system in in 2.1.5.1). BTW in 2.1.6 I think the default cache system is ehcache, one more reason to move to 2.1.6 ;_). he's already using whirlycache,

Re: Cocoon Performance Woes, Is it flow? I don't know!

eric: Two more tips: Try to switch to ehcache. I hear some ratings to the slowness of jcs cache (the default cache system in in 2.1.5.1). BTW in 2.1.6 I think the default cache system is ehcache, one more reason to move to 2.1.6 ;_). if posible switch from xinclude to cinclude, AFAIK still today

Re: Cocoon Performance Woes, Is it flow? I don't know!

Antonio Gallardo wrote: Can you post the sizes of the returned pages in the thread? I guess this is an important point too. The pages are roughly similar in size: home page: / 17.54 KB (17964 bytes) search1: /luxury_hotels/europe__france__paris/index.html 29.88 KB (30599 bytes) search2: /luxur

Re: Cocoon Performance Woes, Is it flow? I don't know!

?id=31760 I saw you canged some pools inside tomcat. Did you changed some cocoon pools? Did you adjusted cocoon memory usage inside cocoon.xconf? Best Regards, Antonio Gallardo. On Jue, 17 de Marzo de 2005, 11:30, Eric E. Meyer dijo: > Cocoon Performance Woes, Is it flow? I don't know! &

Re: Cocoon Performance Woes, Is it flow? I don't know!

tween page requests. Looking with Ethereal, I can seen that the client is not using cookies, and that each thread appears to have it's own keep-alive connection. Note that flow is used even in the case when I removed the refine-search form, as the top-level configuration of the search base

Re: Cocoon Performance Woes, Is it flow? I don't know!

Haha :-) calls for "instrumentation" Cheers Giacomo PS: Eric, sorry, this is an insider joke you might not understand but I couldn't resist to do as 6 month ago the Instrumentation code was removed. Yes, but only in 2.2 - it should still work in 2.1.x (but I have not test

Re: Cocoon Performance Woes, Is it flow? I don't know!

Giacomo Pati wrote: > > > Haha :-) calls for "instrumentation" > > Cheers > > Giacomo > > PS: Eric, sorry, this is an insider joke you might not understand but I > couldn't resist to do as 6 month ago the Instrumentation code was removed. > Yes, but only in 2.2 - it should still work in 2.1.

Re: Cocoon Performance Woes, Is it flow? I don't know!

Eric E. Meyer wrote: Also, for curiosity, I re-ran the tests with the embedded form in the search results page removed. That had a positive impact on performance: With refine-search form: users overall home search1 search2 search3 detail total avg ms page

Re: Cocoon Performance Woes, Is it flow? I don't know!

Eric E. Meyer wrote: Bertrand Delacretaz wrote: Le 17 mars 05, à 18:30, Eric E. Meyer a écrit : ...Some pages in the site scale quite well, while one in particular does not scale well at all.. Did you try to run tests on just that page, many same requests, and try removing components from the pa

Re: Cocoon Performance Woes, Is it flow? I don't know!

Bertrand Delacretaz wrote: Le 17 mars 05, à 18:30, Eric E. Meyer a écrit : ...Some pages in the site scale quite well, while one in particular does not scale well at all.. Did you try to run tests on just that page, many same requests, and try removing components from the page generation path, on

Re: Cocoon Performance Woes, Is it flow? I don't know!

Eric E. Meyer wrote: Also, for curiosity, I re-ran the tests with the embedded form in the search results page removed. That had a positive impact on performance: A while ago i had performance problems using the bindings. My post at [1] contains a few things to watch out for when combining CFor

Re: Cocoon Performance Woes, Is it flow? I don't know!

Reinhard Poetz wrote: Eric E. Meyer wrote: Cocoon Performance Woes, Is it flow? I don't know! CForms, Javascript flow, mix of JX template generators, XInclude transformer and custom generator transformers. Core application components implemented in Java. Hibernate persistence. Do yo

Re: Cocoon Performance Woes, Is it flow? I don't know!

Hi Eric: I have no time now to read all the answer you got. Some points: 1. java 1.4.2_06 is buggy -> update to 1.4.2_07 2. Flow is slow is FUD. I recently read a comparision between diferent scripting languages and rhino is the fastest one. The performance is very good. So I don't th

Re: Cocoon Performance Woes, Is it flow? I don't know!

Le 17 mars 05, à 18:30, Eric E. Meyer a écrit : ...Some pages in the site scale quite well, while one in particular does not scale well at all.. Did you try to run tests on just that page, many same requests, and try removing components from the page generation path, one after the other? This sh

Re: Cocoon Performance Woes, Is it flow? I don't know!

Eric E. Meyer wrote: Cocoon Performance Woes, Is it flow? I don't know! CForms, Javascript flow, mix of JX template generators, XInclude transformer and custom generator transformers. Core application components implemented in Java. Hibernate persistence. Do you use jxmacros in your c

Re: Cocoon Performance Woes, Is it flow? I don't know!

Rhyme error: this should be: "Cocoon Performance Woe, Is it flow? I don't know!" :-) -- Colin Paul Adams Preston Lancashire

Re: Cocoon Performance Woes, Is it flow? I don't know!

Also, that seems like a high number of users for such a little amount of memory. You may just be garbage collecting a lot. Eric E. Meyer wrote: Observations Windows XP Pentium 4 1.8Ghz JDK 1.4.2_06 Tomcat 5.0.28 Cocoon 2.1.5.1 512MB physical RAM JVM -server -Xms256M -Xmx256M Load test with num u

Re: Cocoon Performance Woes, Is it flow? I don't know!

JProbe doesn't give you an indication as to what methods most of the time is spent in? That should be extremely helpful. Eric E. Meyer wrote: These are the tools/approaches that I have used: Multi-thread load test with JMeter. Profiling of application code using JProbe (CPU and memory analysis).

Cocoon Performance Woes, Is it flow? I don't know!

Cocoon Performance Woes, Is it flow? I don't know! Hello all, My team developed and deployed a web application for a client which is built on top of Cocoon (www.fivestaralliance.com). I have spent over two weeks now attempting to improve the performance and scalability of the application –

Re: Better definition of the flow context?

Carsten Ziegeler wrote: Vadim Gritsenko wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: I don't think this should break much code, as that object (which BTW I prefer to name "view data" rather than the ambiguous "flow context" -- we have enough contexts in Cocoon

Re: Better definition of the flow context?

Vadim Gritsenko wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: I don't think this should break much code, as that object (which BTW I prefer to name "view data" rather than the ambiguous "flow context" -- we have enough contexts in Cocoon) is supposed to be a JS

Re: Better definition of the flow context?

Carsten Ziegeler wrote: Sylvain Wallez wrote: I don't think this should break much code, as that object (which BTW I prefer to name "view data" rather than the ambiguous "flow context" -- we have enough contexts in Cocoon) is supposed to be a JS object. And a JS object

Re: Better definition of the flow context?

Sylvain Wallez wrote: I don't think this should break much code, as that object (which BTW I prefer to name "view data" rather than the ambiguous "flow context" -- we have enough contexts in Cocoon) is supposed to be a JS object. And a JS object can easily be turned

Re: Better definition of the flow context?

Daniel Fagerstrom wrote: Carsten Ziegeler wrote: Do we have a solid contract for our flow context object? The FlowContextHelper returns an object, so e.g. in the jxtg we have something like: if (contextObject instanceof Map) { map.putAll((Map)contextObject); } else if

Re: Better definition of the flow context?

Carsten Ziegeler wrote: Do we have a solid contract for our flow context object? The FlowContextHelper returns an object, so e.g. in the jxtg we have something like: if (contextObject instanceof Map) { map.putAll((Map)contextObject); } else if ( contextObject != null

Better definition of the flow context?

Do we have a solid contract for our flow context object? The FlowContextHelper returns an object, so e.g. in the jxtg we have something like: if (contextObject instanceof Map) { map.putAll((Map)contextObject); } else if ( contextObject != null

Re: JXTG: from flow vs directly from sitemap

d first in the context of the request. Thus this facility is not set up generically for JXTemplates, only JXTemplates called from a flow. Could you point me the direct code location? Multiple locations (2.1.6 dist): Start with JXTemplateGenerator:setContexts() 2237 FOM_JavaScriptFlowHelper:getJ

Re: JXTG: from flow vs directly from sitemap

ext of the request. Thus this facility is not set up generically for JXTemplates, only JXTemplates called from a flow. Could you point me the direct code location? Multiple locations (2.1.6 dist): Start with JXTemplateGenerator:setContexts() 2237 FOM_JavaScriptFlowHelper:getJavaPa

Re: JXTG: from flow vs directly from sitemap

a' Package object which you are implicitly using when you do the ${java.util.HashMap()} is only set up (and thus available to JXTemplate) if the FOM JavaScript interpreter is called first in the context of the request. Thus this facility is not set up generically for JXTemplates, only JXTemplates ca

Re: JXTG: from flow vs directly from sitemap

ou are implicitly using when you do the ${java.util.HashMap()} is only set up (and thus available to JXTemplate) if the FOM JavaScript interpreter is called first in the context of the request. Thus this facility is not set up generically for JXTemplates, only JXTemplates called from a flow. T

Re: Write binary data to output stream from flow

odule sources of Cocoon might do what you need, if you use them in combination with the flow-attr input module. Not quite - the flow-attr input module is helpful, but the xmodule source seems to inherently assume that the object in the flow attribute can be serialized as XML - here the object

RE: Write binary data to output stream from flow

sources of Cocoon might do what you need, if you use them in combination with the flow-attr input module. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]

RE: Write binary data to output stream from flow

Original Message- > >>From: Upayavira [mailto:[EMAIL PROTECTED] > >>Sent: Friday, February 18, 2005 11:47 AM > >>To: dev@cocoon.apache.org > >>Subject: Re: Write binary data to output stream from flow > >> > >>Bart Molenkamp wrote: &

Re: Write binary data to output stream from flow

t: Re: Write binary data to output stream from flow Bart Molenkamp wrote: -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Friday, February 18, 2005 11:20 AM To: dev@cocoon.apache.org Subject: Re: Write binary data to output stream from flow Bart Molenkamp wrote: Yes, it makes

RE: Write binary data to output stream from flow

expressions... Would that be a good idea? > -Original Message- > From: Upayavira [mailto:[EMAIL PROTECTED] > Sent: Friday, February 18, 2005 11:47 AM > To: dev@cocoon.apache.org > Subject: Re: Write binary data to output stream from flow > > Bart Molenkamp wrote:

Re: Write binary data to output stream from flow

Upayavira wrote: Bart Molenkamp wrote: If the object in the context is a bean, the path ./inputStream will make JXPath invoke getInputStream(), right? And the same for mimeType of course. So this leaves the user to make the decision if he passes an object which has a getInputStream() method, or if

Re: Write binary data to output stream from flow

Bart Molenkamp wrote: -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Friday, February 18, 2005 11:20 AM To: dev@cocoon.apache.org Subject: Re: Write binary data to output stream from flow Bart Molenkamp wrote: Yes, it makes even better sense. Would such a more generic

RE: Write binary data to output stream from flow

> -Original Message- > From: Upayavira [mailto:[EMAIL PROTECTED] > Sent: Friday, February 18, 2005 11:20 AM > To: dev@cocoon.apache.org > Subject: Re: Write binary data to output stream from flow > > Bart Molenkamp wrote: > > Yes, it makes even better sense

Re: Write binary data to output stream from flow

definition or via the approach, or however the ResourceReader currently works. Regards, Upayavira -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Friday, February 18, 2005 11:06 AM To: dev@cocoon.apache.org Subject: Re: Write binary data to output stream from flow Bart

RE: Write binary data to output stream from flow

gt; Subject: Re: Write binary data to output stream from flow > > Bart Molenkamp wrote: > > Ok, sorry, I didn't understand you but now it makes perfect sense. > > Thanks for your advise! > > Well, I had a chance to express myself more clearly, and think it > through a

Re: Write binary data to output stream from flow

o the view, when the view is pretty simple. I would tend to implement this as a custom reader, actually, with code like: /stream /mimeType That way, you're configuring the reader to know where in the flow business objects to get the stream and the mime type.

RE: Write binary data to output stream from flow

o output stream from flow > > Bart Molenkamp wrote: > > > >>-Original Message- > >>From: Upayavira [mailto:[EMAIL PROTECTED] > >>Sent: Thursday, February 17, 2005 5:19 PM > >>To: dev@cocoon.apache.org > >>Subject: Re: Write binar

Re: Write binary data to output stream from flow

Bart Molenkamp wrote: -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Thursday, February 17, 2005 5:19 PM To: dev@cocoon.apache.org Subject: Re: Write binary data to output stream from flow Bart Molenkamp wrote: Hi, Is it possible to write binary data to the HTTP

JXTG: from flow vs directly from sitemap

Daniel and I have found out some strange behaviour concerning JEXL in Jxtg. Users started reporting this also: http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=110867204019252&w=2 The only thing we know is that the problems occur when the pipeline is not invoked from flowscript. http://apache

RE: Write binary data to output stream from flow

> -Original Message- > From: Upayavira [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 17, 2005 5:19 PM > To: dev@cocoon.apache.org > Subject: Re: Write binary data to output stream from flow > > Bart Molenkamp wrote: > > Hi, > > > > Is it po

Re: Write binary data to output stream from flow

Bart Molenkamp wrote: Hi, Is it possible to write binary data to the HTTP response directly from the flow? I have an InputStream available in my flow, and I want to serve data from that stream directly to the HTTP response. E.g. cocoon.sendBinaryData(inputStream, "application/octet-stream&

Write binary data to output stream from flow

Hi, Is it possible to write binary data to the HTTP response directly from the flow? I have an InputStream available in my flow, and I want to serve data from that stream directly to the HTTP response. E.g. cocoon.sendBinaryData(inputStream, "application/octet-stream"); Or something s

Better collections support and JVM extensions for flow

my pleasant suprise, it worked out quite well which opens the door to the many if not all the Groovy improvements: http://groovy.codehaus.org/groovy-jdk.html Anyways, I don't know if Cocoon has already considered "spicing up" flow to cut down on code size and make flow more simple, but

Re: svn commit: r153938 - in cocoon/trunk: gump.xml lib/core/javacApi-0.9.jar lib/core/javacImpl-0.9.jar lib/jars.xml src/java/org/apache/cocoon/components/flow/javascript/fom/CompilingClassLoader.java src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java

t step towards a BlockBuilder) Removed: cocoon/trunk/lib/core/javacApi-0.9.jar cocoon/trunk/lib/core/javacImpl-0.9.jar cocoon/trunk/src/java/org/apache/cocoon/components/flow/javascript/fom/CompilingClassLoader.java AFAIK the CompilingClassLoader hasn't worked for a long time and

Re: svn commit: r151736 - in cocoon/trunk: ./ lib/ lib/optional/ src/blocks/javaflow/ src/blocks/javaflow/WEB-INF/xconf/ src/blocks/javaflow/java/org/apache/cocoon/components/flow/java/ src/blocks/javaflow/samples/ src/blocks/paranoid/java/org/apache/cocoon/servlet/ src/webapp/WEB-INF/ src/webapp/WEB-INF/compile/ src/webapp/WEB-INF/compile/org/ src/webapp/WEB-INF/compile/org/apache/cocoon/components/flow/java/ src/webapp/WEB-INF/compile/org/apache/cocoon/forms/flow/java/ src/webapp/WEB-INF/compile/org/apache/cocoon/samples/flow/java/ src/webapp/WEB-INF/src/

cocoon/trunk/lib/optional/commons-javaflow-0.1-dev.jar (with props) cocoon/trunk/lib/optional/commons-jci-0.1-dev.jar (with props) Snapshot jars should have timestamp in the file name, as we agreed (and for SVN snapshots, imho, revision number). Sorry, I am a lazy bastard ;-) ...will f

DO NOT REPLY [Bug 33544] - [PATCH] Mention flow-attribute prefix in Flow API doc

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33544] New: - [PATCH] Mention flow-attribute prefix in Flow API doc

gzilla/show_bug.cgi?id=33544 Summary: [PATCH] Mention flow-attribute prefix in Flow API doc Product: Cocoon 2 Version: Current SVN 2.1 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Com

Re: svn commit: r151736 - in cocoon/trunk: ./ lib/ lib/optional/ src/blocks/javaflow/ src/blocks/javaflow/WEB-INF/xconf/ src/blocks/javaflow/java/org/apache/cocoon/components/flow/java/ src/blocks/javaflow/samples/ src/blocks/paranoid/java/org/apache/cocoon/servlet/ src/webapp/WEB-INF/ src/webapp/WEB-INF/compile/ src/webapp/WEB-INF/compile/org/ src/webapp/WEB-INF/compile/org/apache/cocoon/components/flow/java/ src/webapp/WEB-INF/compile/org/apache/cocoon/forms/flow/java/ src/webapp/WEB-INF/compile/org/apache/cocoon/samples/flow/java/ src/webapp/WEB-INF/src/

[EMAIL PROTECTED] wrote: cocoon/trunk/lib/optional/commons-javaflow-0.1-dev.jar (with props) cocoon/trunk/lib/optional/commons-jci-0.1-dev.jar (with props) Snapshot jars should have timestamp in the file name, as we agreed (and for SVN snapshots, imho, revision number). Vadim

fyi: python cocoon-flow clone

Just stumbled onto this: http://subway.python-hosting.com/wiki/CherryFlow -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.

Re: Object parameters, Was: sitemap, jx and flow design

a more diverse set of datatypes then strings. This one is absolutely same issue you are discussing here: http://issues.apache.org/bugzilla/show_bug.cgi?id=9916 IMHO, it is worth to discuss the issue of passing object parameters by itself, without mixing flow or jx into it, as a bonus we might

Re: Object parameters, Was: sitemap, jx and flow design

ssing here: > > http://issues.apache.org/bugzilla/show_bug.cgi?id=9916 > > IMHO, it is worth to discuss the issue of passing object parameters by itself, > without mixing flow or jx into it, as a bonus we might get resolution for a > 2.5 > years old feature request. > &g

Re: sitemap, jx and flow design

Vadim Gritsenko wrote: Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: Now for the instructions (jx:forEach etc) we have the question if they should be choosed: 1. Programatically: There is an abstract base class with common template generator functionality. To implement e.g. JXTG this base c

<    1   2   3   4   5   6   7   8   9   10   >