date:20031105

 -Original Message-
 From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] 
 Sent: woensdag 5 november 2003 0:12
 To: [EMAIL PROTECTED]

 On Tuesday, Nov 4, 2003, at 14:21 Europe/Rome, Unico Hommes wrote:

  Working on davmap I noticed that the way I was setting the 
 status code 
  in the Serializer wasn't working. This is what I do:

  map:match pattern=status/*
map:generate src=status.xml /
map:serialize type=xml status-code={1} / /map:match

  But it seems that the status-code attribute is not being 
 resolved. I 
  propose we change this.

 -1, don't know but I don't like this. should be in the fom as 
 you propose below.

Yes I guess the use case is not a valid argument for making the
attribute variable resolved.

  Then I thought I may be able to set it on fom response 
 object in the 
  flow. But this too seems not to be possible. However, changing this 
  seems to be a little more straightforward since setStatus is not a 
  method on the environment Response interface but on the 
 HttpResponse 
  implementation instead. I propose we add this method to the fom and 
  make it a nop in case we are dealing with a different Response 
  implementation than HttpResponse.

 +1

setStatus' friends the sendError brothers are also be eligible for FOM
membership. But this change has a dependency on the discussion about
bodyless responses since if you'd do a sendError from a flow script and
then send a page afterwards this would result in errors.

  Thoughts?

  -- Unico

 --
 Stefano.

RE: Fooling around with cocoon davmap

 -Original Message-
 From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] 
 Sent: maandag 3 november 2003 13:16
 To: [EMAIL PROTECTED]

 Sylvain Wallez wrote:

  Vadim Gritsenko wrote:

  Sylvain Wallez wrote:

  snip/

  Uh (again)? I'm wondering if there's not a misunderstanding here: 
  this FIXME is about knowing if a flowscript is allowed to 
 terminate 
  without stating what page it to be displayed, i.e. check 
 if one of 
  sendPage(), sendPageAndWait() or redirectTo() was called.

  I think that flow should cover as many features of the actions as 
  possible, and for this, it should be allowed not to redirect (as 
  actions are allowed to do):

  map:call method=doSomething/
  map:generate/
  map:transform/
  map:serialize/

  Mmmh... in that case, we need a flowscript function to 
 return a Map of 
  sitemap variables. Shouldn't it be better to have a 
  flowscript-action that would call a function (and not a
  continuation) and would share global variables with 
 flowscript while 
  not being allowed to call sendPageAndWait()?

 Hmm...

 map:call method=login
   map:generate src=protected.xml/
   map:transform/
   map:serialize/
 /map:call

 login () {
   while (!loggedin) {
 sendPageAndWait(login);
 loggedin = ...
   }
   return ('username': username, 'profile': profile);
 }

 You mean something like this? No objections so far. :)
 What flowscript method returns currently?

This looks pretty cool. But let's avoid the action semantic that says
returning null will continue processing outside the call function node
but instead have returning null signal the end of the response. This
will solve the body-less response issue elegantly as well:

function options() {
  cocoon.response.setHeader(DAV,1);
  cocoon.response.setHeader(Allow,OPTIONS,GET,PUT,DELETE);
  cocoon.response.setStatus(204);
  return null;
}

-- Unico

 Vadim

[Vote] empty HTTP responses [was Re: Cannot easily set http status]

On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote:

setStatus' friends the sendError brothers are also be eligible for FOM
membership. But this change has a dependency on the discussion about
bodyless responses since if you'd do a sendError from a flow script and
then send a page afterwards this would result in errors.
I dislikde sendError because, in fact, HTTP does not have the concept 
of errors, but only status codes and empty-payload responses.

In the future, it's entirely possible to have a 309 or equivalent that 
is not an error, but has a empty-payload response. I would dislike to 
call sendError() to send something that is not an error, feels hacky.

I think the optimal solution is:

 1) add response.setStatus() in FOM
 2) allow the flowscript to terminate without calling sendPage* [thus 
resulting in an empty payload]

Vote?

--
Stefano.

DO NOT REPLY [Bug 24388] - [PATCH] Enhanced Sendmail action: Generate message body from a URI

2003-11-05 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24388.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24388

[PATCH] Enhanced Sendmail action: Generate message body from a URI

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Enhanced Sendmail action|[PATCH] Enhanced Sendmail
   ||action: Generate message
   ||body from a URI

RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]

 -Original Message-
 From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] 
 Sent: woensdag 5 november 2003 12:42
 To: [EMAIL PROTECTED]

 On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote:

  setStatus' friends the sendError brothers are also be 
 eligible for FOM 
  membership. But this change has a dependency on the 
 discussion about 
  bodyless responses since if you'd do a sendError from a flow script 
  and then send a page afterwards this would result in errors.

 I dislikde sendError because, in fact, HTTP does not have 
 the concept of errors, but only status codes and 
 empty-payload responses.

The only thing is that sendError method allows to set a message as well,
whereas the setStatus equivalent for that has been deprecated as of
servlet spec version 2.1 . According to the servlet spec there is
another difference between sendError and setStatus. From the
HttpResponse.sendError() api doc entry: After using this method, the
response should be considered to be committed and should not be written
to. For setStatus this is not specified.

Is there no way to set a response message and not commit the response at
the same time? How can we fake this?

 In the future, it's entirely possible to have a 309 or 
 equivalent that is not an error, but has a empty-payload 
 response. I would dislike to call sendError() to send 
 something that is not an error, feels hacky.

 I think the optimal solution is:

   1) add response.setStatus() in FOM
   2) allow the flowscript to terminate without calling 
 sendPage* [thus resulting in an empty payload]

 Vote?

+1

 --
 Stefano.

RE: Woody: managing persistence sessions


From: Jeremy Quinn

 On Tuesday, November 4, 2003, at 01:43 PM, Reinhard Poetz wrote:
 
 catch (break) {
  //   a continuation has been started
 }
 catch (continue) {
  //   a continuation has been resumed
 }
  }
 
  IIRC catch(break) is must be used as top-level statement
 
 I think this is why they did not work before
 
  (... but this is only a guess - never tried catch(continue) but
  catch(break)
  works for me.)
 
 They both work for me too, so does :
 
 catch (return) {
   // the page has finished rendering
 }
 
 So I have very fine-grained control over the session management :)
 
 What I am not sure about now, is whether the values of widgets on the 
 Form are bound to the Bean via object references, or if they are 
 independent copies.

 If they are copies, and the Bean does not get touched during the 
 SendPageAndWait/Validate cycle then all one should need to do 
 to manage 
 the HibernateSession is this:
 
   . . .
// get the User
form.load (user);
session.close();
form.showForm (formURI);
session = factory.createSession ();
form.save (user);
// save the User
   . . .
 
 If I need to make a 'browser' of 'lazy-initialised' 
 relationships then 
 I would be using JXTemplate rather than Woody, with a dynamic model, 
 and I still have enough control to manage the Session with these 
 call-back handlers. Excellent!
 
 Thanks for your help.


Cocoon Forms Widgets (aka Woody Widgets) have their own values. If you
do form.load(myBean) the values are read out from the bean (-- copies
- no references). If you are finished with data collecting you can write
them back using form.save(myBean)

Cheers,
Reinhard

Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]

2003-11-05 Thread Gianugo Rabellino

Stefano Mazzocchi wrote:

setStatus' friends the sendError brothers are also be eligible for FOM
membership. But this change has a dependency on the discussion about
bodyless responses since if you'd do a sendError from a flow script and
then send a page afterwards this would result in errors.


I dislikde sendError because, in fact, HTTP does not have the concept 
of errors, but only status codes and empty-payload responses.

In the future, it's entirely possible to have a 309 or equivalent that 
is not an error, but has a empty-payload response. I would dislike to 
call sendError() to send something that is not an error, feels hacky.

I think the optimal solution is:

 1) add response.setStatus() in FOM
 2) allow the flowscript to terminate without calling sendPage* [thus 
resulting in an empty payload]
Sorry to jump in late, I'm probably lagging behind a few posts, but was 
the possibility of having *pipelines* send empty payload considered 
instead? This way flow will always have to sendPage(), but the result 
would be empty content anyway. With the added bonus of having the 
pipeline flexibility to, say, set headers.

WDYT?

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)

Re: Woody: managing persistence sessions

On Wednesday, November 5, 2003, at 12:02 PM, Reinhard Poetz wrote:

From: Jeremy Quinn

On Tuesday, November 4, 2003, at 01:43 PM, Reinhard Poetz wrote:

   catch (break) {
 //   a continuation has been started
   }
   catch (continue) {
 //   a continuation has been resumed
   }
}
IIRC catch(break) is must be used as top-level statement
I think this is why they did not work before

(... but this is only a guess - never tried catch(continue) but
catch(break)
works for me.)
They both work for me too, so does :

catch (return) {
// the page has finished rendering
}
So I have very fine-grained control over the session management :)

What I am not sure about now, is whether the values of widgets on the
Form are bound to the Bean via object references, or if they are
independent copies.
If they are copies, and the Bean does not get touched during the
SendPageAndWait/Validate cycle then all one should need to do
to manage
the HibernateSession is this:
  . . .
   // get the User
   form.load (user);
   session.close();
   form.showForm (formURI);
   session = factory.createSession ();
   form.save (user);
   // save the User
  . . .
If I need to make a 'browser' of 'lazy-initialised'
relationships then
I would be using JXTemplate rather than Woody, with a dynamic model,
and I still have enough control to manage the Session with these
call-back handlers. Excellent!
Thanks for your help.


Cocoon Forms Widgets (aka Woody Widgets) have their own values. If you
do form.load(myBean) the values are read out from the bean (-- 
copies
- no references). If you are finished with data collecting you can 
write
them back using form.save(myBean)
Thanks for the clarification.

I am really impressed with the Cocoon Forms framework!!
And the continuation-lifecycle 'catch' events work well too!!
There is one more event that some people could conceivably want  
but I do not know if it is possible  The Continuation has 
completed.

Many thanks guys!

regards Jeremy

RE: Woody: managing persistence sessions

 I am really impressed with the Cocoon Forms framework!!
 And the continuation-lifecycle 'catch' events work well too!! 
 There is one more event that some people could conceivably want  
 but I do not know if it is possible  The Continuation has 
 completed.
 
 Many thanks guys!

Sorry, but I haven't got what you mean with The Continuation has
completed. 
When is this event reached? Can you give a example (maybe using some
code)?

Cheers,
Reinhard

RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]

 -Original Message-
 From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] 
 Sent: woensdag 5 november 2003 14:02
 To: [EMAIL PROTECTED]

 Stefano Mazzocchi wrote:

  setStatus' friends the sendError brothers are also be eligible for 
  FOM membership. But this change has a dependency on the discussion 
  about bodyless responses since if you'd do a sendError from a flow 
  script and then send a page afterwards this would result in errors.

  I dislikde sendError because, in fact, HTTP does not have the 
  concept of errors, but only status codes and empty-payload 
 responses.

  In the future, it's entirely possible to have a 309 or 
 equivalent that 
  is not an error, but has a empty-payload response. I would 
 dislike to 
  call sendError() to send something that is not an error, 
 feels hacky.

  I think the optimal solution is:

   1) add response.setStatus() in FOM
   2) allow the flowscript to terminate without calling 
 sendPage* [thus 
  resulting in an empty payload]

 Sorry to jump in late, I'm probably lagging behind a few 
 posts, but was the possibility of having *pipelines* send 
 empty payload considered instead? This way flow will always 
 have to sendPage(), but the result would be empty content 
 anyway. With the added bonus of having the pipeline 
 flexibility to, say, set headers.

But the function of a pipeline is specifically towards the production of
an xml response body. To have to set up all the components, execute the
pipeline and then fooling the pipeline to send its data to a null output
or refrain from pipeline execution altogether? In some scenarios that
may be necessary, for instance in the case of the http HEAD function.
The point is, you shouldn't have to, because there are a lot of
situations where its just unneccesary overhead. (for example all the
dummy responses in the davmap sitemap)

Unico

 WDYT?

 --
 Gianugo Rabellino
 Pro-netics s.r.l. -  http://www.pro-netics.com Orixo, the XML 
 business alliance - http://www.orixo.com
  (Now blogging at: http://blogs.cocoondev.org/gianugo/)

RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]

 -Original Message-
 From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] 
 Sent: woensdag 5 november 2003 13:55
 To: [EMAIL PROTECTED]

 Le Mercredi, 5 nov 2003, à 13:11 Europe/Zurich, Reinhard 
 Poetz a écrit :
  ...I'm +1 with the idea to send pages without payload but -0 with 
  flowscripts which terminate without calling sendPage*. I 
 would prefer 
  an explicit way

 Same here: flowscripts should not hide the fact that a 
 response is indeed sent.

I suggested on the other thread that we could use return null as a signal for that.

function put() {
  doput();
  setStatus(201);
  return null;
}

Null would mean a pipeline is not required to be executed.

I've checked with Rhino. Null can indeed be used to discriminate between the situation 
where you return nothing at all as in that case an Undefined object is returned to the 
interpreter.

-- Unico

 -Bertrand

Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]

2003-11-05 Thread Gianugo Rabellino

Unico Hommes wrote:

-Original Message-
From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] 
Sent: woensdag 5 november 2003 14:02
To: [EMAIL PROTECTED]

Stefano Mazzocchi wrote:

setStatus' friends the sendError brothers are also be eligible for 
FOM membership. But this change has a dependency on the discussion 
about bodyless responses since if you'd do a sendError from a flow 
script and then send a page afterwards this would result in errors.

I dislikde sendError because, in fact, HTTP does not have the 
concept of errors, but only status codes and empty-payload 
responses.

In the future, it's entirely possible to have a 309 or 
equivalent that 

is not an error, but has a empty-payload response. I would 
dislike to 

call sendError() to send something that is not an error, 
feels hacky.

I think the optimal solution is:

1) add response.setStatus() in FOM
2) allow the flowscript to terminate without calling 
sendPage* [thus 

resulting in an empty payload]
Sorry to jump in late, I'm probably lagging behind a few 
posts, but was the possibility of having *pipelines* send 
empty payload considered instead? This way flow will always 
have to sendPage(), but the result would be empty content 
anyway. With the added bonus of having the pipeline 
flexibility to, say, set headers.

But the function of a pipeline is specifically towards the production of
an xml response body. To have to set up all the components, execute the
pipeline and then fooling the pipeline to send its data to a null output
or refrain from pipeline execution altogether? In some scenarios that
may be necessary, for instance in the case of the http HEAD function.
The point is, you shouldn't have to, because there are a lot of
situations where its just unneccesary overhead. (for example all the
dummy responses in the davmap sitemap)
I sure can see some use of this. In a few cases (think PUT) you might 
have XML input flowing through the pipeline (say you might want to 
transform it) yet you have to send an empty response: in this scenario 
using a pipeline looks like the best option to me. Also, I feel that the 
sitemap is core and flow, while being core, is somehow piggybacked on 
the sitemap. I tend to think, then, that deciding whether to send output 
or not should belong more to the sitemap than to the flow.

Ciao,

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)

DO NOT REPLY [Bug 24433] New: - JXTemplate generator does not handle format-number(number, '$#,##0.00')

2003-11-05 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24433.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24433

JXTemplate generator does not handle format-number(number, '$#,##0.00')

   Summary: JXTemplate generator does not handle format-
number(number, '$#,##0.00')
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
   URL: http://127.0.0.1:/samples/petstore/viewCart.do
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


java.lang.IllegalArgumentException: Malformed pattern $#,##0.00
at
org.apache.cocoon.generation.JXTemplateGenerator.execute(JXTemplateGenerator.java:2957)
at
org.apache.cocoon.generation.JXTemplateGenerator.execute(JXTemplateGenerator.java:3131)
at
org.apache.cocoon.generation.JXTemplateGenerator.generate(JXTemplateGenerator.java:2746)

But it should work as it does in XSLT. This error occurs in the PetStore samples
for the Cart.xml when using JXPath view.

RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]

 -Original Message-
 From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] 
 Sent: woensdag 5 november 2003 14:29
 To: [EMAIL PROTECTED]

 Unico Hommes wrote:

 -Original Message-
 From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]
 Sent: woensdag 5 november 2003 14:02
 To: [EMAIL PROTECTED]

 Stefano Mazzocchi wrote:

 setStatus' friends the sendError brothers are also be 
 eligible for 
 FOM membership. But this change has a dependency on the 
 discussion 
 about bodyless responses since if you'd do a sendError 
 from a flow 
 script and then send a page afterwards this would result 
 in errors.

 I dislikde sendError because, in fact, HTTP does not have the 
 concept of errors, but only status codes and empty-payload

 responses.

 In the future, it's entirely possible to have a 309 or

 equivalent that

 is not an error, but has a empty-payload response. I would

 dislike to

 call sendError() to send something that is not an error,

 feels hacky.

 I think the optimal solution is:

  1) add response.setStatus() in FOM
  2) allow the flowscript to terminate without calling

 sendPage* [thus

 resulting in an empty payload]

 Sorry to jump in late, I'm probably lagging behind a few posts, but 
 was the possibility of having *pipelines* send empty payload 
 considered instead? This way flow will always have to 
 sendPage(), but 
 the result would be empty content anyway. With the added bonus of 
 having the pipeline flexibility to, say, set headers.

  But the function of a pipeline is specifically towards the 
 production of
  an xml response body. To have to set up all the components, 
 execute the
  pipeline and then fooling the pipeline to send its data to 
 a null output
  or refrain from pipeline execution altogether? In some 
 scenarios that
  may be necessary, for instance in the case of the http HEAD 
 function.
  The point is, you shouldn't have to, because there are a lot of
  situations where its just unneccesary overhead. (for example all the
  dummy responses in the davmap sitemap)

 I sure can see some use of this. In a few cases (think PUT) you might 
 have XML input flowing through the pipeline (say you might want to 
 transform it) yet you have to send an empty response: in this 
 scenario 
 using a pipeline looks like the best option to me. 

Hmm, not to me. The way I have implemented PUT in the current davmap
differs from what you are suggesting.

Here I use two pipelines. One generates the request body:

map:pipeline internal-only=true
  map:match pattern=request/PUT
map:generate type=stream /
!-- map:transform type=myfilter / --
map:serialize type=xml /
  /map:match
/map:pipeline

map:pipeline
  map:match pattern=PUT/**
map:call function=put
  map:parameter name=input value=cocoon:/request/PUT /
  map:parameter name=output value={global:staging}{1} /
/map:call
  /map:match
/map:pipeline

The flow uses essentially the internal only request body generating
pipeline in a processPipelineTo type of construct:

Function put(in,out) {

  var s1 = resolver.resolve(in);
  var s2 = resolver.resolve(out);
  cocoon.processPipelineTo(in.inputStream, out.ouputStream);

  cocoon.response.setStatus(201);

  // have to do:
  cocoon.sendPage(dummy,{});

  // but really want to do this:
  // return null;
}

 Also, I 
 feel that the 
 sitemap is core and flow, while being core, is somehow 
 piggybacked on 
 the sitemap. I tend to think, then, that deciding whether to 
 send output 
 or not should belong more to the sitemap than to the flow.

The sitemap is always in control, we are talking about changing the
sitemap semantics in that a map:call function / is extended so that it
can signal the sitemap to terminate processing the request. Maybe we
could add an attribute specifically allowing the function to not send a
page such as in map:call function=blah redirect=false / but I
think this will only complicate things because now what happens if the
function does do a redirect? And what if we want to do what Vadim
suggested:

map:call function=login
  map:generate /
  map:transform /
  map:serialize /
/map:call

Function login() {
  while(!loggedIn) {
sendPageAndWait(login);
loggedIn = ..
  }
  return {user:user,message:message};
}

-- Unico

 Ciao,

 -- 
 Gianugo Rabellino
 Pro-netics s.r.l. -  http://www.pro-netics.com
 Orixo, the XML business alliance - http://www.orixo.com
  (Now blogging at: http://blogs.cocoondev.org/gianugo/)

Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)

2003-11-05 Thread Berin Loritsch

Stefano Mazzocchi wrote:


I'm all for continuing the migration. Even better: the more hands do the 
porting, the more people will know the internals, the better shape the 
tree ends up being.

I think we should make a serious effort to finish this migration rather 
than throw away what Berin did.

But this cannot drag along too much for the reason above.
That is why I chose to fail early instead of dragging on and on.

--

They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety.
- Benjamin Franklin

[Woody] wd:help

Dear All,

Correct me if I am wrong, but it does not appear that the wd:help/ 
tag of the wd:widget/ is supported by the 'woody-field-styling.xsl', 
except for when it is used inside a wd:group/.

Would anyone object to me adding this?

I was thinking of adding handling for this to the 'woody-field-common' 
template, by adding a '?' that is linked to a javascript alert 
containing the text of the wd:help/, that sits just after the field, 
like the required '*.

Alternatively, it could be done with a div popup.

WDYT?

regards Jeremy

Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]

Unico Hommes wrote:

-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] 
Sent: woensdag 5 november 2003 13:55
To: [EMAIL PROTECTED]

Le Mercredi, 5 nov 2003, à 13:11 Europe/Zurich, Reinhard 
Poetz a écrit :

...I'm +1 with the idea to send pages without payload but -0 with flowscripts which terminate without calling sendPage*. I would prefer an explicit way

Same here: flowscripts should not hide the fact that a response is indeed sent.

I suggested on the other thread that we could use return null as a signal for that.

function put() {
 doput();
 setStatus(201);
 return null;
}
Null would mean a pipeline is not required to be executed.

-1 : we must have an explicit call to an environment-related method that 
allows to detect if the application tries to send content back 
afterwards. And this should not be available only in the flow as we may 
want to do the same in an action.

That's why I proposed a redirect to a special null pseudo-protocol, as 
once a redirect has been set the sitemap engine stops further processing 
(unless it's a cocoon: redirect). But this may not be the cleanest way 
and we may better use a method on the response object. And if 
sendStatus() and sendError() don't fit, let's do our own 
sendEmptyResponse(int status, String message).

Sylvain

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

Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]

On Wednesday, Nov 5, 2003, at 14:20 Europe/Rome, Unico Hommes wrote:

From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]

Sorry to jump in late, I'm probably lagging behind a few
posts, but was the possibility of having *pipelines* send
empty payload considered instead? This way flow will always
have to sendPage(), but the result would be empty content
anyway. With the added bonus of having the pipeline
flexibility to, say, set headers.
But the function of a pipeline is specifically towards the production 
of
an xml response body. To have to set up all the components, execute the
pipeline and then fooling the pipeline to send its data to a null 
output
or refrain from pipeline execution altogether? In some scenarios that
may be necessary, for instance in the case of the http HEAD function.
The point is, you shouldn't have to, because there are a lot of
situations where its just unneccesary overhead. (for example all the
dummy responses in the davmap sitemap)
I'm with Unico here: the use of HTTP in a DeltaV scenario is *massive* 
and involves tons of requests/responses for even a simple operation 
like moving a file. Many of these responses have no payload as the 
result is contained in the response headers.

Note, this *does not* imply that you shouldn't be able to use a 
pipeline to do further processing (even if it results in no payload), 
but I think it should *not* be forced upon us to have a dummy 
pipeline just to satisfy these contraints.

Different story for Reinhard's concern, I think it's a valid point: 
most situations on the web handle requests that return a payload... 
having a way to signal that hey, you are missing your payload is a 
good debugging advice and we wouldn't want to loose this for those 
rare (in comparison) payload-less responses.

So, what about

 cocoon.sendEmptyResponse(status-code)

?

--
Stefano.

RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]

 -Original Message-
 From: Sylvain Wallez [mailto:[EMAIL PROTECTED] 
 Sent: woensdag 5 november 2003 15:12
 To: [EMAIL PROTECTED]

 Unico Hommes wrote:

 -Original Message-
 From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
 Sent: woensdag 5 november 2003 13:55
 To: [EMAIL PROTECTED]

 Le Mercredi, 5 nov 2003, à 13:11 Europe/Zurich, Reinhard 
 Poetz a écrit 
 :

 ...I'm +1 with the idea to send pages without payload but 
 -0 with flowscripts which terminate without calling 
 sendPage*. I would prefer an explicit way

 Same here: flowscripts should not hide the fact that a 
 response is indeed sent.

 I suggested on the other thread that we could use return 
 null as a signal for that.

 function put() {
   doput();
   setStatus(201);
   return null;
 }

 Null would mean a pipeline is not required to be executed.

 -1 : we must have an explicit call to an environment-related 
 method that allows to detect if the application tries to send 
 content back afterwards. And this should not be available 
 only in the flow as we may want to do the same in an action.

I see.

 That's why I proposed a redirect to a special null 
 pseudo-protocol, as once a redirect has been set the sitemap 
 engine stops further processing (unless it's a cocoon: 
 redirect). But this may not be the cleanest way and we may 
 better use a method on the response object. And if
 sendStatus() and sendError() don't fit, let's do our own 
 sendEmptyResponse(int status, String message).

sendStatus(int status, String message) sets the hasRedirected flag to true.

setStatus(int status) doesn't.

Perhaps this is correct way of doing it.

 Sylvain

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

Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]

On Wednesday, Nov 5, 2003, at 14:28 Europe/Rome, Gianugo Rabellino 
wrote:

Unico Hommes wrote:

-Original Message-
From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] Sent: woensdag 5 
november 2003 14:02
To: [EMAIL PROTECTED]

Stefano Mazzocchi wrote:

setStatus' friends the sendError brothers are also be eligible for 
FOM membership. But this change has a dependency on the discussion 
about bodyless responses since if you'd do a sendError from a flow 
script and then send a page afterwards this would result in  errors.

I dislikde sendError because, in fact, HTTP does not have the 
concept of errors, but only status codes and empty-payload
responses.

In the future, it's entirely possible to have a 309 or
equivalent that
is not an error, but has a empty-payload response. I would
dislike to
call sendError() to send something that is not an error,
feels hacky.

I think the optimal solution is:

1) add response.setStatus() in FOM
2) allow the flowscript to terminate without calling
sendPage* [thus
resulting in an empty payload]
Sorry to jump in late, I'm probably lagging behind a few posts, but 
was the possibility of having *pipelines* send empty payload 
considered instead? This way flow will always have to sendPage(), 
but the result would be empty content anyway. With the added bonus 
of having the pipeline flexibility to, say, set headers.

But the function of a pipeline is specifically towards the production 
of
an xml response body. To have to set up all the components, execute 
the
pipeline and then fooling the pipeline to send its data to a null 
output
or refrain from pipeline execution altogether? In some scenarios that
may be necessary, for instance in the case of the http HEAD function.
The point is, you shouldn't have to, because there are a lot of
situations where its just unneccesary overhead. (for example all the
dummy responses in the davmap sitemap)
I sure can see some use of this. In a few cases (think PUT) you might 
have XML input flowing through the pipeline (say you might want to 
transform it) yet you have to send an empty response: in this scenario 
using a pipeline looks like the best option to me.
I agree that there are situations where it makes sense to go thru a 
pipeline even for potentially emtpy responses, but I also see tons of 
reasons to avoid going thru a pipeline again.

Also, I feel that the sitemap is core and flow, while being core, is 
somehow piggybacked on the sitemap. I tend to think, then, that 
deciding whether to send output or not should belong more to the 
sitemap than to the flow.
h,

The sitemap is core in the fact that the flowscript function is still 
matched there... but deciding the output in case of an empty response 
is a concern of the programmatical side of things, of the logic that 
controls the flow of hte application, not of the logic that drives 
the generation of the payload.

phisolophical issue, I agree, and hardly objective, but the more 
complex the webapp becomes (and webdavapps tend to be *very* complex 
from a flow perspective even for very simple cases) the more stuff 
should be done in the flow (and in java components directly called by 
the flow!) and less in the pipeline.

pipeline should deal with content, flow should deal with headers.

of course, your mileage may vary, but that's a potential design pattern 
that you might want to use to measure how you are writing your 
webdavapp

... but this is such a undiscovered land that I might just be dead 
wrong.

but my gut feeling tells me that webdavapps will have a lot more flow 
than pipelines.

--
Stefano.

Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)

On Wednesday, Nov 5, 2003, at 14:58 Europe/Rome, Berin Loritsch wrote:

Stefano Mazzocchi wrote:


I'm all for continuing the migration. Even better: the more hands do 
the porting, the more people will know the internals, the better 
shape the tree ends up being.
I think we should make a serious effort to finish this migration 
rather than throw away what Berin did.
But this cannot drag along too much for the reason above.
That is why I chose to fail early instead of dragging on and on.
I understood this and, believe me, I highly appreciated the move. So 
far, in fact, that I'm now more than willing to keep going exactly to 
honor your work and the respect you showed us in doing it and admitting 
your problems so early and so honestly.

--
Stefano.

Re: Woody: managing persistence sessions

On Wednesday, November 5, 2003, at 01:06 PM, Reinhard Poetz wrote:

I am really impressed with the Cocoon Forms framework!!
And the continuation-lifecycle 'catch' events work well too!!
There is one more event that some people could conceivably want 
but I do not know if it is possible  The Continuation has
completed.
Many thanks guys!
Sorry, but I haven't got what you mean with The Continuation has
completed.
When is this event reached? Can you give a example (maybe using some
code)?
This is what I am thinking about:

If you take this code snippet here:

  . . .
   // get the User
   form.load (user);
   session.close();
   form.showForm (formURI);
   session = factory.createSession ();
   form.save (user);
   // save the User
  . . .
The line session.close(); in the sample above, could be replaced by 
this (obviously after the snippet):

catch (break) {
session.close();
}
because it will be called just as a continuation is about to start

whereas the line session = factory.createSession (); does not have an 
equivalent handler that would trigger after all continuation handling 
has completed.

do you see what I mean?

regards Jerm

Re: [Woody] wd:help

Jeremy Quinn wrote:

Dear All,

Correct me if I am wrong, but it does not appear that the wd:help/ 
tag of the wd:widget/ is supported by the 'woody-field-styling.xsl', 
except for when it is used inside a wd:group/.

Would anyone object to me adding this?


Certainly not! Do it, do it ;-)

I was thinking of adding handling for this to the 'woody-field-common' 
template, by adding a '?' that is linked to a javascript alert 
containing the text of the wd:help/, that sits just after the field, 
like the required '*.

Alternatively, it could be done with a div popup.


I would prefer this solution which would allow for markup in help, and 
the CalendarPopup.js in Woody [1] already contains a library for this to 
build the popups [2].

Having a ? IMO makes the page look heavier, and I was thinking of 
placing a help mode switch in the pages. This switch (analogous to the 
one that appears in the title bar of some dialog on Windows) would 
change the mouse cursor to a ? and display the associated help (if 
any) associated to clicked elements. How hard would this be to do?

[1] http://www.mattkruse.com/javascript/calendarpopup/
[2] http://www.mattkruse.com/javascript/popupwindow/
WDYT?

regards Jeremy




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

Re: [Woody] wd:help

On Wed, 2003-11-05 at 15:44, Sylvain Wallez wrote:
 Jeremy Quinn wrote:
 
  Dear All,
 
  Correct me if I am wrong, but it does not appear that the wd:help/ 
  tag of the wd:widget/ is supported by the 'woody-field-styling.xsl', 
  except for when it is used inside a wd:group/.
 
  Would anyone object to me adding this?
 
 
 Certainly not! Do it, do it ;-)
 
  I was thinking of adding handling for this to the 'woody-field-common' 
  template, by adding a '?' that is linked to a javascript alert 
  containing the text of the wd:help/, that sits just after the field, 
  like the required '*.
 
  Alternatively, it could be done with a div popup.
 
 
 I would prefer this solution which would allow for markup in help, and 
 the CalendarPopup.js in Woody [1] already contains a library for this to 
 build the popups [2].
 
 Having a ? IMO makes the page look heavier, and I was thinking of 
 placing a help mode switch in the pages. This switch (analogous to the 
 one that appears in the title bar of some dialog on Windows) would 
 change the mouse cursor to a ? and display the associated help (if 
 any) associated to clicked elements.

I'm not sure about this from a usability point of view.

  How hard would this be to do?
 
 [1] http://www.mattkruse.com/javascript/calendarpopup/
 [2] http://www.mattkruse.com/javascript/popupwindow/

Another alternative would be to use the label of the widget as trigger
to show the help.

Currently the wt:widget-label tag only outputs the content of the label
of the widget, without any tag around it telling it is the label. I'm
thinking we should maybe replace that with a wt:widget-displaydata which
would effectively insert a wi:displaydata containg the label  help (
hotkey in the future), so that the XSL can react on that and put the
label inside a label tag, and also add some javascript to show the
help when you hover over it. (the label could have a e.g. a slightly
different color if it has help)

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]

2003-11-05 Thread Vadim Gritsenko

Stefano Mazzocchi wrote:

On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote:

setStatus' friends the sendError brothers are also be eligible for FOM
membership. But this change has a dependency on the discussion about
bodyless responses since if you'd do a sendError from a flow script and
then send a page afterwards this would result in errors.


I dislikde sendError because, in fact, HTTP does not have the 
concept of errors, but only status codes and empty-payload responses.

In the future, it's entirely possible to have a 309 or equivalent that 
is not an error, but has a empty-payload response. I would dislike to 
call sendError() to send something that is not an error, feels hacky.

I think the optimal solution is:

 1) add response.setStatus() in FOM
 2) allow the flowscript to terminate without calling sendPage* [thus 
resulting in an empty payload]

Vote?


Before we vote: how to resolve flow actions issue then? There should 
be migration path for users who already have wrote an actions wtih flow.

(remember? you've said that actions should be replaced with flowscript ;-)

Vadim

RE: ComponentSelector could not find the component for hint [personnel]


I know, I did that. The repository block depends on the databases block.
Look for the inspector configuration entry in cocoon.xconf. Inside is a
configuration for a SimpleJdbcSourceDescriptor. It uses the personel
datasource. Should I comment the offending configuration? Or should the
user?

Regards, Unico.

 
 -Original Message-
 From: Leszek Gawron [mailto:[EMAIL PROTECTED] 
 Sent: woensdag 5 november 2003 16:06
 To: [EMAIL PROTECTED]
 
 Current CVS version.
 
 Would be completely normal if I did use the personnel 
 datasource, but I do not use it so I deleted it. So goes the 
 stacktrace: 
 
 org.apache.avalon.framework.service.ServiceException: 
 datasources: ComponentSelector could not find the component 
 for hint [personnel] (key [personnel]) 
 (Key='org.apache.avalon.excalibur.datasource.DataSourceCompone
 ntSelector/personnel')
   at 
 org.apache.avalon.framework.service.WrapperServiceSelector.sel
 ect(WrapperServiceSelector.java:124)
   at 
 org.apache.cocoon.components.source.impl.SimpleJdbcSourceDescr
 iptor.initialize(SimpleJdbcSourceDescriptor.java:176)
   at 
 org.apache.avalon.framework.container.ContainerUtil.initialize
 (ContainerUtil.java:282)
   at 
 org.apache.cocoon.components.source.impl.SourceDescriptorManag
 er.initialize(SourceDescriptorManager.java:142)
   at 
 org.apache.avalon.framework.container.ContainerUtil.initialize
 (ContainerUtil.java:282)
   at 
 org.apache.avalon.excalibur.component.DefaultComponentFactory.
 newInstance(DefaultComponentFactory.java:323)
   at 
 org.apache.avalon.excalibur.component.ThreadSafeComponentHandl
 er.initialize(ThreadSafeComponentHandler.java:141)
   at 
 org.apache.avalon.excalibur.component.ExcaliburComponentManage
 r.initialize(ExcaliburComponentManager.java:554)
   at 
 org.apache.cocoon.components.CocoonComponentManager.initialize
 (CocoonComponentManager.java:539)
   at 
 org.apache.avalon.framework.container.ContainerUtil.initialize
 (ContainerUtil.java:282)
   at org.apache.cocoon.Cocoon.initialize(Cocoon.java:334)
   at 
 org.apache.avalon.framework.container.ContainerUtil.initialize
 (ContainerUtil.java:282)
   at 
 org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonSer
 vlet.java:1369)
   at 
 org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:515)
   at 
 org.apache.catalina.core.StandardWrapper.loadServlet(StandardW
 rapper.java:935)
   at 
 org.apache.catalina.core.StandardWrapper.load(StandardWrapper.
 java:823)
   at 
 org.apache.catalina.core.StandardContext.loadOnStartup(Standar
 dContext.java:3422)
   at 
 org.apache.catalina.core.StandardContext.start(StandardContext
 .java:3623)
   at 
 org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
   at 
 org.apache.catalina.core.StandardHost.start(StandardHost.java:754)
   at 
 org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
   at 
 org.apache.catalina.core.StandardEngine.start(StandardEngine.java:363)
   at 
 org.apache.catalina.core.StandardService.start(StandardService
 .java:497)
   at 
 org.apache.catalina.core.StandardServer.start(StandardServer.j
 ava:2190)
   at 
 org.apache.catalina.startup.CatalinaService.start(CatalinaServ
 ice.java:273)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
 orImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
 odAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:324)
   at 
 org.apache.catalina.startup.BootstrapService.start(BootstrapSe
 rvice.java:245)
   at 
 org.apache.catalina.startup.BootstrapService.main(BootstrapSer
 vice.java:307)
 Caused by: 
 org.apache.avalon.framework.component.ComponentException: 
 datasources: ComponentSelector could not find the component 
 for hint [personnel] (key [personnel])
   at 
 org.apache.avalon.excalibur.component.ExcaliburComponentSelect
 or.select(ExcaliburComponentSelector.java:237)
   at 
 org.apache.avalon.framework.service.WrapperServiceSelector.sel
 ect(WrapperServiceSelector.java:120)
   ... 30 more
 
   lg
 -- 
 __
  | /  \ |Leszek Gawron//  \\
 \_\\  //_/   [EMAIL PROTECTED]   _\\()//_
  .'/()\'. Phone: +48(501)720812 / //  \\ \
   \\  //  recursive: adj; see recursive  | \__/ |

RE: Woody: managing persistence sessions


From: Jeremy Quinn

 
 On Wednesday, November 5, 2003, at 01:06 PM, Reinhard Poetz wrote:
 
  I am really impressed with the Cocoon Forms framework!!
  And the continuation-lifecycle 'catch' events work well 
 too!! There 
  is one more event that some people could conceivably want 
  but I 
  do not know if it is possible  The Continuation has 
 completed.
 
  Many thanks guys!
 
  Sorry, but I haven't got what you mean with The Continuation has 
  completed. When is this event reached? Can you give a 
 example (maybe 
  using some code)?
 
 This is what I am thinking about:
 
 If you take this code snippet here:
 
. . .
 // get the User
 form.load (user);
 session.close();
 form.showForm (formURI);
 session = factory.createSession ();
 form.save (user);
 // save the User
. . .
 
 The line session.close(); in the sample above, could be replaced by 
 this (obviously after the snippet):
 
   catch (break) {
   session.close();
   }
 
 because it will be called just as a continuation is about to start
 
 whereas the line session = factory.createSession (); does 
 not have an 
 equivalent handler that would trigger after all continuation handling 
 has completed.

IIU Sylvain's docs correctly
(http://wiki.cocoondev.org/Wiki.jsp?page=RhinoWithContinuations) 

catch (continue) {
   session = factory.createSession ();
}

should do it. Doesn't it work for you (I haven't tried it yet.)?

If not you'll have to wait for my interceptions implementation (hintor
help me finishing it hint/ ;-) which would fill this gap.
Currently I haven't much time doing it (but hopefully things change in
the next weeks - expect more work on this then).

--
Reinhard

RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]


From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] 

snip/

 Different story for Reinhard's concern, I think it's a valid point: 
 most situations on the web handle requests that return a payload... 
 having a way to signal that hey, you are missing your payload is a 
 good debugging advice and we wouldn't want to loose this for those 
 rare (in comparison) payload-less responses.
 
 So, what about
 
   cocoon.sendEmptyResponse(status-code)
 

+1

Reinhard

Re: [Woody] wd:help

On Wednesday, November 5, 2003, at 02:44 PM, Sylvain Wallez wrote:

Jeremy Quinn wrote:

Dear All,

Correct me if I am wrong, but it does not appear that the wd:help/ 
tag of the wd:widget/ is supported by the 
'woody-field-styling.xsl', except for when it is used inside a 
wd:group/.

Would anyone object to me adding this?


Certainly not! Do it, do it ;-)
He He!

I was thinking of adding handling for this to the 
'woody-field-common' template, by adding a '?' that is linked to a 
javascript alert containing the text of the wd:help/, that sits 
just after the field, like the required '*.

Alternatively, it could be done with a div popup.


I would prefer this solution which would allow for markup in help
Markup would be good

, and the CalendarPopup.js in Woody [1] already contains a library for 
this to build the popups [2].
OK

Having a ? IMO makes the page look heavier, and I was thinking of 
placing a help mode switch in the pages. This switch (analogous to 
the one that appears in the title bar of some dialog on Windows) would 
change the mouse cursor to a ? and display the associated help (if 
any) associated to clicked elements.
Nice idea  not sure about being inspired by Windows GUI design 
though :)

Would they best popup (in help-mode) when clicked, or rolled-over?

How hard would this be to do?
Not sure . but it could be beyond my current DHTML knowledge, do 
you know of any sites that do this?  ;)

It is something I'd like to have a go at . this weekend however I 
will be tied up, upgrading my Macs to Panther :)

There is a CSS2 directive for changing the cursor, but have no idea how 
well implemented it is across browsers. 
http://www.w3.org/TR/CSS2/ui.html#cursor-props, there is a 'help' 
cursor.

I'll checkout your references to the popup stuff 

regards Jeremy

Re: [Woody] wd:help

Bruno Dumon wrote:

On Wed, 2003-11-05 at 15:44, Sylvain Wallez wrote:

Jeremy Quinn wrote:

Dear All,

Correct me if I am wrong, but it does not appear that the wd:help/ tag of the wd:widget/ is supported by the 'woody-field-styling.xsl', except for when it is used inside a wd:group/.

Would anyone object to me adding this?

Certainly not! Do it, do it ;-)

I was thinking of adding handling for this to the 'woody-field-common' template, by adding a '?' that is linked to a javascript alert containing the text of the wd:help/, that sits just after the field, like the required '*.

Alternatively, it could be done with a div popup.

I would prefer this solution which would allow for markup in help, and the CalendarPopup.js in Woody [1] already contains a library for this to build the popups [2].

Having a ? IMO makes the page look heavier, and I was thinking of placing a help mode switch in the pages. This switch (analogous to the one that appears in the title bar of some dialog on Windows) would change the mouse cursor to a ? and display the associated help (if any) associated to clicked elements.

I'm not sure about this from a usability point of view.

I find this quite convenient on Windows, and Mac has (or used to have -
dunno in MacOS X) the equivalent with help balloons.

How hard would this be to do?

[1] http://www.mattkruse.com/javascript/calendarpopup/
[2] http://www.mattkruse.com/javascript/popupwindow/

Another alternative would be to use the label of the widget as trigger to show the help.

Do you mean that clicking on the label would show the help? Normally,
clicking on a label gives focus to the associated input widget. And what
about label-less widgets such as buttons?

Currently the wt:widget-label tag only outputs the content of the label of the widget, without any tag around it telling it is the label. I'm thinking we should maybe replace that with a wt:widget-displaydata which would effectively insert a wi:displaydata containg the label help (hotkey in the future), so that the XSL can react on that and put the label inside a label tag

Hehe, exactly my thoughts after adding support for label today in
page-styling.xsl...

and also add some javascript to show the help when you hover over it. (the label could have a e.g. a slightly different color if it has help)

Hover is currently used for tooltips defined though wd:hint.

Sylvain

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

encoding problem

2003-11-05 Thread Leszek Gawron

Current CVS version of cocoon:

ServerPagesGenerator.generate(): java.lang.RuntimeException:
org.xml.sax.SAXException: Attempt to output character of integral value 346
that is not represented in specified output encoding of .

I am using UTF-8 everywhere and switching to current cocoon cvs version either
displays the above error or just messes up all polish characters in my html
pages.

LG
-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

Re: encoding problem

2003-11-05 Thread Leszek Gawron

On Wed, Nov 05, 2003 at 04:33:51PM +0100, Leszek Gawron wrote:
 Current CVS version of cocoon:
 
 ServerPagesGenerator.generate(): java.lang.RuntimeException:
 org.xml.sax.SAXException: Attempt to output character of integral value 346
 that is not represented in specified output encoding of .
 
 I am using UTF-8 everywhere and switching to current cocoon cvs version either
 displays the above error or just messes up all polish characters in my html
 pages.
I am sorry. This has got nothing to do with cocoon. It's tomcat's 4.1.29
fault. It sets Content-Type header to ISO-8859-1 .. strange
lg
-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

XSLT problem

2003-11-05 Thread Leszek Gawron

This error occurs in current cvs version with xalan/xslt transformer. It does not 
occur with xsltc:


FATAL_E (2003-11-05) 17:02.58:968   [core.xslt-processor] 
(/gemini-manager/service/pocket-list) Thread-8/TraxErrorHandler: Error in 
TraxTransformer: javax.xml.transform.TransformerException: org.xml.sax.SAXException: 
Attempt to output character of integral value 322 that is not represented in specified 
output encoding of .
javax.xml.transform.TransformerException: org.xml.sax.SAXException: Attempt to output 
character of integral value 322 that is not represented in specified output encoding 
of .
at org.apache.xalan.templates.ElemValueOf.execute(ElemValueOf.java:327)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2362)
at 
org.apache.xalan.transformer.TransformerImpl.transformToString(TransformerImpl.java:2045)
at 
org.apache.xalan.templates.ElemAttribute.constructNode(ElemAttribute.java:232)
at org.apache.xalan.templates.ElemElement.execute(ElemElement.java:363)
at org.apache.xalan.templates.ElemAttribute.execute(ElemAttribute.java:144)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2362)
at 
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:716)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2362)
at org.apache.xalan.templates.ElemIf.execute(ElemIf.java:199)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2362)
at 
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:716)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2362)
at 
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:716)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2362)
at 
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:716)
at 
org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:429)
at 
org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:215)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2362)
at 
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:716)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2362)
at 
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:716)
at 
org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:429)
at 
org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:215)
at 
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2362)
at 
org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2228)
at 
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1306)
at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3376)
at 
org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:427)
at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:91)
at 
org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:579)
at 
org.apache.cocoon.www.file_.c_.Dev.gemini_server.gemini_manager.__service.view.pocket_list_xsp.generate(C:\DevTools\jakarta-tomcat-4.1.27-LE-jdk14\work\Standalone\localhost\_\cocoon-files\org\apache\cocoon\www\file_\c_\Dev\gemini_server\gemini_manager\__service\view\pocket_list_xsp.java:1042)
at 
org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:262)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:557)
at 
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:196)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:501)
at 
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:147)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at

Re: Woody: managing persistence sessions

On Wednesday, November 5, 2003, at 03:23 PM, Reinhard Poetz wrote:

From: Jeremy Quinn

On Wednesday, November 5, 2003, at 01:06 PM, Reinhard Poetz wrote:

I am really impressed with the Cocoon Forms framework!!
And the continuation-lifecycle 'catch' events work well
too!! There
is one more event that some people could conceivably want
 but I
do not know if it is possible  The Continuation has
completed.
Many thanks guys!
Sorry, but I haven't got what you mean with The Continuation has
completed. When is this event reached? Can you give a
example (maybe
using some code)?
This is what I am thinking about:

If you take this code snippet here:

   . . .
// get the User
form.load (user);
session.close();
form.showForm (formURI);
session = factory.createSession ();
form.save (user);
// save the User
   . . .
The line session.close(); in the sample above, could be replaced by
this (obviously after the snippet):
catch (break) {
session.close();
}
because it will be called just as a continuation is about to start

whereas the line session = factory.createSession (); does
not have an
equivalent handler that would trigger after all continuation handling
has completed.
IIU Sylvain's docs correctly
(http://wiki.cocoondev.org/Wiki.jsp?page=RhinoWithContinuations)
catch (continue) {
   session = factory.createSession ();
}
should do it. Doesn't it work for you (I haven't tried it yet.)?
it works fine  but I think it has a different meaning  it is 
when an existing continuation is resumed ... ie. when a Request comes 
back to a continuation-id.

Whereas what I was thinking about is being notifies of when the 
continuation-cycle is complete and the continuation is disposed of.

If not you'll have to wait for my interceptions implementation 
(hintor
help me finishing it hint/ ;-) which would fill this gap.
Currently I haven't much time doing it (but hopefully things change in
the next weeks - expect more work on this then).
Cool :)

regards Jeremy

Re: Woody: managing persistence sessions

On Wednesday, November 5, 2003, at 02:45 PM, Antonio Gallardo wrote:

Hi Jeremy:

Can you explain a little bit? I still does not understand your point.
Sorry I know it is my fault.
OK, I will try again  :)

Lets say you have a script that uses continuations (sendPageAndWait is 
called).

Lets also say that you have to do specific things (eg. persistence 
management) just before starting a continuation-cycle (where you want 
to keep sending the form until it has validated), and just after  the 
continuation-cycle is finished.

With no 'continuation-events' you have to place the code before and 
after each function call to sendPageAndWait (or the function that calls 
it like form.sendPage).

If you have several places in your script where sendPageAndWait is 
called, or your scripts call other scripts that do sendPageAndWait, you 
have lots of code duplicated all over the place.

If you use the 'continuation-events' however, you do not need to 
duplicate anything, you stuff just gets called as needed.

The only problem here, is that there is no event that specifies, the 
continuation-cycle has finished.

There are events that tell you other things like continue: a 
continuation has resumed , break: a continuation has started, 
return: sendPageAndWait has finished rendering the page.

Any clearer?

regards Jeremy

Jeremy Quinn dijo:
On Wednesday, November 5, 2003, at 01:06 PM, Reinhard Poetz wrote:

I am really impressed with the Cocoon Forms framework!!
And the continuation-lifecycle 'catch' events work well too!!
There is one more event that some people could conceivably want 
but I do not know if it is possible  The Continuation has
completed.
Many thanks guys!
Sorry, but I haven't got what you mean with The Continuation has
completed.
When is this event reached? Can you give a example (maybe using some
code)?
This is what I am thinking about:

If you take this code snippet here:

   . . .
// get the User
form.load (user);
session.close();
form.showForm (formURI);
session = factory.createSession ();
form.save (user);
// save the User
   . . .
The line session.close(); in the sample above, could be replaced by
this (obviously after the snippet):
catch (break) {
session.close();
}
because it will be called just as a continuation is about to start

whereas the line session = factory.createSession (); does not have 
an
equivalent handler that would trigger after all continuation handling
has completed.

do you see what I mean?

regards Jerm

[OT] Using components outside of Cocoon

2003-11-05 Thread Steve K

Hey folks --

I have developed a few Avalon Components (they all extend 
AbstractLogEnabled) that I am currently using inside of Cocoon, but I 
would like to use them in another, much simpler application.  I know the 
ExcalibirTestCase does a pretty good job at providing a simple 
environment for the components to run in -- is there a similar wrapper I 
can use to run the components in another app?  Or do I have to use 
ECM/Fortress/Merlin to host the components?

cheers,
-steve

Re: [OT] Using components outside of Cocoon

2003-11-05 Thread Berin Loritsch

Steve K wrote:

Hey folks --

I have developed a few Avalon Components (they all extend 
AbstractLogEnabled) that I am currently using inside of Cocoon, but I 
would like to use them in another, much simpler application.  I know the 
ExcalibirTestCase does a pretty good job at providing a simple 
environment for the components to run in -- is there a similar wrapper I 
can use to run the components in another app?  Or do I have to use 
ECM/Fortress/Merlin to host the components?
The ExcaliburTestCase is an Avalon base test class.  YOu can continue to
use that to test your components. (although you should feel free to ask
these types of questions on the Avalon Users list as well).
--

They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety.
- Benjamin Franklin

[Woody-binding] wb:repeater unique-path

2003-11-05 Thread Antonio Gallardo

Hi:

I am trying to do a form.save(bean) from an empty displayed form.I have
2 days with this sample and still not working. :-(


My problem is that inside the repeater there is only 1 value (res_id) of
datatype integer.

Binding just save the first 2 values and an empty repeater.

BTW, A question why we need to define the unique-path attribute as
@res_id AFAIK, a collection cannot have an attribute called res_id.
Please explain. :-D

Best Regards,

Antonio Gallardo

Here is the binding:

wb:context xmlns:wb=... path=/
  wb:value id=rol_name path=rol_name/
  wb:value id=rol_enable path=rol_enable/
  wb:repeater id=resource parent-path=.
row-path=auth_permissionList unique-row-id=res_id
unique-path=@res_id
  wb:on-bind
  wb:value id=res_id path=res_id/
  /wb:on-bind
  wb:on-delete-row
  wb:delete-node/
  /wb:on-delete-row

  wb:on-insert-row
  wb:insert-bean classname=test.Auth_permission
  addmethod=addAuth_permission/
/wb:on-insert-row
/wb:repeater
/wb:context

The Bean is:

public class Auth_role implements java.io.Serializable
{

   private Integerrol_id;
   private String rol_name;
   private Booleanrol_enable;
  //---

   /* Getters and Setters

   //---

   private Collection auth_user_roleList = new ArrayList();

/* Getters and Setters */

//---

   private Collection auth_permissionList = new ArrayList();

   public Collection getAuth_permissionList() { return auth_permissionList;}

   public void setAuth_permissionList(Collection c) {
this.auth_permissionList = c;}

   public void addAuth_permission( Auth_permission auth_permission )
   {
  auth_permission.setAuth_role(this);
  auth_permissionList.add( auth_permission );
   }
}

Re: Saving pipeline output to a temp file...everything you wanted to know but were afraid to ask!

2003-11-05 Thread Josiel Maimoni de Figueiredo

Hi, Andrzej,
 you save your tempfile, but when you delete it? Is it a temporary 
file, no?

Best Regards,

  Josiel

Andrzej Jan Taramina wrote:

dominik:

 

I'm sorry to bother you, but I can't direcly subscribe to the mail list
because of my company. you posted on the cocoon list:
   

No botherthe least I can do is to help out a fellow Cocoon afficionado, 
since I have received a lot of help myself.  Gotta pass on the karma when you 
can. ;-)

However, I will copy this reply to the list, in case anyone else there has a 
similar issue.  This way it will be in the archives for future reference or 
maybe someone will post it on the Cocoon Wiki? (hint...hint ;-)  ).

 

Try SourceWritingTransformer from the sitemap or else
cocoon.processPipelineTo from a flowscript.
 

 

I decided to bite the bullet and add flowscript to my appit worked 
perfectly!
   

 

would you please be so kind and give me a short outline of this solution? I'm
having a similar problem for weeks, but there was nothing is sight.
   

Sure thing.  Here is what I did (salient parts only...not a full working 
example):

I have a flowscript called saveToFile.flow (I call my flowscripts *.flow to 
distinguish them from normal client side javascripts, but you can call them 
*.js if you want), source attached to this email.

In my sitemap, in the map:components section I have the following entry:

	map:flow-interpreters default=JavaScript/

Then I include a flow definition later in the sitemap:

map:flow language=javascript
map:script src=scripts/saveToFile.flow/
/map:flow
Which will cause Cocoon to load the flowscript and make it available for 
execution in pipelines. (Note: you may need a pipeline to source the 
scripts/*.flow files using a simple Cocoon reader.  I assume you know enough 
about cocoon to put that in place).

Then I have a pipeline that looks like this, to actually execute the 
flowscript and save the output of a particular pipeline:

map:pipeline
map:match pattern=saveFile.html
map:call function=saveToFile/
map:select type=request-attribute
map:parameter name=attribute-name 
value=centralPrint.status/
map:when test=success   
!-- Do something useful here, since the saveToFile 
succeeded --
.
/map:when
map:otherwise
map:read src=html/saveToFileFailed.html 
mime-type=text/html/
/map:otherwise
/map:select
/map:match
/map:pipeline
Then there is a pipeline that generates the actual output that you want to 
save, which in my example, is output.xml.  Note that the flowscript 
saveToFile.flow references output.xml, which is how it initiates execution of 
the following pipeline:

map:pipeline internal-only=true
map:match pattern=output.xml
map:generate type=file src=xml/input.xml/
map:transform src=xsl/myTransform.xsl/
map:serialize type=xml/
/map:match
/map:pipeline
Sowhen the user accesses a url of the form saveFile.html, Cocoon will 
execute the first pipeline above, which in turn calls the flowscript, which  
will then fire off the 2nd pipeline, and voila...your file is now saved in a 
temp directory with a unique name!  The filename that was generated for the 
save is returned in a request attribute called saveToFile.tempFile, so you 
can get it later in your pipeline if you need to along with a status 
attribute so you know if it succeeded or not.

Hope this helps!





Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
 



The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
   File information ---
File:  saveToFile.flow
Date:  5 Nov 2003, 11:55
Size:  1296 bytes.
Type:  Unknown

Re: [Woody-binding] wb:repeater unique-path

On Wed, 2003-11-05 at 18:51, Antonio Gallardo wrote:
 Hi:
 
 I am trying to do a form.save(bean) from an empty displayed form.I have
 2 days with this sample and still not working. :-(
 
 
 My problem is that inside the repeater there is only 1 value (res_id) of
 datatype integer.
 
 Binding just save the first 2 values and an empty repeater.

Is the res_id field a field that the user can edit? The current
repeater-binding assumes that new rows are those with an empty id field
(res_id your case). Thus if these are editable by the user and the user
puts a value in them, the repeater binding will not detect that these
are new rows.

However, it is of course possible to implement alternative
repeater-binding strategies. One that's also available is
wb:simple-repeater (see javadoc of the class
SimpleRepeaterJXPathBindingBuilder). This binding works by first
removing all items, and the adding all the items in the repeater.

If this approach is not acceptable for you, I think it is possible to
adjust the normal repeater binding so that it detects new id's as new
rows (instead of only null id's).

 
 BTW, A question why we need to define the unique-path attribute as
 @res_id AFAIK, a collection cannot have an attribute called res_id.
 Please explain. :-D

It is not an attribute of the collection, but of the individual objects
in the collection.

Hope this helps.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [Woody-binding] wb:repeater unique-path

On Wed, 2003-11-05 at 19:57, Bruno Dumon wrote:
 On Wed, 2003-11-05 at 18:51, Antonio Gallardo wrote:
  Hi:
  
  I am trying to do a form.save(bean) from an empty displayed form.I have
  2 days with this sample and still not working. :-(
  
  
  My problem is that inside the repeater there is only 1 value (res_id) of
  datatype integer.
  
  Binding just save the first 2 values and an empty repeater.
 
 Is the res_id field a field that the user can edit? The current
 repeater-binding assumes that new rows are those with an empty id field
 (res_id your case). Thus if these are editable by the user and the user
 puts a value in them, the repeater binding will not detect that these
 are new rows.
 
 However, it is of course possible to implement alternative
 repeater-binding strategies. One that's also available is
 wb:simple-repeater (see javadoc of the class
 SimpleRepeaterJXPathBindingBuilder). This binding works by first
 removing all items, and the adding all the items in the repeater.

After having a look at the source code, I'm afraid that binding
currently only works for XML documents.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: Saving pipeline output to a temp file...everything you wanted to know but were afraid to ask!

(moving the discussion to @dev)

Unico Hommes wrote:

snip/

Mmmh... careful here : you're relying on a unspecified behaviour that allows a flow script to not send a page. And we still have to decide if this allowed or not.
   

Better would be in this case to do in your saveToFile function:

function saveToFile() {
 
 ...

 cocoon.processPipelineTo(output.xml,{},fileInputStream);

 // redirect to the page to display
 cocoon.sendPage(success.html,{});
}
 

Exactly.

From my point of view, this should not be allowed. 
   

I now believe this is true.
 

Yep, with the help of an additional no content method on the response 
as discussed this afternoon.

But ...
 

And for this kind of purpose, I would better go for a flowscript-action that calls a script function that returns parameters to the sitemap but which is not allowed to create a continuation.
   

... why is that better than the above flow script? (I am not trying to be obstinate, I'm just trying to understand. :-)
 

Obstination shows the desire to understand ;-)

It's not better because of the actual JavaScript code, which would be 
more or less the same, but because of the sitemap semantics: map:call 
function and map:call continuation are meant to be final statements 
for the current sitemap execution and also are not meant to have some 
child statements whose executions could depend on the result of the call.

The sitemap statement that has these two semantics (not final with 
children) is map:act

That's why I'm suggesting an action of type flowscript that would call 
a function defined in the script files listed in map:flow and thus be 
able to share the session-global variables with map:call statements. 
Think of this action as a secondary controller in a MVC model (they 
fine-tune the view but don't change it radically), the map:call being 
the primary controller (it chooses the pipeline URI that fully defines 
the view).

WDYT?

Sylvain

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

Re: [Woody-binding] wb:repeater unique-path

2003-11-05 Thread Antonio Gallardo

Bruno Dumon dijo:
 On Wed, 2003-11-05 at 18:51, Antonio Gallardo wrote:
 Hi:

 I am trying to do a form.save(bean) from an empty displayed form.I
 have 2 days with this sample and still not working. :-(


 My problem is that inside the repeater there is only 1 value
 (res_id) of datatype integer.

 Binding just save the first 2 values and an empty repeater.

 Is the res_id field a field that the user can edit?

Yep. The subform has 2 fields:

res_id - The Foreign Key for a resouces of the application
rol_id - Foreign key to master in a master-detail relation.

So, we intend to allow the user to choose the resouces. That is the idea.

Also: The primary key are the 2 fields.

 The current repeater-binding assumes that new rows are those with
 an empty id field (res_id your case). Thus if these are editable
 by the user and the user puts a value in them, the repeater binding
 will not detect that these are new rows.

:-(

Damn! This is for sure the origin of my martyrdom. I am happy to discover
that at the end, this was not my fault. This is simply because it is not
implemented yet.

Often I prefer to try many times before write to the list. Maybe this is
not a good approach because I lose many time trying to do the imposible.
:-(

 However, it is of course possible to implement alternative
 repeater-binding strategies. One that's also available is
 wb:simple-repeater (see javadoc of the class
 SimpleRepeaterJXPathBindingBuilder). This binding works by first
 removing all items, and the adding all the items in the repeater.

OK. I will try this.

 If this approach is not acceptable for you, I think it is possible to
 adjust the normal repeater binding so that it detects new id's as new
 rows (instead of only null id's).

I think sometimes it is aceptable at all because there is no other approach:

The user iscreating a new document (master-detail at once) so Primary Keys
(PK) are not defined yet. So how I can give them a value. This is why they
are empty. Also will be empty in any case when you insert a new row for
the repeater.

I realize it is hard to separate the form from the DB while developing DB
applications, but I am trying

So in the Woody example, I think woody would be able to manage this type
of forms too.

 BTW, A question why we need to define the unique-path attribute as
 @res_id AFAIK, a collection cannot have an attribute called res_id.
 Please explain. :-D

 It is not an attribute of the collection, but of the individual objects
 in the collection.

Please explain where is this attribute stored. I don't defined it in my case.

 Hope this helps.

Of course and very much it helps! Many thanks. I am afraid I owe many
beers to you :-

Best Regards,

Antonio Gallardo

Re: stub approach with WSDL/SOAP on Cocoon

2003-11-05 Thread Daniel Fagerstrom

[EMAIL PROTECTED] wrote:
Hi to all,
first of all sorry for my bad English and for not so much clarity in post :-)
I'm currently doing a project using Cocoon 2.1.2 .

I'm trying to find an automated way to reuse components in a pipelne, like 
WebServiceProxyGenerator, to implement this flow:

- fetch a remote WSDL and parsing it
- construction of necessary logic to create machine-generated stub of SOAP 
methods contained
- in/out of method parameters and invocation thru XForms or something similar 
at presentation level.
- transformation of response in order to serialize and present it.
Do you mean that you want to build something like:
http://www.mindreef.net ?
I'm working on a prototype of something similar (although more 
primitive), that I hopefully will be able to submit in the next few days.

It is based on an enhancement to the SourceWritingTransformer that makes 
it possible to post XML (or whatever) to an URL, (see 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24402 for details). 
Then I have written a number of XSLT-scripts that basically takes a path 
to a WSDL document as input and creates a view of the services it 
offers, forms for calling the methods of it and rendering of the 
results, respectively.

Currently it is just a proof of concept, but the company I am working 
for is planning to package a lot of our web applications as web services 
as well, so I am definitively interested in developing a production 
quality tool set for using web services that are described in WSDL, from 
Cocoon.

/Daniel

Re: stub approach with WSDL/SOAP on Cocoon

Daniel Fagerstrom wrote:

[EMAIL PROTECTED] wrote:

Hi to all,
first of all sorry for my bad English and for not so much clarity in 
post :-)

I'm currently doing a project using Cocoon 2.1.2 .

I'm trying to find an automated way to reuse components in a pipelne, 
like WebServiceProxyGenerator, to implement this flow:

- fetch a remote WSDL and parsing it
- construction of necessary logic to create machine-generated stub 
of SOAP methods contained
- in/out of method parameters and invocation thru XForms or something 
similar at presentation level.
- transformation of response in order to serialize and present it.


Do you mean that you want to build something like:
http://www.mindreef.net ?
I'm working on a prototype of something similar (although more 
primitive), that I hopefully will be able to submit in the next few days.


Does it produce Woody forms? That would be awesome!!

Sylvain

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

Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]

On Wednesday, Nov 5, 2003, at 13:41 Europe/Rome, Vadim Gritsenko wrote:

Stefano Mazzocchi wrote:

On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote:

setStatus' friends the sendError brothers are also be eligible for 
FOM
membership. But this change has a dependency on the discussion about
bodyless responses since if you'd do a sendError from a flow script 
and
then send a page afterwards this would result in errors.


I dislikde sendError because, in fact, HTTP does not have the 
concept of errors, but only status codes and empty-payload responses.

In the future, it's entirely possible to have a 309 or equivalent 
that is not an error, but has a empty-payload response. I would 
dislike to call sendError() to send something that is not an error, 
feels hacky.

I think the optimal solution is:

 1) add response.setStatus() in FOM
 2) allow the flowscript to terminate without calling sendPage* [thus 
resulting in an empty payload]

Vote?


Before we vote: how to resolve flow actions issue then? There should 
be migration path for users who already have wrote an actions wtih 
flow.

(remember? you've said that actions should be replaced with flowscript 
;-)
You teaser ;-)

IMVHO, an action is an overlap of three concerns:

 1) processing logic external to the sitemap used to drive its flow
 2) processing logic external to the pipelines used to drive its 
creation
 3) processing logic used to update the external environment

A potential migration strategy is:

 1) should be done in the flow, either rewriting in javascript or 
refactoring the logic, moving it into an isolated component (either 
avalon or simple java class to instantiate from the flow)

 3) this should be refactored into a class or component

which leaves us with 2).

I've seen far too many actions that set parameters that are later used 
by selectors. This is WRONG!!! You should be writing a selector!!!

But at the very end, I think the issues at stake are orthogonal: Unico 
and I want a simple way to generate reponses with empty-payloads 
because this is going to be common for more complex uses of HTTP.

You propose to clone the ugly action-like sitemap semantics with 
flowscript logic.

The votes can happen independently.

]--
Stefano.

Re: cvs commit: cocoon-2.2/src/java/org/apache/cocoon/components/pipeline ProcessingPipeline.java AbstractProcessingPipeline.java

2003-11-05 Thread Geoff Howard

[EMAIL PROTECTED] wrote:

cziegeler2003/11/05 13:29:08

 Modified:src/java/org/apache/cocoon/components/treeprocessor
   InvokeContext.java
  src/java/org/apache/cocoon/components
   RequestLifestyleComponentHandler.java
   SitemapConfigurableAccessor.java
   RequestLifecycleHelper.java
   CocoonComponentManager.java CocoonContainer.java
  src/java/org/apache/cocoon/components/pipeline
   ProcessingPipeline.java
   AbstractProcessingPipeline.java
 Log:
 Readding methods for compatibility in CocoonComponentManager
 Fixing autorelease of components

 Making pipelines reserviceable

 Correting formatting and licence headers

 

Is this a step back towards ComponentManager, or a step forward toward 
Fortress?

Geoff

Woody and the ObjectModel

2003-11-05 Thread Joe Latty





I am trying to call a web service from within my 
Woody Script. 

The SOAP calls uses information in the session 
object to maintain state.

The SOAP controller takes (at present) the 
(Environment) ObjectModel as one of it's arguments, from this it obtains a 
referenceto the session object, this is so that the SOAPController can 
control the state management of the SOAP calls.

I am not sure how I can get a reference to the 
cocoon.environment.objectModel from within Woody, to pass in to the 
SOAPController. 

Passing cocoon.session to SOAPControllergives 
the following error:
Cannot 
convert 
[EMAIL PROTECTED] 
to org.apache.cocoon.environment.Session

Any help woody be 
appreciated.

Joe

Re: Saving pipeline output to a temp file...everything you wanted to know but were afraid to ask!

2003-11-05 Thread Andrzej Jan Taramina

dominik:

 I'm sorry to bother you, but I can't direcly subscribe to the mail list
 because of my company. you posted on the cocoon list:

No botherthe least I can do is to help out a fellow Cocoon afficionado, 
since I have received a lot of help myself.  Gotta pass on the karma when you 
can. ;-)

However, I will copy this reply to the list, in case anyone else there has a 
similar issue.  This way it will be in the archives for future reference or 
maybe someone will post it on the Cocoon Wiki? (hint...hint ;-)  ).

  Try SourceWritingTransformer from the sitemap or else
  cocoon.processPipelineTo from a flowscript.

 I decided to bite the bullet and add flowscript to my appit worked 
 perfectly!

 would you please be so kind and give me a short outline of this solution? I'm
 having a similar problem for weeks, but there was nothing is sight.

Sure thing.  Here is what I did (salient parts only...not a full working 
example):

I have a flowscript called saveToFile.flow (I call my flowscripts *.flow to 
distinguish them from normal client side javascripts, but you can call them 
*.js if you want), source attached to this email.

In my sitemap, in the map:components section I have the following entry:

map:flow-interpreters default=JavaScript/

Then I include a flow definition later in the sitemap:

map:flow language=javascript
map:script src=scripts/saveToFile.flow/
/map:flow

Which will cause Cocoon to load the flowscript and make it available for 
execution in pipelines. (Note: you may need a pipeline to source the 
scripts/*.flow files using a simple Cocoon reader.  I assume you know enough 
about cocoon to put that in place).

Then I have a pipeline that looks like this, to actually execute the 
flowscript and save the output of a particular pipeline:

map:pipeline
map:match pattern=saveFile.html
map:call function=saveToFile/
map:select type=request-attribute
map:parameter name=attribute-name 
value=centralPrint.status/
map:when test=success   
!-- Do something useful here, since the saveToFile 
succeeded --
.
/map:when
map:otherwise
map:read src=html/saveToFileFailed.html 
mime-type=text/html/
/map:otherwise
/map:select
/map:match
/map:pipeline

Then there is a pipeline that generates the actual output that you want to 
save, which in my example, is output.xml.  Note that the flowscript 
saveToFile.flow references output.xml, which is how it initiates execution of 
the following pipeline:

map:pipeline internal-only=true
map:match pattern=output.xml
map:generate type=file src=xml/input.xml/
map:transform src=xsl/myTransform.xsl/
map:serialize type=xml/
/map:match
/map:pipeline

Sowhen the user accesses a url of the form saveFile.html, Cocoon will 
execute the first pipeline above, which in turn calls the flowscript, which  
will then fire off the 2nd pipeline, and voila...your file is now saved in a 
temp directory with a unique name!  The filename that was generated for the 
save is returned in a request attribute called saveToFile.tempFile, so you 
can get it later in your pipeline if you need to along with a status 
attribute so you know if it succeeded or not.

Hope this helps!





Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

    File information ---
 File:  saveToFile.flow
 Date:  5 Nov 2003, 11:55
 Size:  1296 bytes.
 Type:  Unknown


saveToFile.flow
Description: Binary data

Re: RE: Re: [IMP] Performance Killer and Memory leak

2003-11-05 Thread volker . schmitt




 From: [EMAIL PROTECTED]

 If we remove the ComponentManagerProxy this problem is solved.

 I'm fine with removing the proxy, but can this problem be solved in the
 CocoonComponentManager instead? For example by making it aware of the
 proxy? Or by making it release the requestlifecyclecomponent via its
 originating component manager?

Yes I think this can be fixed but this doesn't fix the performance
decreasing if you lookup several components inside compose as it is done
for the InputModules inside the Cocoon Sitemap.

 It's just that we *do* have that code in there, and if you remove it,
 someone else will pipe up and say that oh, why oh why did you break
 my application?.

I think it is not a problem, because lookup components inside compose which
are not ThreadSafe and are not released inside dispose should not happen. I
never found such code inside Cocoon or other applications.

 So I'm trying to find a solution that will fix the problem (and it is
 a problem), byt leaves ECM intact.

ok, may be using a org.apache.commons.collections.MultiHashMap but anyway
my feeling is, for performance reason, we should remove the Proxy ;-)

/LS


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RE: Re: [IMP] Performance Killer and Memory leak