Re: Cocoon PMC report, February 2005

[Brian Behlendorf]

On Fri, 18 Feb 2005, Sylvain Wallez wrote:
I'm really sorry for this late report. For some unknown reason, I thought the 
board meeting was to be held next week.
It is, I was the one who made the erroneous statement it might have been 
this week.  So you're definitely on time, thanks!

Brian

RE: Moving blocks

[Ben Pope]

> -Original Message-
> From: Reinhard Poetz [mailto:[EMAIL PROTECTED] 
> Sent: 18 February 2005 17:41
> To: dev@cocoon.apache.org
> Subject: Re: Moving blocks
> 
> Upayavira wrote:
> > Reinhard Poetz wrote:
> > 
> >> Could some people pls report back whether there have been any 
> >> problems on updates? (Escpecially be careful if you had changes in 
> >> one of the four moved blocks. In this case, sorry for any 
> >> inconveniences!)
> > 
> > 
> > Have you tried checking out the external references via http rather 
> > than https? Just want to be sure that they'll still work for 
> > non-committers using http.
> 
> Yes,
> 
> svn checkout http://svn.apache.org/repos/asf/cocoon/trunk/src/blocks
> 
> worked for me. I guess that people not using https have to 
> accept the certificate once.

That seems to be what just happened.

TortoiseSVM deleted the blocks, and re-added them at the some location, but
I had to accept the certificate.

No major problem.

Ben

RE: Re: CONTRIBUTION: repeater-widget (insert row): InsertRowsActionDefinition

[depub2]

Well, what do you guys think? Does 7 days of silence amount to agreement??
I'll be happy to make any mods you suggest and resubmit source to you for
inclusion...


#define SUBJECT_DRIFT_ON
Also, I have a "2 line" minor tweak to the forms-calendar-styling.xsl that
disables the "calendar icon/popup" when a datetype="date" widget is set to
readonly, disabled, or hidden (in these cases, we don't want an icon or
popup - ESPECIALLY when the widget is supposed to be "hidden").

The change was simple, in
cocoon/samples/blocks/forms/resources/forms-calendar-styling.xsl

I added:

around the calendar HTML anchor.

The modified code segment in that file now reads:



  



All that I added was the surrounding  block. It works great!!

Should I move this to a separate CONTRIBUTION thread or is this simple
enough that you would just get it into the cvs archive??

Thanks again - I hope these contributions are seen more helpful than the
pain they are to include them in the distribution... (And IMHO, how can you
get a better deal than a free ghost-writer?? ;-)

David



-Original Message-
From: depub2 [mailto:[EMAIL PROTECTED]
Sent: Friday, February 11, 2005 2:32 PM
To: CocoonDev
Subject: Re: CONTRIBUTION: repeater-widget (insert row):
InsertRowsActionDefinition


Can we get a few quick yay/nays??

Sylvain is considering incorporation of the changes noted below... Could we
hear a few words of encouragement (or discouragement) from a couple of
people so this item can be closed and completed.

Thanks to all! David


> Sylvain wrote:

depub2 wrote:

>Hello Folks,
>
>I would like to make a small contribution to the cocoon repeater-widget
>(insert row) and would like someone (Sylvain Wallez?) to accept my code; so
>I'll be a "ghostwriter" as it does not make sense for me to maintain this
>small piece of code.
>
>Specifically, I would like to add something like:
>  package org.apache.cocoon.forms.formmodel;
>  public class InsertRowsActionDefinition extends RepeaterActionDefinition
>{}
>
>It will act like DeleteRowsActionDefinition; but instead will insert a
>single row in front of each of the selected rows. This sure seems like a
>natural need for the repeater! Yes?!?
>
>

Sorry, it doesn't seem natural to me, and I never saw such behaviour,
particularily inserting several rows at once and inserting them before
the selected row.

Now I understand that the set of available repeater-actions is currently
limited, and that "add-row" that inserts a new row at the end of the
repeater may not be the most convenient when you want to insert a row at
an arbitrary place in the repeater (although you have the "add-after"
row-action).

So IMO the behaviour of an "add-rows" action should be to add rows
_after_ the selected rows. This kind of interaction usually involves a
single selection, but we could find it acceptable that it is generalized
to inserting a row after all selected rows.

What do people think?

Sylvain


> Hi Sylvain,
> As you mention it, I think "add-rows" would be as-good or better than
"insert-rows".
> Since the change is fairly trivial to the tested "insert-rows" code you
> now have from me, it might even be worthwhile to have both "insert-rows"
and
> "add-rows" and allow the user / GUI designer to select their choice.
> Perhaps the repeater samples code could be modified to only demonstrate
> "add-rows" to "steer" a GUI designer in that more favorable direction.
>
> One nice side-effect of multiple-checked insert-rows/add-rows capability
is
> that multiple-selection enables one to rapidly insert multiple rows
through
> exponentially increasing iterations of inserts. (check 1, check 2, check
4,
> check 8...) Just to clarify, "my code's" behavior is that a _single_ row
is
> inserted above (below is fine too) every selected row. Adding 32 new/blank
> rows is simply a 5x "add-rows" operation. Perhaps it would be helpful to
> "pre-select" the rows that were added so that this multiple exponential
> insert is even easier on the user, so they don't have to check the boxes.
> Woe unto them that later perform "delete-rows" without deselecting first.
>
> As it turns out, multiple-select insertion was easier to implement than
> single-selection, based on copying the delete-rows code and minor tweak.
>
> If you find it difficult to modify the samples code, I could probably
> do it and email it to you.
> Best, David Epperly -depub2


--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Moving blocks

[Reinhard Poetz]

Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
I have not tested yet what happens with local changes after the block 
is "mounted" using svn:external. Any experiences?

I've been using svn:external for including the documentation in the 
simile.mit.edu web site (which is managed in SVN) importing the /docs 
that come from the various projects (so no code) but I have no found a 
problem yet with this approach.
good too hear
The only problem is that 'svn status' might not show you changed done in 
the imported blocks, you have to 'cd' into the block directory and do 
'svn status' there.

[but there might be a switch somewhere in turn that behavior off... that 
havn't bugged me enough to be concerned about it]
The (possible) problem that I'm thinking of is if people haven't updated their 
working copies yes and have some local changes. I don't know what's happening if 
they do "svn update". I guess they have to manually save their changes, to "svn 
update" and copy the changes back.

--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: Moving blocks

[Reinhard Poetz]

Upayavira wrote:
Reinhard Poetz wrote:
This afternoon I've started to move some selected blocks:
- authentication-fw
- session-fw
- cron
- html
Cron and html are blocks don't require other blocks to build. 
Authentication-fw depends on session-fw. This will give me the chance 
to test my build system that will respect those relations. In my sense 
all those blocks are well supported by the community but making a 
decision whether they are supported, core or not was not my goal. We 
can discuss this later in a separate thread.

As those blocks are not under heavy development I don't expect (too 
many) problems. I have not tested yet what happens with local changes 
after the block is "mounted" using svn:external. Any experiences? If 
there are troubles we need some migration strategy (means code freeze).

Could some people pls report back whether there have been any problems 
on updates? (Escpecially be careful if you had changes in one of the 
four moved blocks. In this case, sorry for any inconveniences!)

Have you tried checking out the external references via http rather than 
https? Just want to be sure that they'll still work for non-committers 
using http.
Yes,
svn checkout http://svn.apache.org/repos/asf/cocoon/trunk/src/blocks
worked for me. I guess that people not using https have to accept the 
certificate once.

--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

DO NOT REPLY [Bug 33637] - i18n messages don't work for required fields

[bugzilla]

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_bug.cgi?id=33637


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Samples |blocks




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 33637] New: - i18n messages don't work for required fields

[bugzilla]

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_bug.cgi?id=33637

   Summary: i18n messages don't work for required fields
   Product: Cocoon 2
   Version: Current SVN 2.1
  Platform: All
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Samples
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


I've tried using i18n tags in the XSL for required fields to no avail. The 
other validation messages work when i18n tags used in form definitions but 
localized messages for required fields no joy under any conditions. 

Ideally I'd be submitting a patch with this but haven't nail exactly where the 
problem is. The problem is also in the samples.. You can get localised 
messages working when you define them with i18n tags in the form def, but a 
simple test using Packages.ValidationError("mykey.inmessages",true) fails. 

I've got as far as System.outs in I18nMessage.toSax() but haven't worked out a 
means of debuging a contentHandler as yet.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Moving blocks

[Stefano Mazzocchi]

Reinhard Poetz wrote:
I have not tested yet what happens with local changes 
after the block is "mounted" using svn:external. Any experiences?
I've been using svn:external for including the documentation in the 
simile.mit.edu web site (which is managed in SVN) importing the /docs 
that come from the various projects (so no code) but I have no found a 
problem yet with this approach.

The only problem is that 'svn status' might not show you changed done in 
the imported blocks, you have to 'cd' into the block directory and do 
'svn status' there.

[but there might be a switch somewhere in turn that behavior off... that 
havn't bugged me enough to be concerned about it]

HTH
--
Stefano.

Re: [OT]Re: [RT] How scripting made me hate java

[Stefano Mazzocchi]

Rogier Peters wrote:
But maybe an interesting question would be: how would cocoon be different when
written in another language. Would you need an XML sitemap if you could just
write your sitemap in a dynamic language?
Yes, that is a very interesting question, but it's not something I want 
to spend my time on right now, there are way more important things to 
work on and language wars tend to get religious very very fast.

--
Stefano.

Re: JXTG: from flow vs directly from sitemap

[Leszek Gawron]

Ellis Pritchard wrote:
Leszek Gawron wrote:
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.org/cocoon/templates/jx/1.0";>
  


  
  



  

For what we know test2 does not work. "map" variable is not properly 
initialized.

Could anybody comment?

AFAICS (looking at the code) the 'java' 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 called from a flow.
Could you point me the direct code location?
This is why doing a 'null' flow which just calls your JX view works; the 
java package is set up by the flow; if the 'null' flow also contained 
other importPackage() function calls, you would also be able to use 
those packages in the JXTemplate.

--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: Moving blocks

[Upayavira]

Reinhard Poetz wrote:
This afternoon I've started to move some selected blocks:
- authentication-fw
- session-fw
- cron
- html
Cron and html are blocks don't require other blocks to build. 
Authentication-fw depends on session-fw. This will give me the chance to 
test my build system that will respect those relations. In my sense all 
those blocks are well supported by the community but making a decision 
whether they are supported, core or not was not my goal. We can discuss 
this later in a separate thread.

As those blocks are not under heavy development I don't expect (too 
many) problems. I have not tested yet what happens with local changes 
after the block is "mounted" using svn:external. Any experiences? If 
there are troubles we need some migration strategy (means code freeze).

Could some people pls report back whether there have been any problems 
on updates? (Escpecially be careful if you had changes in one of the 
four moved blocks. In this case, sorry for any inconveniences!)
Have you tried checking out the external references via http rather than 
https? Just want to be sure that they'll still work for non-committers 
using http.

Regards, Upayavira

Moving blocks

[Reinhard Poetz]

This afternoon I've started to move some selected blocks:
- authentication-fw
- session-fw
- cron
- html
Cron and html are blocks don't require other blocks to build. Authentication-fw 
depends on session-fw. This will give me the chance to test my build system that 
will respect those relations. In my sense all those blocks are well supported by 
the community but making a decision whether they are supported, core or not was 
not my goal. We can discuss this later in a separate thread.

As those blocks are not under heavy development I don't expect (too many) 
problems. I have not tested yet what happens with local changes after the block 
is "mounted" using svn:external. Any experiences? If there are troubles we need 
some migration strategy (means code freeze).

Could some people pls report back whether there have been any problems on 
updates? (Escpecially be careful if you had changes in one of the four moved 
blocks. In this case, sorry for any inconveniences!)

--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: JXTG: from flow vs directly from sitemap

[Ellis Pritchard]

Leszek Gawron wrote:
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.org/cocoon/templates/jx/1.0";>
  


  
  



  

For what we know test2 does not work. "map" variable is not properly 
initialized.

Could anybody comment?
AFAICS (looking at the code) the 'java' 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 called from a flow.

This is why doing a 'null' flow which just calls your JX view works; the 
java package is set up by the flow; if the 'null' flow also contained 
other importPackage() function calls, you would also be able to use 
those packages in the JXTemplate.

Ellis.

Re: Problems with ojb block in 2.1.x

[Antonio Gallardo]

On Vie, 18 de Febrero de 2005, 7:22, Carsten Ziegeler dijo:
> When I do a full (clean) build of current 2.1.7-dev from SVN and then
> start Cocoon, I get a class not found exception and Cocoon doesn't
> start. Some JDO classes are missing.
>
> Commenting out the ojb block solves this - can we fix this?

I was working on that before your post. ;-)

I hope I can fix this today.


Best Regards,

Antonio Gallardo.

Re: Problems with ojb block in 2.1.x

[Vadim Gritsenko]

Carsten Ziegeler wrote:
When I do a full (clean) build of current 2.1.7-dev from SVN and then
start Cocoon, I get a class not found exception and Cocoon doesn't
start. Some JDO classes are missing.
Hm, I have not noticed this because of jdo.jar in lib/local/...

Commenting out the ojb block solves this - can we fix this?
I'll add a test/logging in the right places.
Vadim

Problems with ojb block in 2.1.x

[Carsten Ziegeler]

When I do a full (clean) build of current 2.1.7-dev from SVN and then
start Cocoon, I get a class not found exception and Cocoon doesn't
start. Some JDO classes are missing.
Commenting out the ojb block solves this - can we fix this?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

[OT]Re: [RT] How scripting made me hate java

[Rogier Peters]

quoting Stefano Mazzocchi <[EMAIL PROTECTED]>:

> Greg Weinger wrote:
> > This may be way off course, but have you thought about a Cocoon in
> > Squeak?

The thought must have crossed a lot of minds - but I don't actually know of
success-stories of the
"project-X-based-on-project-Y-but-in-a-different-language"

> No and I'm *NOT* rewriting 4 million lines of code (cocoon + all the
> libraries it depends on!) in another language, thanks.

But maybe an interesting question would be: how would cocoon be different when
written in another language. Would you need an XML sitemap if you could just
write your sitemap in a dynamic language?

Not completely relevant link, by way of Bruce Eckel:
http://osteele.com/archives/2003/08/test-versus-type

Re: Write binary data to output stream from flow

[Upayavira]

Bruno Dumon wrote:
On Fri, 2005-02-18 at 11:11 +0100, Bart Molenkamp wrote:
Yes, it makes even better sense. 

Would such a more generic, JXPath oriented stream reader be a valuable
contribution to Cocoon?

I haven't read the complete thread in detail, but the existing module
and/or xmodule 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 has a getInputStream() method.

But a source similar to that, a StreamSource, could serve the same 
purpose in combination with the flow-attr input module. But, for some 
reason, this approach makes me feel a little uneasy.

Regards, Upayavira

RE: Write binary data to output stream from flow

[Bruno Dumon]

On Fri, 2005-02-18 at 11:11 +0100, Bart Molenkamp wrote:
> Yes, it makes even better sense. 
> 
> Would such a more generic, JXPath oriented stream reader be a valuable
> contribution to Cocoon?

I haven't read the complete thread in detail, but the existing module
and/or xmodule 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: [RT] How scripting made me hate java

[Stefano Mazzocchi]

Bart Molenkamp wrote:

-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 16, 2005 3:14 PM
To: dev@cocoon.apache.org
Subject: Re: [RT] How scripting made me hate java
 

Big -1
Not knowing where the code is is bad, having to versions that claim to
be the same things in different parts of the repository is way worse.
Again, maybe completely off-topic, but could you explain why you give a
-1? 
I did.
Yes, when making a copy you see a version of the codebase in two
places in the repository, but it also allows committers to change the
codebase for the Cocoon specific needs, without interfering with the
original codebase. And new versions of the original codebase can be
merged into the copied codebase without losing (if people know what
they're doing) their changes.
yeah, in theory. In practice, this never happens and you get two 
incompatible versions, and it's even worse than forking: because you 
find out they are incompatible only 3 years down the road, when somebody 
comes up and wants to merge and they can't.

I am just curious, because I use vendor branches myself for managing my
changes to the Cocoon codebase (very small changes).
But they pay you to do this, big difference.
--
Stefano.

Re: [RT] How scripting made me hate java

[Stefano Mazzocchi]

Greg Weinger wrote:
This may be way off course, but have you thought about a Cocoon in 
Squeak?
No and I'm *NOT* rewriting 4 million lines of code (cocoon + all the 
libraries it depends on!) in another language, thanks.

--
Stefano.

Re: Fixing i18n required messages

[Mark Lowe]

Just to confirm the sample apps have the same bug.. I guess that got
missed while everyone was rapid application developing at such a fast
pace..

Interestingly there's no static variable I18N_CATALOGUE in Contants,
unless its secretly added during some tourtured build process.. Also
interesting there's no obvious error when this fails, this could
perhaps be something to do with a finally block that claims the field
is validated even in the event of an error here's the comment:

// Consider validation finished even in case of exception
this.valueState = VALUE_VALIDATED;

I cant express how impressed I am. 

Mark

On Thu, 17 Feb 2005 16:17:54 +0100, Mark Lowe <[EMAIL PROTECTED]> wrote:
> I've got all that working (localized error messages) and such like,
> thats all find and dandy. Its just the required field.. The situation
> has been complicated where I'm walking into a project thats already in
> progress and, So this could be down to the xslt for form rendering.
> 
> However I was reading that the required attribute and rendering a
> localised message wasn't working in the sample either. So I thought
> I'd take a look into it, rather than whining about it. Guess ist time
> to run the examples again to see if they do what they say on the box.
> 
> Mark
> 
> On Thu, 17 Feb 2005 15:49:06 +0100 (CET), Daniele Madama
> <[EMAIL PROTECTED]> wrote:
> >
> > > I found that, and yes of course I have the message keys added.. You
> > > should try it, practice is usually better than theory. I've seen this
> > > mentioned elsewhere, if its a bug I'd prefer to submit a patch when i
> > > enter it rather than just joining a que.
> >
> > If you see the form-instance you can found the declaration of
> > validation-message
> >
> > general.field-required
> >
> > so this message must be in the 'forms' catalogue, if you want to have the
> > message in the same file of other message you can simply add another
> > catalogue on the declaration of I18nTransformer that point on the same
> > file
> >
> >   >name="i18n"
> >label="i18n"
> >logger="sitemap.transformer.i18n"
> >src="org.apache.cocoon.transformation.I18nTransformer">
> >  
> > > location="resources/translations"/>
> > > location="resources/translations"/>
> >  
> >  false
> >  
> >
> > in this code both catalogue point to the same file.
> >
> > Is this all or your sitatuion is different?
> >
> > TIA,
> > Best regards
> >
> > >
> > > On Thu, 17 Feb 2005 11:40:37 +0100 (CET), Daniele Madama
> > > <[EMAIL PROTECTED]> wrote:
> > >>
> > >> > Hello
> > >> >
> > >> > Could someone nudge me in the right direction (i.e. where to start
> > >> > looking) if i wanted to get a patch in to fix this annoying i18n
> > >> > required messages problem.
> > >> >
> > >> > Thanks
> > >> >
> > >> > Mark
> > >> >
> > >>
> > >> If you are looking for the i18n of the cforms required message, is
> > >> already
> > >> done in the o.a.c.forms.formmodel.Field class
> > >>
> > >> 
> > >>if (this.value == null && getFieldDefinition().isRequired())
> > >> {
> > >>// Field is required
> > >>this.validationError = new ValidationError(new
> > >> I18nMessage("general.field-required",
> > >> Constants.I18N_CATALOGUE));
> > >>} else {
> > >> 
> > >>
> > >> So the only things is to add the correct message entry in the i18n
> > >> catalog.
> > >>
> > >> I hope this is what you need.
> > >>
> > >> Best regards
> > >>
> > >> --
> > >> Daniele Madama
> > >>
> > >> Pro-netics s.r.l.
> > >> Via Elio Lampridio Cerva 127/c
> > >> Roma
> > >> Tel. 0651530849
> > >> http://www.pro-netics.com
> > >>
> > >
> >
> > --
> > Daniele Madama
> >
> > Pro-netics s.r.l.
> > Via Elio Lampridio Cerva 127/c
> > Roma
> > Tel. 0651530849
> > http://www.pro-netics.com
> >
>

RE: Write binary data to output stream from flow

[Bart Molenkamp]

> 
> Bart Molenkamp wrote:
> > Maybe it is even better to have a source that can lookup mimeType,
> > contentLength, inputStream from the context using JXPath
expressions?
> > Then one could use the ResourceReader to serve the content, and use
the
> > source in other places as well. The only difficult thing would be to
> > configure the Xpath expressions... Would that be a good idea?
> 
> You could configure the source in the cocoon.xconf, specifying the
> JXPath expressions there. So yes, you could do it with a source. But I
> think they're better placed in the sitemap, thus as a reader.

Specifying this in cocoon.xconf is a little bit too static for me.

> 
> Otherwise, you could have a source such as:
> 
> stream:/my/path/to/JXPath/Object(application/zip)

Well, I don't think that the (application/zip) at the end isn't
required, as you specify this path in cocoon.xconf. But still I think
you're right about a reader being the best choice. I'll go for that one.

> 
> But that seems to be abusing the URL metaphor a bit too much for me.
> 
> Regards, Upayavira
> 
> >>-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:
> >>
> -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, JXPath oriented stream reader be a
> >>>
> >>>valuable
> >>>
> >>>
> >contribution to Cocoon?
> 
> To me it would. Anyone else think so, or have some reasons
against?
> 
> In fact, the object you pass to the reader (via the XPath string),
> should not be the input stream, but some object that has a
> getInputStream method. That would make better sense.
> >>>
> >>>
> >>>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 he passes the
> >
> > stream
> >
> >>>directly.
> >>
> >>Guess so, yes. But it must be possible to configure the mime type
> >>manually via the sitemap as well as having it provided by the
> >
> > flowscript.
> >
> >>Regards, Upayavira
> >
> >

Re: Write binary data to output stream from flow

[Upayavira]

Bart Molenkamp wrote:
Maybe it is even better to have a source that can lookup mimeType,
contentLength, inputStream from the context using JXPath expressions?
Then one could use the ResourceReader to serve the content, and use the
source in other places as well. The only difficult thing would be to
configure the Xpath expressions... Would that be a good idea?
You could configure the source in the cocoon.xconf, specifying the 
JXPath expressions there. So yes, you could do it with a source. But I 
think they're better placed in the sitemap, thus as a reader.

Otherwise, you could have a source such as:
stream:/my/path/to/JXPath/Object(application/zip)
But that seems to be abusing the URL metaphor a bit too much for me.
Regards, Upayavira
-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:
-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, JXPath oriented stream reader be a
valuable

contribution to Cocoon?
To me it would. Anyone else think so, or have some reasons against?
In fact, the object you pass to the reader (via the XPath string),
should not be the input stream, but some object that has a
getInputStream method. That would make better sense.

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 he passes the
stream
directly.
Guess so, yes. But it must be possible to configure the mime type
manually via the sitemap as well as having it provided by the
flowscript.
Regards, Upayavira

RE: Write binary data to output stream from flow

[Bart Molenkamp]

Maybe it is even better to have a source that can lookup mimeType,
contentLength, inputStream from the context using JXPath expressions?
Then one could use the ResourceReader to serve the content, and use the
source in other places as well. The only difficult thing would be to
configure the Xpath 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:
> >
> >>-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, JXPath oriented stream reader be a
> >
> > valuable
> >
> >>>contribution to Cocoon?
> >>
> >>To me it would. Anyone else think so, or have some reasons against?
> >>
> >>In fact, the object you pass to the reader (via the XPath string),
> >>should not be the input stream, but some object that has a
> >>getInputStream method. That would make better sense.
> >
> >
> > 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 he passes the
stream
> > directly.
> 
> Guess so, yes. But it must be possible to configure the mime type
> manually via the sitemap as well as having it provided by the
flowscript.
> 
> Regards, Upayavira

Re: Write binary data to output stream from flow

[Reinhard Poetz]

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 he passes the stream
directly.
supporting both is a good idea IMO

Guess so, yes. But it must be possible to configure the mime type 
manually via the sitemap as well as having it provided by the flowscript.
think so too
--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: Write binary data to output stream from flow

[Upayavira]

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, JXPath oriented stream reader be a
valuable
contribution to Cocoon?
To me it would. Anyone else think so, or have some reasons against?
In fact, the object you pass to the reader (via the XPath string),
should not be the input stream, but some object that has a
getInputStream method. That would make better sense. 

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 he passes the stream
directly.
Guess so, yes. But it must be possible to configure the mime type 
manually via the sitemap as well as having it provided by the flowscript.

Regards, Upayavira

RE: Write binary data to output stream from flow

[Bart Molenkamp]

> -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, JXPath oriented stream reader be a
valuable
> > contribution to Cocoon?
> 
> To me it would. Anyone else think so, or have some reasons against?
> 
> In fact, the object you pass to the reader (via the XPath string),
> should not be the input stream, but some object that has a
> getInputStream method. That would make better sense. 

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 he passes the stream
directly.

> And the reader
> could check to see if the object has a getMimeType() method, and if
so,
> get the mime type from that. It should also be possible to configure
the
> mime type in the component definition or via the  mime-type="xxx"> approach, or however the ResourceReader currently
works.
> 
> Regards, Upayavira

Bart.

Re: Write binary data to output stream from flow

[Upayavira]

Bart Molenkamp wrote:
Yes, it makes even better sense. 

Would such a more generic, JXPath oriented stream reader be a valuable
contribution to Cocoon?
To me it would. Anyone else think so, or have some reasons against?
In fact, the object you pass to the reader (via the XPath string), 
should not be the input stream, but some object that has a 
getInputStream method. That would make better sense. And the reader 
could check to see if the object has a getMimeType() method, and if so, 
get the mime type from that. It should also be possible to configure the 
mime type in the component 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 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 bit more.
Basically, what you're doing is implementing another way to connect
the
controller to 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. As the context
object from flow comes back as just an Object (presumably could be
some
kind of javascript object as well), you would do well to use JXPath to
get at the values, hence specifying the names of these values as XPath
expressions.
You end up with something more generic component that way that isn't
specifically targetted at your problem.
Make sense?
Regards, Upayavira

RE: Write binary data to output stream from flow

[Bart Molenkamp]

Yes, it makes even better sense. 

Would such a more generic, JXPath oriented stream reader be a valuable
contribution to Cocoon?

Bart.

> -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 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 bit more.
> 
> Basically, what you're doing is implementing another way to connect
the
> controller to 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. As the context
> object from flow comes back as just an Object (presumably could be
some
> kind of javascript object as well), you would do well to use JXPath to
> get at the values, hence specifying the names of these values as XPath
> expressions.
> 
> You end up with something more generic component that way that isn't
> specifically targetted at your problem.
> 
> Make sense?
> 
> Regards, Upayavira
> 
> 
> >>-Original Message-
> >>From: Upayavira [mailto:[EMAIL PROTECTED]
> >>Sent: Friday, February 18, 2005 10:37 AM
> >>To: dev@cocoon.apache.org
> >>Subject: 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 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 similar.
> >
> >I solved it now by creating a SourceFactory and Source
> >>>
> >>>implementation,
> >>>
> >>>
> >so that I can use a plain reader, but this feels a bit like
> >>>
> >>>overkill.
> >>>
> >>>
> >The SourceFactory has to lookup the data from the database (that
is
> >where the data is for the input stream), and the URL contains the
> >primary key to get the data from the database.
> 
> To my knowledge there isn't a way to do this directly. But you
could
> place the inputstream into a request attribute or some such, and
> >
> > pick
> >
> that up from your source, rather than reading the database again.
> 
> Am I understanding your question right?
> 
> Regards, Upayavira
> >>>
> >>>Hi Upayavira,
> >>>
> >>>I don't know if I understood your answer. Maybe I'm not clear
enough
> >>>about my question, so I'll try again.
> >>>
> >>>In my flowscript, I get a java.io.InputStream instance, and the
> >
> > content
> >
> >>>that I read from it can be sent to the user directly. The user
> >
> > thinks
> >
> >>>that it is downloading a file (which he is) but the source comes
> >
> > from a
> >
> >>>database (but the database is transparent due to OJB). In my case,
I
> >>>have a review object which can hold 0 or more downloaded files
> >
> > (files
> >
> >>>are evidence that support the result of the review):
> >>>
> >>>...
> >>>review = ...; // get review from database trough OJB
> >>>cocoon.sendPageAndWait("list-evidence.xml",
> >>>  {evidence: review.getEvidence()});
> >>>
> >>>...
> >>>evidenceId = cocoon.request.get("evidenceId");
> >>>evidence = review.getEvidenceById(evidenceId);
> >>>evidenceDataStream = evidence.getInputStream();
> >>>mimeType = evidence.getMimeType();
> >>>
> >>>// now I want to serve the input stream to the user
> >>>// e.g. something like
> >>>cocoon.sendBinaryData(evidenceDataStream, mimeType);
> >>>
> >>>How can I now read this input stream, and pass it's data to the
> >
> > output
> >
> >>>stream of a pipeline, in a simple way. Currently, I have an
evidence
> >>>source that I can lookup. The URL contains the ID of the review,
and
> >
> > the
> >
> >>>ID of the evidence. Something like
> >
> > evidence://reviewid/evidenceid.txt
> >
> >>That is exactly what I took from what you were saying. And, as it
> >>currently stands, there is no way to send data other than via a
> >>pipeline. So, what I would say is:
> >>
> >>cocoon.sendPage("my-binary-url", {"stream": evidenceDataStream,
> >>"mimeType": mimeType});
> >>
> >>
> >>   
> >>
> >>
> >>Then, in your source, you can use o.a.c.components.flow.FlowHelper
to
> >>get the stream and mimetype business objects, and have 

Re: Write binary data to output stream from flow

[Upayavira]

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 bit more.

Basically, what you're doing is implementing another way to connect the 
controller to 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. As the context 
object from flow comes back as just an Object (presumably could be some 
kind of javascript object as well), you would do well to use JXPath to 
get at the values, hence specifying the names of these values as XPath 
expressions.

You end up with something more generic component that way that isn't 
specifically targetted at your problem.

Make sense?
Regards, Upayavira

-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Friday, February 18, 2005 10:37 AM
To: dev@cocoon.apache.org
Subject: 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 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 similar.
I solved it now by creating a SourceFactory and Source
implementation,

so that I can use a plain reader, but this feels a bit like
overkill.

The SourceFactory has to lookup the data from the database (that is
where the data is for the input stream), and the URL contains the
primary key to get the data from the database.
To my knowledge there isn't a way to do this directly. But you could
place the inputstream into a request attribute or some such, and
pick
that up from your source, rather than reading the database again.
Am I understanding your question right?
Regards, Upayavira
Hi Upayavira,
I don't know if I understood your answer. Maybe I'm not clear enough
about my question, so I'll try again.
In my flowscript, I get a java.io.InputStream instance, and the
content
that I read from it can be sent to the user directly. The user
thinks
that it is downloading a file (which he is) but the source comes
from a
database (but the database is transparent due to OJB). In my case, I
have a review object which can hold 0 or more downloaded files
(files
are evidence that support the result of the review):
...
review = ...; // get review from database trough OJB
cocoon.sendPageAndWait("list-evidence.xml",
 {evidence: review.getEvidence()});
...
evidenceId = cocoon.request.get("evidenceId");
evidence = review.getEvidenceById(evidenceId);
evidenceDataStream = evidence.getInputStream();
mimeType = evidence.getMimeType();
// now I want to serve the input stream to the user
// e.g. something like
cocoon.sendBinaryData(evidenceDataStream, mimeType);
How can I now read this input stream, and pass it's data to the
output
stream of a pipeline, in a simple way. Currently, I have an evidence
source that I can lookup. The URL contains the ID of the review, and
the
ID of the evidence. Something like
evidence://reviewid/evidenceid.txt
That is exactly what I took from what you were saying. And, as it
currently stands, there is no way to send data other than via a
pipeline. So, what I would say is:
cocoon.sendPage("my-binary-url", {"stream": evidenceDataStream,
"mimeType": mimeType});

  

Then, in your source, you can use o.a.c.components.flow.FlowHelper to
get the stream and mimetype business objects, and have your source use
them. I'm not up on this enough to give you exact details, but if I
were
to try to achieve this, this is probably how I would go about it.
Am I making sense now?
Regards, Upayavira

RE: Write binary data to output stream from flow

[Bart Molenkamp]

Ok, sorry, I didn't understand you but now it makes perfect sense.
Thanks for your advise!

Bart.

> -Original Message-
> From: Upayavira [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 18, 2005 10:37 AM
> To: dev@cocoon.apache.org
> Subject: 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 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 similar.
> >>>
> >>>I solved it now by creating a SourceFactory and Source
> >
> > implementation,
> >
> >>>so that I can use a plain reader, but this feels a bit like
> >
> > overkill.
> >
> >>>The SourceFactory has to lookup the data from the database (that is
> >>>where the data is for the input stream), and the URL contains the
> >>>primary key to get the data from the database.
> >>
> >>To my knowledge there isn't a way to do this directly. But you could
> >>place the inputstream into a request attribute or some such, and
pick
> >>that up from your source, rather than reading the database again.
> >>
> >>Am I understanding your question right?
> >>
> >>Regards, Upayavira
> >
> > Hi Upayavira,
> >
> > I don't know if I understood your answer. Maybe I'm not clear enough
> > about my question, so I'll try again.
> >
> > In my flowscript, I get a java.io.InputStream instance, and the
content
> > that I read from it can be sent to the user directly. The user
thinks
> > that it is downloading a file (which he is) but the source comes
from a
> > database (but the database is transparent due to OJB). In my case, I
> > have a review object which can hold 0 or more downloaded files
(files
> > are evidence that support the result of the review):
> >
> > ...
> > review = ...; // get review from database trough OJB
> > cocoon.sendPageAndWait("list-evidence.xml",
> >   {evidence: review.getEvidence()});
> >
> > ...
> > evidenceId = cocoon.request.get("evidenceId");
> > evidence = review.getEvidenceById(evidenceId);
> > evidenceDataStream = evidence.getInputStream();
> > mimeType = evidence.getMimeType();
> >
> > // now I want to serve the input stream to the user
> > // e.g. something like
> > cocoon.sendBinaryData(evidenceDataStream, mimeType);
> >
> > How can I now read this input stream, and pass it's data to the
output
> > stream of a pipeline, in a simple way. Currently, I have an evidence
> > source that I can lookup. The URL contains the ID of the review, and
the
> > ID of the evidence. Something like
evidence://reviewid/evidenceid.txt
> 
> That is exactly what I took from what you were saying. And, as it
> currently stands, there is no way to send data other than via a
> pipeline. So, what I would say is:
> 
> cocoon.sendPage("my-binary-url", {"stream": evidenceDataStream,
> "mimeType": mimeType});
> 
> 
>
> 
> 
> Then, in your source, you can use o.a.c.components.flow.FlowHelper to
> get the stream and mimetype business objects, and have your source use
> them. I'm not up on this enough to give you exact details, but if I
were
> to try to achieve this, this is probably how I would go about it.
> 
> Am I making sense now?
> 
> Regards, Upayavira

Re: Dependencies

[Mark Lowe]

Its would depend with which sdk version the jars were compliled. Could
be what I was looking for, thanks.


On Tue, 15 Feb 2005 13:21:48 +0100, Giacomo Pati <[EMAIL PROTECTED]> wrote:
> 
> 
> Mark Lowe wrote:
> 
> > Ant or maven the first step would be to have the dependencies for a
> > release builds available on a maven style repository. Then the src of
> 
> Are you looking for something like on
> http://www.apache.org/dist/java-repository/cocoon/jars/
> 
> Giacomo
> 
> --
> Otego AG  Tel:   +41 (0)1  240 00 55
> Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04
> Apache Software Foundation Member Mailto:[EMAIL PROTECTED]
> Hohlstrasse 216   Mailto:[EMAIL PROTECTED]
> CH-8004 Zuerich   http://www.otego.com
> 
> 
>

Re: Write binary data to output stream from flow

[Upayavira]

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 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 similar.
I solved it now by creating a SourceFactory and Source
implementation,
so that I can use a plain reader, but this feels a bit like
overkill.
The SourceFactory has to lookup the data from the database (that is
where the data is for the input stream), and the URL contains the
primary key to get the data from the database.
To my knowledge there isn't a way to do this directly. But you could
place the inputstream into a request attribute or some such, and pick
that up from your source, rather than reading the database again.
Am I understanding your question right?
Regards, Upayavira
 
Hi Upayavira,

I don't know if I understood your answer. Maybe I'm not clear enough
about my question, so I'll try again.
In my flowscript, I get a java.io.InputStream instance, and the content
that I read from it can be sent to the user directly. The user thinks
that it is downloading a file (which he is) but the source comes from a
database (but the database is transparent due to OJB). In my case, I
have a review object which can hold 0 or more downloaded files (files
are evidence that support the result of the review):
...
review = ...; // get review from database trough OJB
cocoon.sendPageAndWait("list-evidence.xml", 
  {evidence: review.getEvidence()});

...
evidenceId = cocoon.request.get("evidenceId");
evidence = review.getEvidenceById(evidenceId);
evidenceDataStream = evidence.getInputStream();
mimeType = evidence.getMimeType();
// now I want to serve the input stream to the user
// e.g. something like
cocoon.sendBinaryData(evidenceDataStream, mimeType);
How can I now read this input stream, and pass it's data to the output
stream of a pipeline, in a simple way. Currently, I have an evidence
source that I can lookup. The URL contains the ID of the review, and the
ID of the evidence. Something like evidence://reviewid/evidenceid.txt
That is exactly what I took from what you were saying. And, as it 
currently stands, there is no way to send data other than via a 
pipeline. So, what I would say is:

cocoon.sendPage("my-binary-url", {"stream": evidenceDataStream, 
"mimeType": mimeType});


  

Then, in your source, you can use o.a.c.components.flow.FlowHelper to 
get the stream and mimetype business objects, and have your source use 
them. I'm not up on this enough to give you exact details, but if I were 
to try to achieve this, this is probably how I would go about it.

Am I making sense now?
Regards, Upayavira

Cocoon PMC report, February 2005

[Sylvain Wallez]

I'm really sorry for this late report. For some unknown reason, I 
thought the board meeting was to be held next week.

So here's the February 2005 report for the Cocoon project.

Community:
- Cocoon 2.1.6 has been released in November. This is a maintainance 
release. Cocoon 2.2 development is going on, and we reduced its original 
scope to allow for an earlier release as it already includes a number of 
much wanted improvements.

- The Java continuation engine and Java compiler interface that had 
being written in Cocoon have been moved to the Jakarta commons sandbox 
(JavaFlow and JCI) because we felt they could be used in a number of 
other contexts and may attract other developpers.

- there's an ongoing effort to refactor our documentation and its 
writing process, at the poor structuration of our docs is a major 
problem for newcomers.

- a new french-speaking user list has been created as an answer to the 
fact that many Cocoon-related questions where asked on other 
french-speaking lists and forums.

Legal:
The legal issues related to the Mozilla Rhino fork supporting 
continuations are solved, as we now use the latest official version 
which has continuation support.


Sylvain
PS: cc'ing pmc@ for archival and dev@ to keep the community informed
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

JXTG: from flow vs directly from sitemap

[Leszek Gawron]

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.org/cocoon/templates/jx/1.0";>
  


  
  



  

For what we know test2 does not work. "map" variable is not properly 
initialized.

Could anybody comment?
--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

RE: Write binary data to output stream from flow

[Bart Molenkamp]

> -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 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 similar.
> >
> > I solved it now by creating a SourceFactory and Source
implementation,
> > so that I can use a plain reader, but this feels a bit like
overkill.
> > The SourceFactory has to lookup the data from the database (that is
> > where the data is for the input stream), and the URL contains the
> > primary key to get the data from the database.
> 
> To my knowledge there isn't a way to do this directly. But you could
> place the inputstream into a request attribute or some such, and pick
> that up from your source, rather than reading the database again.
> 
> Am I understanding your question right?
> 
> Regards, Upayavira

Hi Upayavira,

I don't know if I understood your answer. Maybe I'm not clear enough
about my question, so I'll try again.

In my flowscript, I get a java.io.InputStream instance, and the content
that I read from it can be sent to the user directly. The user thinks
that it is downloading a file (which he is) but the source comes from a
database (but the database is transparent due to OJB). In my case, I
have a review object which can hold 0 or more downloaded files (files
are evidence that support the result of the review):

...
review = ...; // get review from database trough OJB
cocoon.sendPageAndWait("list-evidence.xml", 
  {evidence: review.getEvidence()});

...
evidenceId = cocoon.request.get("evidenceId");
evidence = review.getEvidenceById(evidenceId);
evidenceDataStream = evidence.getInputStream();
mimeType = evidence.getMimeType();

// now I want to serve the input stream to the user
// e.g. something like
cocoon.sendBinaryData(evidenceDataStream, mimeType);

How can I now read this input stream, and pass it's data to the output
stream of a pipeline, in a simple way. Currently, I have an evidence
source that I can lookup. The URL contains the ID of the review, and the
ID of the evidence. Something like evidence://reviewid/evidenceid.txt

Hope this clarifies my question a little bit more.