Re: [RT] Webdavapps with Cocoon

[Stefano Mazzocchi]

replying to both Gianugo and Marc in the same email for brevity.

On Friday, Jul 25, 2003, at 17:08 Europe/Rome, Marc Portier wrote:

Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:


Now Cocoon, in its present incarnation, is heavily biased by the 
"read-only" syndrome, and this makes IMO very hard to enter the 
WebDAV world. I see two serious areas where WebDAV support needs 
careful (re)thinking of core Cocoon patterns:
I think this applies also to more classic file-upload schemes?
Yes, it totally does. the way file-upload is handled today is just one 
aspect of a more general 'polishing outside-in flow of information' for 
cocoon.

(note I used the term "polishing" not "rethinking", see below why)

1) URI space decoupling being unreversable: while this is a *major* 
feature of Cocoon (and something that might help immensely when 
applied to a DAV environment: views on WebDAV would really kick ass, 
imagine presenting your XML files as virtual OpenOffice .sxw that are 
assembled /disassembled on the fly), the drawback is that, in most 
cases, it's impossible to work your way from the pipeline result to 
the single pieces that make that result happen. Even the simplest 
XSLT transformation can't be reversely applied, so now there is no 
way to understand how an resource should be treated in a symmetric 
way when requested or uploaded. Oh yes, you can
hm, do we really need to look at it as symmetric?
No, we don't. I've been thinking about this a lot and I think that 
symmetry is not only a holy grail, but it's the wrong grail to consider 
holy. Read on.

I know we are tempted to do so, but is it a must?
It is tempting, but symmetry-driven design is bad. we must understand 
what we want, why and what is limiting us.

Is it imposed by current webdav enabled editors?
It has been already said that webdav is the most under-hyped technology 
ever.

Microsoft said in the helloween documents that they pushed for webdav 
to be a supercomplex specification so that opensource wouldn't be able 
to implement it. Greg Stein (the current ASF chairmain, BTW) finished 
mod_dav in a few days disturbed by those documents (if you ever meet 
Greg, as him, is a pretty funny story and he's very proud of having 
done that [he worked for microsoft before])

As a result of this, Microsoft moved away from webdav (probably they 
thought it was not complex enough) and into web services (will the 
SOAP/WSDL/UDDI/BPEL4WS stack will be hard enough for OSS to catch up? 
hopefully we'll be smarter and just keep going with good old HTTP style 
WS).

As a result, webdav was (more or less) abandoned by the market. 
Subversion is the only use of webdav that goes behind saving a file on 
disk thru your web folder (which implementation sucks ass and I bet is 
not going to be better in the future, in favor of a SOAP-based document 
upload web service). Again, Greg Stein is behind the effort.

WebDAV is a very generic protocol (just like HTTP is) but people are 
influenced by implementations more than by the protocol design 
themselves. For example, almost everybody on the web believes that

 http://blah.com

and

 http://blah.com/

are the same URL just because all web clients will call

 HTTP/1.0 GET /

on both requests. But they don't know that

 http://blah.com/news

and

 http://blah.com/news/

are two different URL and it's the web server that (normally! but 
nobody ever specified this behavior anywhere!) translates the first 
into the second if the folder 'news' if found in the file system that 
mounts to that URL space.

Note that on a real FS, everybody knows the difference between

 /home/blah/news

and

 /home/blah/news/

because the OS enforces type checking on these (on a POSIX file system 
you cannot open a directory for writing as a file, for example).

The above weakness of URL space handling is the first thing that 
severely hurt the WebDAV world. [note: a bug in microsoft web folders 
eliminates the trailing slash from URL before sending the HTTP request, 
go figure! means that nobody in microsoft ever thought about 
webdav-editing the root of a folder (which is normally its index, or 
default content in ISS terms)]

Some say (ever Marc suggests) that the forcing of DAV to work all the 
actions on the same URL might be a reason for poor success, but I 
disagree because it doesn't take resource views into consideration.

If I have a resource like

 http://blah.com/news/

and I want to edit, I could ask for

 http://blah.com:/news/
 http://edit.blah.com/news/
 http://blah.com/news/?view="edit";
which are all 'orthogonal' ways of asking a different view of the same 
resource accessing it thru a parallel URL space (but with different 
behaviors)

I normally prefer the virtual-host approach. something like this

   [frontend] <- [repository] <- [backend]
 http://blah.com http://edit.blah.com
where frontend and backend are separated (frontend might even be a 
static representation of the saved content (say, created b

Re: [flow] forwardTo()

[Bruno Dumon]

On Tue, 2003-07-22 at 16:12, Marc Portier wrote:
> Hi all,
> 
> Trying to understand some more flow internals...
> 
> I just checked the FOM_Cocoon.java on how it handles the redirects...
> 
> and this seems to be the relevant portion:
> 
> String redUri = uri;
> if(! uri.startsWith( "cocoon://" ) ) {
>  redUri = "cocoon://" + this.environment.getURIPrefix() + uri;
> }
> 

actually that's how the forwardTo(uri, object, Continuation) method does
it.

forwardTo(uri, object, FOM_WebContinuation) always inserts cocoon:// +
getURIPrefix, regardless of whether the URI already starts with
cocoon://


> 
> 1/ do we explicitely want to prohibit the usage of ANY valid uri
> to redirect to?
> 
> I guess that http://whatever-uri should be able to work as well,
> no?  Maybe we should just be checking for the presence of a
> 'scheme' part in the URI?

Don't know. We got a redirectTo method for that.

> (and even if we don't want to have client-side-redirect uri's
> ripple through then we should at least check and warn accordingly?)

agreed

> 2/ when selecting a sitemap-pipeline do we explicitely want to
> have everything resolved versus the top level sitemap?
> 
> if we would just append 'cocoon:/' (ONE slash) then the
> flow-writer can control if he wants to select relative to the
> current sitemap or relative to the root sitemap (by letting his
> uri start with a '/' or not)
> 
> sendPageAndWait('localmap/uri-part');
>  --> cocoon:/localmap/uri-part
> sendPageAndWait('/topmap/whatever);
>  --> cocoon://topmap/whatever

Makes sense. This could change existing behaviour if people already used
/ at the beginning of the path, but I think that will rarely be the case
and is a change we can still afford now.

> 3/ is this behaviour a general property of 'flow' or is it 
> specific to how the JSInterpreter handles things?
> 
> personally I think we can tackle this on the level of the
> AbstractInterpreter so this line of thinking becomes available to 
> all flow implementations?

I agree.

> if all 3 comments make sense the following could become the new
> implementation of AbstractInterpreter.forwardTo() (and we could 
> offload the burdon from the current implementations)
> 
> 
> 
> import org.apache.excalibur.source.SourceUtil;
> 
> 
> public void forwardTo(String uri, Object bizData,
>  WebContinuation continuation,
>  Environment environment)
>throws Exception
> {
>if (SourceUtil.indexOfSchemeColon(uri) == -1) {
>uri = "cocoon:/" + uri;
>}
> 
>Map objectModel = environment.getObjectModel();
>FlowHelper.setContextObject(objectModel, bizData);
>FlowHelper.setWebContinuation(objectModel, continuation);
>PipelinesNode.getRedirector(environment)
> .redirect(false, uri);
> }
> 
> 
> 
> what do others think?

I would forbid the use of schemes completely (i.e. throw an exception if
the uri contains a scheme), and prepend cocoon:/ (one slash).

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

DO NOT REPLY [Bug 21925] New: - FOM Request object does not provide access to all the request's values

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925

FOM Request object does not provide access to all the request's values

   Summary: FOM Request object does not provide access to all the
request's values
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The following methods seem to be missing from FOM_Request:

getServerName
getScheme
getServerPort
getRemoteAddr

DO NOT REPLY [Bug 21925] - FOM Request object does not provide access to all the request's values

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925

FOM Request object does not provide access to all the request's values





--- Additional Comments From [EMAIL PROTECTED]  2003-07-28 10:00 ---
Created an attachment (id=7540)
Provide the missing methos

Re: Release on tuesday?

[Stefano Mazzocchi]

On Sunday, Jul 27, 2003, at 15:04 Europe/Rome, Andreas Kuckartz wrote:

Carsten Ziegeler wrote:

I want to make the 2.1rc1 release on tuesday. I haven't followed
the list this week very closely, but it seems that there are no
outstanding issues. Did I oversee something?
No. The vote on the sitemap changes for the pluggable flow 
implementation is lagging behind, I think it's better if we freeze the 
contract now and change it later for Cocoon 2.2, right now it feels 
like there is too many issues on the table.

I don't want to modify it now and then have to modify it yet again in 
the future.

Bugzilla contains 117 unresolved issues.
Point me to *one* project that releases only when there are no 
unresoved issues, Andreas.

--
Stefano.

Re: Release on tuesday?

[Antonio Gallardo]

Stefano Mazzocchi dijo:
>
> On Sunday, Jul 27, 2003, at 15:04 Europe/Rome, Andreas Kuckartz wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> I want to make the 2.1rc1 release on tuesday. I haven't followed the
>>> list this week very closely, but it seems that there are no
>>> outstanding issues. Did I oversee something?
>
> No. The vote on the sitemap changes for the pluggable flow
> implementation is lagging behind, I think it's better if we freeze the
> contract now and change it later for Cocoon 2.2, right now it feels
> like there is too many issues on the table.
>
> I don't want to modify it now and then have to modify it yet again in
> the future.

Good choice. Flow can continue his development in the "underground". :)

But once it is finish we need a release. Flow is a big step ahead! As you
sugested it can be 2.2

>
>> Bugzilla contains 117 unresolved issues.
>
> Point me to *one* project that releases only when there are no
> unresoved issues, Andreas.

Windows. lol. :)

Antonio Gallardo

DO NOT REPLY [Bug 21931] New: - [PATCH] LDAPTransformer filter element as sitemap parameter

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21931

[PATCH] LDAPTransformer filter element as sitemap parameter

   Summary: [PATCH] LDAPTransformer filter element as sitemap
parameter
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Many elements of LDAPTransformer can already be specified as sitemap parameters.
Not the filter element however. This patch adds that functionality.

DO NOT REPLY [Bug 21931] - [PATCH] LDAPTransformer filter element as sitemap parameter

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21931

[PATCH] LDAPTransformer filter element as sitemap parameter





--- Additional Comments From [EMAIL PROTECTED]  2003-07-28 11:00 ---
Created an attachment (id=7541)
unified diff for LDAPTransformer.java

NPE after portal-fw samples sitemap reload

[Unico Hommes]

Whenever reloading the portal-fw samples-fw sitemap. I'm seeing the
following NullPointerException:

java.lang.NullPointerException
at
org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedC
omponentSelector.java:317)
at
org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.dispose(Se
lectNode.java:169)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.disposeTree(Tre
eProcessor.java:472)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.setupRootNode(T
reeProcessor.java:422)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:319)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:307)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun
tNode.java:133)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:84)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i
nvoke(PreparableMatchNode.java:164)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P
ipelineNode.java:164)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(
PipelinesNode.java:161)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:325)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:307)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun
tNode.java:133)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:84)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i
nvoke(PreparableMatchNode.java:164)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P
ipelineNode.java:164)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(
PipelinesNode.java:161)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:325)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:307)
at org.apache.cocoon.Cocoon.process(Cocoon.java:621)

Would an additional null check suffice or is this a symptom of a
different problem?

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom FOM_Cocoon.java

[bruno]

bruno   2003/07/28 04:07:31

  Modified:src/java/org/apache/cocoon/components/flow/javascript/fom
FOM_Cocoon.java
  Log:
  Added methods getServerName, getScheme, getServerPort, getRemoteAddr to FOM_Request
  (Patch 21925 by Ugo Cei)
  
  Revision  ChangesPath
  1.7   +17 -1 
cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java
  
  Index: FOM_Cocoon.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- FOM_Cocoon.java   21 Jul 2003 23:13:01 -  1.6
  +++ FOM_Cocoon.java   28 Jul 2003 11:07:31 -  1.7
  @@ -362,6 +362,22 @@
   public String jsFunction_getProtocol() {
   return request.getProtocol();
   }
  +
  +public String jsFunction_getServerName() {
  +return request.getServerName();
  +}
  +
  +public String jsFunction_getRemoteAddr() {
  +return request.getRemoteAddr();
  +}
  +
  +public int jsFunction_getServerPort() {
  +return request.getServerPort();
  +}
  +
  +public String jsFunction_getScheme() {
  +return request.getScheme();
  +}
   }
   
   public static class FOM_Cookie extends ScriptableObject {
  
  
  

DO NOT REPLY [Bug 21925] - FOM Request object does not provide access to all the request's values

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925

FOM Request object does not provide access to all the request's values





--- Additional Comments From [EMAIL PROTECTED]  2003-07-28 11:15 ---
Thanks, I applied your patch.

>From a quick count of the methods here:
http://wiki.cocoondev.org/Wiki.jsp?page=FOM_request
(or src/documentation/xdocs/userdocs/flow/api.xml)

and the methods present in the FOM_Request class, it seems there are still a few
others missing. If you'd happen to have some time to do those as well, then a
patch is very welcome.

cvs commit: cocoon-2.1 status.xml

[gianugo]

gianugo 2003/07/28 04:28:22

  Modified:src/java/org/apache/cocoon/transformation
SourceWritingTransformer.java
   src/documentation/xdocs/userdocs/transformers
sourcewriting-transformer.xml
   .status.xml
  Log:
  Added delete capabilities to the SourceWritingTransformer, while solving
  a DOM bug(?) with new documents creation.
  
  Revision  ChangesPath
  1.5   +77 -9 
cocoon-2.1/src/java/org/apache/cocoon/transformation/SourceWritingTransformer.java
  
  Index: SourceWritingTransformer.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/transformation/SourceWritingTransformer.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- SourceWritingTransformer.java 16 Mar 2003 17:49:15 -  1.4
  +++ SourceWritingTransformer.java 28 Jul 2003 11:28:20 -  1.5
  @@ -110,6 +110,12 @@
* [Optional] The XPath (relative to 
) to backup the overwritten node to - 
eg: "foo/versions" or "/doc/versions/foo". NOTE: If specified and a node is replaced, 
all children of this replaced node will be reinserted at the given path.
* The XML Fragment to be 
written - eg: "" or "" 
etc.
* 
  + * 
  + *  - deletes an existing asset.
  + * The System ID of the asset to be 
deleted - eg: "docs/blah.xml" or "context://blah.xml" etc.
  + * [Ignored] XPath to specify how your content is 
wrapped
  + * [Ignored]The XML Fragment to be 
written 
  + * 
* 
*
*
  @@ -248,6 +254,7 @@
*
* @author mailto:[EMAIL PROTECTED]">Carsten Ziegeler
* @author mailto:[EMAIL PROTECTED]">Jeremy Quinn
  + * @author mailto:[EMAIL PROTECTED]">Gianugo Rabellino
* @version CVS $Id$
*/
   public class SourceWritingTransformer
  @@ -262,6 +269,7 @@
   public static final String PATH_ELEMENT = "path";
   public static final String FRAGMENT_ELEMENT = "fragment";
   public static final String REPLACE_ELEMENT = "replace";
  +public static final String DELETE_ELEMENT = "delete";
   public static final String SOURCE_ELEMENT = "source";
   public static final String REINSERT_ELEMENT = "reinsert";
   /** outgoing elements */
  @@ -281,6 +289,7 @@
   public static final String ACTION_NONE = "none";
   public static final String ACTION_NEW = "new";
   public static final String ACTION_OVER = "overwritten";
  +public static final String ACTION_DELETE = "deleted";
   /** The current state */
   private static final int STATE_OUTSIDE  = 0;
   private static final int STATE_INSERT   = 1;
  @@ -290,6 +299,7 @@
   private static final int STATE_FILE = 6;
   private static final int STATE_REINSERT = 7;
   private static final int STATE_WRITE= 8;
  +private static final int STATE_DELETE = 9;
   private int state;
   private int parent_state;
   
  @@ -366,15 +376,20 @@
   this.stack.push(attr.getValue(SERIALIZER_ATTRIBUTE));
   this.stack.push("END");
   
  +// Element: delete
  +} else if (this.state == STATE_OUTSIDE && name.equals(DELETE_ELEMENT)) {
  +this.state = STATE_DELETE;
  +this.parent_state = state;
  +this.stack.push("END");
   // Element: file
   } else if (name.equals(SOURCE_ELEMENT)
  -   && (this.state == STATE_INSERT || this.state == STATE_WRITE)) {
  +   && (this.state == STATE_INSERT || this.state == STATE_WRITE || 
this.state == STATE_DELETE)) {
   this.state = STATE_FILE;
   this.startTextRecording();
   
   // Element: path
   } else if (name.equals(PATH_ELEMENT)
  -   && (this.state == STATE_INSERT || this.state == STATE_WRITE)) {
  +   && (this.state == STATE_INSERT || this.state == STATE_WRITE || 
this.state == STATE_DELETE)) {
   this.state = STATE_PATH;
   this.startTextRecording();
   
  @@ -386,7 +401,7 @@
   
   // Element: fragment
   } else if (name.equals(FRAGMENT_ELEMENT)
  -   &&  (this.state == STATE_INSERT || this.state == STATE_WRITE)) {
  +   &&  (this.state == STATE_INSERT || this.state == STATE_WRITE || 
this.state == STATE_DELETE)) {
   this.state = STATE_FRAGMENT;
   this.startRecording();
   
  @@ -466,6 +481,22 @@
   
   this.state = STATE_OUTSIDE;
   
  +// Element: delete
  +} else if (name.equals(DELETE_ELEMENT) && this.state == STATE_DELETE) {
  +S

Re: Release on tuesday?

[Geoff Howard]

Stefano Mazzocchi wrote:
On Sunday, Jul 27, 2003, at 15:04 Europe/Rome, Andreas Kuckartz wrote:

Carsten Ziegeler wrote:

I want to make the 2.1rc1 release on tuesday. I haven't followed
the list this week very closely, but it seems that there are no
outstanding issues. Did I oversee something?
No. The vote on the sitemap changes for the pluggable flow 
implementation is lagging behind, I think it's better if we freeze the 
contract now and change it later for Cocoon 2.2, right now it feels like 
there is too many issues on the table.
I thought that discussion ended with an agreement to release as is 
(exactly as you say) and revisit after release.  Reinhard was going out 
of town and asked me if I would follow up on the discussion with a vote 
but it seemed to have been resolved - maybe I dropped the ball?

Geoff

Re: Release on tuesday?

[Andreas Kuckartz]

Carsten wrote:

>> it seems that there are no outstanding issues.
>> Did I oversee something?

Andreas (myself) wrote:

> > Bugzilla contains 117 unresolved issues.

Stefano wrote:

> Point me to *one* project that releases only when there are no
> unresoved issues, Andreas.

"Resolved" does not necessarily imply "fixed". I simply do not know how
severe each of these 117 issues is.

And, yes, I know several proprietary software projects in which all open
issues are resolved before the software is released. And even if I did not
know *one* such project, that would not change my mind - why should it?

If Carsten decides that none of these open issues is severe enough to block
the release that would be ok with me.

Cheers,
Andreas

Re: Release on tuesday?

[Steven Noels]

On 27/07/2003 14:57 Carsten Ziegeler wrote:

I want to make the 2.1rc1 release on tuesday. I haven't followed
the list this week very closely, but it seems that there are no
outstanding issues. Did I oversee something?
If not, we will finally release the long awaited version this week.
Let's go for it!


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Re: cvs commit: cocoon-2.1 status.xml

[Geoff Howard]

[EMAIL PROTECTED] wrote:
gianugo 2003/07/28 04:28:22

  Modified:src/java/org/apache/cocoon/transformation
SourceWritingTransformer.java
   src/documentation/xdocs/userdocs/transformers
sourcewriting-transformer.xml
   .status.xml
  Log:
  Added delete capabilities to the SourceWritingTransformer, while solving
  a DOM bug(?) with new documents creation.
  
  Revision  ChangesPath
  1.5   +77 -9 cocoon-2.1/src/java/org/apache/cocoon/transformation/SourceWritingTransformer.java
...

  @@ -647,7 +706,7 @@
   // import the fragment
   Node importNode = resource.importNode(fragment, true);
   if ( path.equals("") ) {  // this is allowed in write
  -resource.appendChild(importNode);
  +resource.appendChild(importNode.getFirstChild());
   message = "entire source overwritten";
Was this bit the DOM "bug"?  Was it caused by whitespace outside root 
node when overwriting the whole document?  There was some discussion 
about 9 months ago where some (at least one) thought that was mandatory 
behavior and the responsibility of the fragment author (or pipeline) to 
remove whitespace.

If you've changed that behavior I'm personally very +1 but it may be 
worth a discussion.

Geoff

RE: Release on tuesday?

[Carsten Ziegeler]

Andreas Kuckartz wrote:
> 
> If Carsten decides that none of these open issues is severe 
> enough to block
> the release that would be ok with me.
> 
It's not me who decides this, we all ( the community ) decide it.
By sending mails like these I only remind everyone to see if there are
blocking issues. If none pops up (= if noone says so), it means
we (not only I) are not aware of any issues that really have to be
solved before the release.

But the great part of doing the releases is, when something goes wrong,
everyone knows who to blame... ;)

Carsten

Re: cvs commit: cocoon-2.1 status.xml

[Gianugo Rabellino]

Geoff Howard wrote:

  @@ -647,7 +706,7 @@
   // import the fragment
   Node importNode = resource.importNode(fragment, true);
   if ( path.equals("") ) {  // this is allowed in write
  -resource.appendChild(importNode);
  +resource.appendChild(importNode.getFirstChild());
   message = "entire source overwritten";


Was this bit the DOM "bug"?  Was it caused by whitespace outside root 
node when overwriting the whole document?  There was some discussion 
about 9 months ago where some (at least one) thought that was mandatory 
behavior and the responsibility of the fragment author (or pipeline) to 
remove whitespace.

If you've changed that behavior I'm personally very +1 but it may be 
worth a discussion.
I don't think it's a matter of whitespace. I'm not a DOM guru, but if 
the firstChild is a whitespace node it should be returned by the 
getFistChild() call as well. Actually, I am a bit puzzled too, since the 
SWT wasn't working on my setup but it was on others (I suspect it has to 
do with the latest JVM that I'm using), no matter what sample documents 
I gave to him. With this one liner, everything was working OK, so I just 
thought to change it. But I'm more than open to any discussion. :-)

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: Release on tuesday?

[Sylvain Wallez]

Stefano Mazzocchi wrote:

On Sunday, Jul 27, 2003, at 15:04 Europe/Rome, Andreas Kuckartz wrote:

Carsten Ziegeler wrote:

I want to make the 2.1rc1 release on tuesday. I haven't followed the 
list this week very closely, but it seems that there are no 
outstanding issues. Did I oversee something?

+1. Release the baby ;-)

No. The vote on the sitemap changes for the pluggable flow 
implementation is lagging behind, I think it's better if we freeze the 
contract now and change it later for Cocoon 2.2, right now it feels 
like there is too many issues on the table.

I don't want to modify it now and then have to modify it yet again in 
the future. 


Exactly. We need more thinking before knowing exactly _what_ to vote on. 
And if changes are to be done, let's do them only once and provide a 
backwards-compatible mode with the current state if needed.

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: [RT] Webdavapps with Cocoon

[Sylvain Wallez]

Stefano Mazzocchi wrote:

On Friday, Jul 25, 2003, at 11:44 Europe/Rome, [EMAIL PROTECTED] wrote:


"Europe/Rome" : Stefano is ba-a-ack !

Inspired by an email of Michael Homeijer 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103483890724049&w=2 
I created a first version of a DAVmap, a sitemap serving as a WebDAV 
server.

If you extract the zip file to /samples/webdav, you 
can mount http://localhost:/samples/webdav/davmap/repo as a 
webfolder.

I tested it with Windows Explorer on win2k, with XML Spy, an 
application build on the Slide WebDAV client library and the 
WebDAVSource (yes, that means you can use Cocoon as its own WebDAV 
repository :-) 

Way cool, Guido !

But the bad thing about WebDAV on Windoze (aka "webfolders") is that 
it's not a real filesystem : you cannot open the file directly from 
there, but only copy/paste it on a "real" filesystem. Or did I missed 
something ?

As this again is based on Cocoon's source resolving you could expose 
your CVS repository via Sylvain's CVSSource or a Xindice Database 
(given someone implements TraversableSource and maybe 
ModifiableSource in XMLDBSource). You could even integrate some data 
of a SQL table or just proxy another WebDAV server (to leverage its 
versioning or to plugin some workflow logic). 

Quick update about the CVSSource : I did a major rewrite for one of our 
projects (Gianugo : it's a CMS using dynamically-generated sxw files to 
edit content!), and it's now an Excalibur Source and supports crawling 
the version history (only on the main branch), tagging, cache validity, 
etc. I committed this new version this morning on cocoondev.org.

What's to be done now is handling branches and move to Eclipse's CVS 
client library in order to migrate into Cocoon's CVS (it currently uses 
JCVS's client library which is LGPL'ed).



I would love to see cocoon becoming a framework that can glue together 
everything on the web, from stateless publishing from stateful webdav 
applications and yeah, why not, once you can do webdav applications 
you can do SOAP applications or XML-RPC applications, they are, more 
or less, all XMLoverHTTP stuff.

Now, is the sitemap ready for this?

No, it needs a new concept. Something I've been calling "extractor": a 
component that is able to extract information from a pipeline and make 
it available to the sitemap for further selection of components.

why? because both WebDAV and SOAP have the terrible attitude of 
storing pipeline-routing information *inside* the pipeline.

It has been proposed in the past to allow selectors to have access to 
the pipeline, but I like the idea of "extractors" more. 


Mmmh... "extractor" or pipeline-aware selectors somewhat imply a single 
processing pipeline. Where does the flow fit in this ? What about 
handling this kind of request by a flowscript that would call an input 
pipeline (term introduced by Daniel Fagerstrom) that would extract the 
meat from the incoming stream (e.g. build a bean/hashmap/woody 
form/whatever from its content), and then call a regular response 
pipeline after having processed  the incoming data ?

In other words, streamed requests aren't so much different from regular 
requests : it's just that incoming data is more complex and that 
decoding is not handled transparently by the servlet engine. Once 
decoded, the processing model can be the same as usual.

What do you think ?

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: [RT] Webdavapps with Cocoon

[TREGAN Fabien]

Title: RE: [RT] Webdavapps with Cocoon





> But the bad thing about WebDAV on Windoze (aka "webfolders") is that 
> it's not a real filesystem : you cannot open the file directly from 
> there, but only copy/paste it on a "real" filesystem. Or did I missed 
> something ?


-Shell extensions exists that allow you to mount webdav adresses in your namespace (i've only tested commercial ones, but it was a year ago, some free one may have appeared since)

-Some window app (Office, Epic 4.3, ...) are webdav aware.


But, indeed, the "webfolders jumble" alone can't be considered as a filesystem.



f.

Re: processing flow for

[Sylvain Wallez]

Joerg Heinicke wrote:

(Moving this discussion to dev list because it implies an more or less 
important change - wanted or not.)

The problem: Does the processing return to a calling pipeline after 
?

The docu at 
http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#Calling+resources 
and http://wiki.cocoondev.org/Wiki.jsp?page=Resources says no (to 
whatever reasons). But I saw Marc's example at 
http://wiki.cocoondev.org/Wiki.jsp?page=CleanerSiteMapsThroughResources 
and he tested it again and it worked, i.e. the processing flow *does* 
return to the calling pipeline.

Is this change implied? What were the pros and contras of this 
behaviour? I only know the old behaviour and, yes, the return makes 
the sitemap pipeline snippets more flexible. And who updates the docu ;-)

Can anybody say something about it?


Yes : the culprit is me ;-)

The compiled sitemap engine enforced the "doesn't return" feature. When 
writing the interpreted engine (the only one available in 2.1), I 
introduced a "bug" which was causing resources to return if the 
processing wasn't terminated. As resources were meant to close the 
pipeline, this made no difference... until the day where someone forgot 
to close it and discovered we could return from resources.

So we can consider resources as "gosub" and no more "goto" as stated in 
the doc. Moreover, since resources can be passed parameters, they are 
actually functions ! I can't remember if a formal vote occured on this, 
but people globally found this feature usefull.

Time to update the docs...

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

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor DefaultTreeBuilder.java TreeProcessor.java TreeBuilder.java

[cziegeler]

cziegeler2003/07/28 05:55:45

  Modified:src/java/org/apache/cocoon/components/treeprocessor
DefaultTreeBuilder.java TreeProcessor.java
TreeBuilder.java
  Log:
  Fixing wrong component manager usage
  
  Revision  ChangesPath
  1.2   +8 -1  
cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/DefaultTreeBuilder.java
  
  Index: DefaultTreeBuilder.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/DefaultTreeBuilder.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- DefaultTreeBuilder.java   9 Mar 2003 00:09:15 -   1.1
  +++ DefaultTreeBuilder.java   28 Jul 2003 12:55:45 -  1.2
  @@ -454,6 +454,13 @@
   }
   
   /**
  + * Return the sitemap component manager
  + */
  +public ComponentManager getSitemapComponentManager() {
  +return this.manager;
  +}
  +
  +/**
* Setup a ProcessingNode by setting its location, calling all
* the lifecycle interfaces it implements and giving it the parameter map if
* it's a ParameterizableNode.
  
  
  
  1.7   +8 -3  
cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/TreeProcessor.java
  
  Index: TreeProcessor.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/TreeProcessor.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- TreeProcessor.java6 Jul 2003 11:44:30 -   1.6
  +++ TreeProcessor.java28 Jul 2003 12:55:45 -  1.7
  @@ -157,6 +157,9 @@
   /** The different sitemap component configurations */
   protected Map sitemapComponentConfigurations;
   
  +/** The component manager for the sitemap */
  +protected ComponentManager sitemapComponentManager;
  +
   /**
* Create a TreeProcessor.
*/
  @@ -320,7 +323,7 @@
   }
   
   // and now process
  -CocoonComponentManager.enterEnvironment(environment, this.manager, this);
  +CocoonComponentManager.enterEnvironment(environment, 
this.sitemapComponentManager, this);
   try {
   return this.rootNode.invoke(environment, context);
   } finally {
  @@ -339,7 +342,7 @@
   
   context.enableLogging(getLogger());
   
  -CocoonComponentManager.enterEnvironment(environment, this.manager, this);
  +CocoonComponentManager.enterEnvironment(environment, 
this.sitemapComponentManager, this);
   try {
   if ( process(environment, context) ) {
   return context.getProcessingPipeline();
  @@ -438,6 +441,8 @@
   }
   root = builder.build(this.source);
   
  +this.sitemapComponentManager = builder.getSitemapComponentManager();
  +
   this.disposableNodes = builder.getDisposableNodes();
   } finally {
   this.builderSelector.release(builder);
  
  
  
  1.2   +7 -1  
cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/TreeBuilder.java
  
  Index: TreeBuilder.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/TreeBuilder.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- TreeBuilder.java  9 Mar 2003 00:09:18 -   1.1
  +++ TreeBuilder.java  28 Jul 2003 12:55:45 -  1.2
  @@ -51,6 +51,7 @@
   package org.apache.cocoon.components.treeprocessor;
   
   import org.apache.avalon.framework.component.Component;
  +import org.apache.avalon.framework.component.ComponentManager;
   import org.apache.avalon.framework.configuration.Configuration;
   import org.apache.avalon.framework.configuration.ConfigurationException;
   import org.apache.excalibur.source.Source;
  @@ -133,4 +134,9 @@
* @throws ConfigurationException if the default type could not be found.
*/
   String getTypeForStatement(Configuration statement, String role) throws 
ConfigurationException;
  +
  +/**
  + * Return the sitemap component manager
  + */
  +ComponentManager getSitemapComponentManager();
   }
  
  
  

DO NOT REPLY [Bug 21925] - FOM Request object does not provide access to all the request's values

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925

FOM Request object does not provide access to all the request's values





--- Additional Comments From [EMAIL PROTECTED]  2003-07-28 13:15 ---
I'll try to add the missing methods tonight. I'd also like to bring the API docs
up to date. Shouldn't there be an IDL file somewhere to fill? I can't seem to
find it.

Re: NPE after portal-fw samples sitemap reload

[Joerg Heinicke]

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

If this occurs as often as written by Alfred ("I get an NPE in 
ECS.release always for the first request after touching the sub-
sitemap"), we maybe have the blocking issue for the release.

Joerg

Unico Hommes wrote:
Whenever reloading the portal-fw samples-fw sitemap. I'm seeing the
following NullPointerException:
java.lang.NullPointerException
at
org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedC
omponentSelector.java:317)
at
org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.dispose(Se
lectNode.java:169)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.disposeTree(Tre
eProcessor.java:472)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.setupRootNode(T
reeProcessor.java:422)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:319)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:307)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun
tNode.java:133)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:84)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i
nvoke(PreparableMatchNode.java:164)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P
ipelineNode.java:164)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(
PipelinesNode.java:161)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:325)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:307)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun
tNode.java:133)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:84)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i
nvoke(PreparableMatchNode.java:164)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P
ipelineNode.java:164)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(
PipelinesNode.java:161)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:325)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:307)
at org.apache.cocoon.Cocoon.process(Cocoon.java:621)
Would an additional null check suffice or is this a symptom of a
different problem?

Cocoon and OJB with JDO.

[Antonio Gallardo]

Hi Cocooners!

I am currently working trying to use OJB with Cocoon. I already wrote a
simple example and I invite you to see it at wiki. :=)

http://wiki.cocoondev.org/Wiki.jsp?page=OJBWithJDO

Please note this is a first attempt to use an alternative project to
Hibernate. I choosed OJB because it is under the Apache umbrella. This
simple fact will allow us to integrate it in Cocoon. The problem with
Hibernate it the LPGL. :(

My idea is that we can build a OJB block and make the life easier for
people building database webapp. this block can be easily used with Flow.
I am looking for it.

The OJB can be used as the "model" of the MVC design paradigm. Currently
we are working in the Controller, called "Flow". An for the View we have 2
candidates Woody and JXForms.

I will keep working on this stuff and post to the list the results of that.

Of course, I am not too smart ;)
I need to thanks to Ricardo Rocha for the advise:

  "Forget XSP and check JDO"

Best Regards,

Antonio Gallardo.

Re: [RT] Webdavapps with Cocoon

[Marc Portier]

Stefano Mazzocchi wrote:
replying to both Gianugo and Marc in the same email for brevity.

On Friday, Jul 25, 2003, at 17:08 Europe/Rome, Marc Portier wrote:

Gianugo Rabellino wrote:

Stefano Mazzocchi wrote:




1) URI space decoupling being unreversable: while this is a *major* 
feature of Cocoon (and something that might help immensely when 
applied to a DAV environment: views on WebDAV would really kick ass, 
imagine presenting your XML files as virtual OpenOffice .sxw that are 
assembled /disassembled on the fly), the drawback is that, in most 
cases, it's impossible to work your way from the pipeline result to 
the single pieces that make that result happen. Even the simplest 
XSLT transformation can't be reversely applied, so now there is no 
way to understand how an resource should be treated in a symmetric 
way when requested or uploaded. Oh yes, you can


hm, do we really need to look at it as symmetric?


No, we don't. I've been thinking about this a lot and I think that 
I haven't really yet, I just jotted down my immediate 
associations with a topic that very naturally appealed to what I 
consider 'common sense dreaming' :-)

your more elaborate version of this RT proves that your thoughts 
are more mature and I agree with most of everything... just some 
questions/comments in line here and there

symmetry is not only a holy grail, but it's the wrong grail to consider 
holy. Read on.

I know we are tempted to do so, but is it a must?


It is tempting, but symmetry-driven design is bad. we must understand 
what we want, why and what is limiting us.

Is it imposed by current webdav enabled editors?


It has been already said that webdav is the most under-hyped technology 
ever.



WebDAV is a very generic protocol (just like HTTP is) but people are 
influenced by implementations more than by the protocol design 
themselves. For example, almost everybody on the web believes that

+1000, very true (helas this reality applies to a lot of things)


topic="clear explanation of the common (mis)understanding of the 
trailing / in URL's"
on-the-side="starting some wild thoughts on my side about 
designing flow-directed URI's"/>

The above weakness of URL space handling is the first thing that 
severely hurt the WebDAV world. [note: a bug in microsoft web folders 
eliminates the trailing slash from URL before sending the HTTP request, 
go figure! means that nobody in microsoft ever thought about 
webdav-editing the root of a folder (which is normally its index, or 
default content in ISS terms)]

Some say (ever Marc suggests) that the forcing of DAV to work all the 
actions on the same URL might be a reason for poor success, but I 
disagree because it doesn't take resource views into consideration.

If I have a resource like

 http://blah.com/news/

and I want to edit, I could ask for

 http://blah.com:/news/
 http://edit.blah.com/news/
 http://blah.com/news/?view="edit";
which are all 'orthogonal' ways of asking a different view of the same 
resource accessing it thru a parallel URL space (but with different 
behaviors)

I like this

recognise some of my immature idea of separate URI-spaces but 
this is a clean step further... (not separate per request-method, 
but separate by intent/purpose/role/view)

the only thing I am still strugling with is if there could be an 
automatic way for the clients to know about these other URI's?

I mentioned the possible use of PROPFIND somwhere down the line 
for communicating READ-ONLY state, in this light this could be 
extended to having a property that describes the URL or 'view' to 
get into editing? (or at least a url to a linkbase that mentiones 
the different allowed view-modes, their role and their URL?)

on the web-page side of thinks I guess there would just be an 
'edit' link on the page?

I normally prefer the virtual-host approach. something like this

   [frontend] <- [repository] <- [backend]
 http://blah.com http://edit.blah.com
where frontend and backend are separated (frontend might even be a 
static representation of the saved content (say, created by a cronned 
forrest every hour or so).

The above setup removes you from the need from having to be symmetric.

yep, it draws better on the reality that creation-publication is 
not a two-way street:

ie not
   creation >
user   <>system-uri
   < publication
but rather
--> creation-uri  --
  / \
  user  v
   ^  'system'
\  /
  --publication-uri  --
(they want to put back where they got I assume?)

actually if you look at the combination of 
matchers/request-method-selector you wrote up it more looks like the 
request-method being part of the uri-request space almost?


I dislike this. the action should not be encoded in the URI space.

I think we're saying the same...

meaning: I have to admit request-params and hostname are better 
p

Re: [RT] Webdavapps with Cocoon

[Stefano Mazzocchi]

On Monday, Jul 28, 2003, at 14:23 Europe/Rome, Sylvain Wallez wrote:

Stefano Mazzocchi wrote:

On Friday, Jul 25, 2003, at 11:44 Europe/Rome, [EMAIL PROTECTED] 
wrote:
"Europe/Rome" : Stefano is ba-a-ack !
Yep, I'm back.

Inspired by an email of Michael Homeijer 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103483890724049&w=2 
I created a first version of a DAVmap, a sitemap serving as a WebDAV 
server.

If you extract the zip file to /samples/webdav, you 
can mount http://localhost:/samples/webdav/davmap/repo as a 
webfolder.

I tested it with Windows Explorer on win2k, with XML Spy, an 
application build on the Slide WebDAV client library and the 
WebDAVSource (yes, that means you can use Cocoon as its own WebDAV 
repository :-)

Way cool, Guido !

But the bad thing about WebDAV on Windoze (aka "webfolders") is that 
it's not a real filesystem : you cannot open the file directly from 
there, but only copy/paste it on a "real" filesystem. Or did I missed 
something ?
no, you are right, webforlders sck! and they are as buggy 
as hell, expecially if you do webdav over https with digital 
certificates. forget it, you have to use a commercial application 
(don't remember its name).

As this again is based on Cocoon's source resolving you could expose 
your CVS repository via Sylvain's CVSSource or a Xindice Database 
(given someone implements TraversableSource and maybe 
ModifiableSource in XMLDBSource). You could even integrate some data 
of a SQL table or just proxy another WebDAV server (to leverage its 
versioning or to plugin some workflow logic).

Quick update about the CVSSource : I did a major rewrite for one of 
our projects (Gianugo : it's a CMS using dynamically-generated sxw 
files to edit content!), and it's now an Excalibur Source and supports 
crawling the version history (only on the main branch), tagging, cache 
validity, etc. I committed this new version this morning on 
cocoondev.org.
awesome!!

What's to be done now is handling branches and move to Eclipse's CVS 
client library in order to migrate into Cocoon's CVS (it currently 
uses JCVS's client library which is LGPL'ed).
maybe if you give us some pointers on what needs to be done, somebody 
might chime in.



I would love to see cocoon becoming a framework that can glue 
together everything on the web, from stateless publishing from 
stateful webdav applications and yeah, why not, once you can do 
webdav applications you can do SOAP applications or XML-RPC 
applications, they are, more or less, all XMLoverHTTP stuff.

Now, is the sitemap ready for this?

No, it needs a new concept. Something I've been calling "extractor": 
a component that is able to extract information from a pipeline and 
make it available to the sitemap for further selection of components.

why? because both WebDAV and SOAP have the terrible attitude of 
storing pipeline-routing information *inside* the pipeline.

It has been proposed in the past to allow selectors to have access to 
the pipeline, but I like the idea of "extractors" more.


Mmmh... "extractor" or pipeline-aware selectors somewhat imply a 
single processing pipeline.
not at all, actually, the opposite.

Where does the flow fit in this ?
just like any other pipeline.

What about handling this kind of request by a flowscript that would 
call an input pipeline (term introduced by Daniel Fagerstrom) that 
would extract the meat from the incoming stream (e.g. build a 
bean/hashmap/woody form/whatever from its content), and then call a 
regular response pipeline after having processed  the incoming data ?
sure, but will be up to you do decide how to write your webdavapp. 
that's the point: cocoon should provide you the low level components 
and you compose them as you like.

Today, cocoon cannot select parts of a pipeline depending on 
information contained inside the pipeline itself.

So far, we didn't miss this much because selection is never done with 
data that passes inside the pipeline, but all xml-rpc-like applications 
(and SOAP and WebDAV fall into this category), the information for 
processing the request has to be *extracted* from the pipeline flow 
before being made available.

Note that I said "processing the request" and this impact all matching 
selecting and flow control.

Do we really need extractors? no, we can extend the StreamGenerator 
into a WebDAV StreamGenerator that extracts information from the stream 
and places it into the request parameters, then you can do processing 
as it was a normal request.

But just as the aggregator is just a special generator, I was thinking 
of introducing the concept of an extractor which is just a generator 
but that expects serious payloads that contain inforamation that might 
be needed by the sitemap/flow to process the request (NOTE: both the 
sitemap and flow DO NOT have access to the pipeline content directly, 
and this should *NOT* change! this is the reason why we should 
introduce this 'extraction' concept)

In other 

[Vote] Ugo Cei and Marc Portier as Cocoon committers

[Sylvain Wallez]

Hi team,

I'd like to propose two people for Cocoon committership : Ugo Cei and 
Marc Portier.

Ugo has been there for years (the archives show his first post back in 
July 2000!), has been an early adopter of flowscript and wrote the first 
Cocoon-based blogging tool.

Marc is working intensively on the binding and flowscript integrations 
of Woody and cares a lot about Cocoon.

Please cast your votes.
Here are mines : +1 for both !
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] Ugo Cei and Marc Portier as Cocoon committers

[Antonio Gallardo]

Sylvain Wallez dijo:
> Hi team,
>
> I'd like to propose two people for Cocoon committership : Ugo Cei and
> Marc Portier.
>
> Ugo has been there for years (the archives show his first post back in
> July 2000!), has been an early adopter of flowscript and wrote the first
>  Cocoon-based blogging tool.

+1
>
> Marc is working intensively on the binding and flowscript integrations
> of Woody and cares a lot about Cocoon.

+1


Antonio Gallardo

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Joerg Heinicke]

Sylvain Wallez wrote:

Ugo has been there for years (the archives show his first post back in 
July 2000!), has been an early adopter of flowscript and wrote the first 
Cocoon-based blogging tool.
+1

Marc is working intensively on the binding and flowscript integrations 
of Woody and cares a lot about Cocoon.
+1

Joerg

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Stephan Michels]

On Mon, 28 Jul 2003, Sylvain Wallez wrote:

> Hi team,
>
> I'd like to propose two people for Cocoon committership : Ugo Cei and
> Marc Portier.
>
> Ugo has been there for years (the archives show his first post back in
> July 2000!), has been an early adopter of flowscript and wrote the first
> Cocoon-based blogging tool.
>
> Marc is working intensively on the binding and flowscript integrations
> of Woody and cares a lot about Cocoon.
>
> Please cast your votes.
> Here are mines : +1 for both !

+1 for both, of cause!

Stephan.

Re: [RT] Webdavapps with Cocoon

[Sylvain Wallez]

Stefano Mazzocchi wrote:

On Monday, Jul 28, 2003, at 14:23 Europe/Rome, Sylvain Wallez wrote:

Stefano Mazzocchi wrote:

On Friday, Jul 25, 2003, at 11:44 Europe/Rome, [EMAIL PROTECTED] 
wrote:


"Europe/Rome" : Stefano is ba-a-ack !


Yep, I'm back.


Hmmm, h, h, you are triggering second order thinking 
h... I need a whiteboard... I'll be back soon. 


This time, for sure, it's "Stefanator 3, Rise of the webdavapps" ;-P

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: processing flow for

[Marc Portier]

Sylvain Wallez wrote:
Joerg Heinicke wrote:



So we can consider resources as "gosub" and no more "goto" as stated in 
the doc. Moreover, since resources can be passed parameters, they are 
actually functions ! I can't remember if a formal vote occured on this, 
but people globally found this feature usefull.
^^

the man is so honest, there was actually a sigh of relieve 
throughout the entire galaxy :-)

much of the viewed side-effects to be observed here:
http://hubblesite.org/newscenter/archive/
Time to update the docs...

I'm prepping up a rewrite of some the wiki pages as a doco patch 
(unless someone beats me to it)

Sylvain

-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at  http://radio.weblogs.com/0116284/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Sylvain Wallez]

Antonio Gallardo wrote:

Sylvain Wallez dijo:
 

Hi team,

I'd like to propose two people for Cocoon committership : Ugo Cei and Marc Portier.

Ugo has been there for years (the archives show his first post back in July 2000!), has been an early adopter of flowscript and wrote the first Cocoon-based blogging tool.
   

+1
 

Marc is working intensively on the binding and flowscript integrations
of Woody and cares a lot about Cocoon.
   

+1
 

Antonio, we appreciate your opinion and enthusiasm, but remember that 
committers are voted by other comitters and that you're not (yet) one !

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] Ugo Cei and Marc Portier as Cocoon committers

[Marcus Crafter]

Hi All,

+1 for both - Welcome Marc and Ugo! :)

Cheers,

Marcus

On Mon, Jul 28, 2003 at 03:46:49PM +0200, Sylvain Wallez wrote:
> Hi team,
> 
> I'd like to propose two people for Cocoon committership : Ugo Cei and 
> Marc Portier.
> 
> Ugo has been there for years (the archives show his first post back in 
> July 2000!), has been an early adopter of flowscript and wrote the first 
> Cocoon-based blogging tool.
> 
> Marc is working intensively on the binding and flowscript integrations 
> of Woody and cares a lot about Cocoon.
> 
> Please cast your votes.
> Here are mines : +1 for both !
> 
> 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
> 

-- 
.
 ,,$,  Marcus Crafter
;$'  ':Computer Systems Engineer
$: :   ManageSoft GmbH
 $   o_)$$$:   82-84 Mainzer Landstrasse
 ;$,_/\ &&:'   60327 Frankfurt Germany
   ' /( &&&
   \_'
  .
&&&:

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Upayavira]

On Mon, 28 Jul 2003 15:46:49 +0200, "Sylvain Wallez"
<[EMAIL PROTECTED]> said:
> Hi team,
> 
> I'd like to propose two people for Cocoon committership : Ugo Cei and 
> Marc Portier.
> 
> Ugo has been there for years (the archives show his first post back in 
> July 2000!), has been an early adopter of flowscript and wrote the first 
> Cocoon-based blogging tool.
> 
> Marc is working intensively on the binding and flowscript integrations 
> of Woody and cares a lot about Cocoon.
> 
> Please cast your votes.
> Here are mines : +1 for both !

+1 to both

(eee! My first vote!)

Upayavira

RE: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Morrison, John]

Sylvain Wallez wrote:
> Hi team,
> 
> I'd like to propose two people for Cocoon committership : Ugo Cei and
> Marc Portier. 
> 
> Ugo has been there for years (the archives show his first post back in
> July 2000!), has been an early adopter of flowscript and wrote the
> first Cocoon-based blogging tool.
> 
> Marc is working intensively on the binding and flowscript integrations
> of Woody and cares a lot about Cocoon.
> 
> Please cast your votes.
> Here are mines : +1 for both !
> 
> Sylvain

I didn't realise they weren't!

+1 for both.

Are there any other regular [PATCH]ers who deserve this?

J.


===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.
Experian Limited (registration number 653331).
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF

RE: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Carsten Ziegeler]

+1 for both

Carsten

Sylvain Wallez wrote:
> 
> Ugo has been there for years (the archives show his first post back in 
> July 2000!), has been an early adopter of flowscript and wrote 
the first 
> Cocoon-based blogging tool.
> 
> Marc is working intensively on the binding and flowscript integrations 
> of Woody and cares a lot about Cocoon.
> 

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Christian Haul]

On 28.Jul.2003 -- 03:46 PM, Sylvain Wallez wrote:
> Hi team,
> 
> I'd like to propose two people for Cocoon committership : Ugo Cei and 
> Marc Portier.
> 
> Ugo has been there for years (the archives show his first post back in 
> July 2000!), has been an early adopter of flowscript and wrote the first 
> Cocoon-based blogging tool.

+1

> Marc is working intensively on the binding and flowscript integrations 
> of Woody and cares a lot about Cocoon.

+1

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

CODE FREEZE for 2.1rc1

[Carsten Ziegeler]

Hi,

I will start with the release tomorrow morning around 10:00 european time,
so please don't commit from that time on until I finished building the
release.

PS: and put the champaigne into the fridge.

Thanks
Carsten 

Re: cvs commit: cocoon-2.1 status.xml

[Geoff Howard]

Gianugo Rabellino wrote:
Geoff Howard wrote:

  @@ -647,7 +706,7 @@
   // import the fragment
   Node importNode = resource.importNode(fragment, 
true);
   if ( path.equals("") ) {  // this is allowed in write
  -resource.appendChild(importNode);
  +resource.appendChild(importNode.getFirstChild());
   message = "entire source overwritten";


Was this bit the DOM "bug"?  Was it caused by whitespace outside root 
node when overwriting the whole document?  There was some discussion 
about 9 months ago where some (at least one) thought that was 
mandatory behavior and the responsibility of the fragment author (or 
pipeline) to remove whitespace.

If you've changed that behavior I'm personally very +1 but it may be 
worth a discussion.


I don't think it's a matter of whitespace. I'm not a DOM guru, but if 
the firstChild is a whitespace node it should be returned by the 
getFistChild() call as well. Actually, I am a bit puzzled too, since the 
SWT wasn't working on my setup but it was on others (I suspect it has to 
do with the latest JVM that I'm using), no matter what sample documents 
I gave to him. With this one liner, everything was working OK, so I just 
thought to change it. But I'm more than open to any discussion. :-)
Nope, sounds like it's not needed.  I was making connections from 
distant memory.

Geoff

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Geoff Howard]

Sylvain Wallez wrote:
Hi team,

I'd like to propose two people for Cocoon committership : Ugo Cei and 
Marc Portier.

Ugo has been there for years (the archives show his first post back in 
July 2000!), has been an early adopter of flowscript and wrote the first 
Cocoon-based blogging tool.
+1 (thought he was)

Marc is working intensively on the binding and flowscript integrations 
of Woody and cares a lot about Cocoon.
+1

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Torsten Curdt]

Here are mines : +1 for both !
+1 for both
--
Torsten

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Nicola Ken Barozzi]

Sylvain Wallez wrote, On 28/07/2003 15.46:
Hi team,

I'd like to propose two people for Cocoon committership : Ugo Cei and 
Marc Portier.

Ugo has been there for years (the archives show his first post back in 
July 2000!), has been an early adopter of flowscript and wrote the first 
Cocoon-based blogging tool.
+1

Marc is working intensively on the binding and flowscript integrations 
of Woody and cares a lot about Cocoon.
+1

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

RE: NPE after portal-fw samples sitemap reload

[Carsten Ziegeler]

Joerg Heinicke wrote:
>
> FYI: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21400
>
> If this occurs as often as written by Alfred ("I get an NPE in
> ECS.release always for the first request after touching the sub-
> sitemap"), we maybe have the blocking issue for the release.
>
I think the error reported below is related to the component handling
in the portal. I will have a look at it tomorrow.
This does not seem to be a general error, so it's not a blocker.
And even if it's a common error we can fix it between rc1 and
the final release.

Carsten

>
> Unico Hommes wrote:
> > Whenever reloading the portal-fw samples-fw sitemap. I'm seeing the
> > following NullPointerException:
> >
> > java.lang.NullPointerException
> > at
> > org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedC
> > omponentSelector.java:317)
> > at
> > org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.dispose(Se
> > lectNode.java:169)
> > at
> > org.apache.cocoon.components.treeprocessor.TreeProcessor.disposeTree(Tre
> > eProcessor.java:472)
> > at
> > org.apache.cocoon.components.treeprocessor.TreeProcessor.setupRootNode(T
> > reeProcessor.java:422)
> > at
> > org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
> > cessor.java:319)
> > at
> > org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
> > cessor.java:307)
> > at
> > org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun
> > tNode.java:133)
> > at
> > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
> > invokeNodes(AbstractParentProcessingNode.java:84)
> > at
> > org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i
> > nvoke(PreparableMatchNode.java:164)
> > at
> > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
> > invokeNodes(AbstractParentProcessingNode.java:108)
> > at
> > org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P
> > ipelineNode.java:164)
> > at
> > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
> > invokeNodes(AbstractParentProcessingNode.java:108)
> > at
> > org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(
> > PipelinesNode.java:161)
> > at
> > org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
> > cessor.java:325)
> > at
> > org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
> > cessor.java:307)
> > at
> > org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun
> > tNode.java:133)
> > at
> > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
> > invokeNodes(AbstractParentProcessingNode.java:84)
> > at
> > org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i
> > nvoke(PreparableMatchNode.java:164)
> > at
> > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
> > invokeNodes(AbstractParentProcessingNode.java:108)
> > at
> > org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P
> > ipelineNode.java:164)
> > at
> > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
> > invokeNodes(AbstractParentProcessingNode.java:108)
> > at
> > org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(
> > PipelinesNode.java:161)
> > at
> > org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
> > cessor.java:325)
> > at
> > org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
> > cessor.java:307)
> > at org.apache.cocoon.Cocoon.process(Cocoon.java:621)
> >
> > Would an additional null check suffice or is this a symptom of a
> > different problem?
>

Re: [flow] forwardTo()

[Marc Portier]

Bruno Dumon wrote:
On Tue, 2003-07-22 at 16:12, Marc Portier wrote:

Hi all,

Trying to understand some more flow internals...

I just checked the FOM_Cocoon.java on how it handles the redirects...

and this seems to be the relevant portion:

String redUri = uri;
if(! uri.startsWith( "cocoon://" ) ) {
redUri = "cocoon://" + this.environment.getURIPrefix() + uri;
}


actually that's how the forwardTo(uri, object, Continuation) method does
it.
forwardTo(uri, object, FOM_WebContinuation) always inserts cocoon:// +
getURIPrefix, regardless of whether the URI already starts with
cocoon://


1/ do we explicitely want to prohibit the usage of ANY valid uri
to redirect to?
I guess that http://whatever-uri should be able to work as well,
no?  Maybe we should just be checking for the presence of a
'scheme' part in the URI?


Don't know. We got a redirectTo method for that.

ah, an observation I missed out on, thx
(I take it that function-implementation was going over a 
different path then the forwardTo?)

another thought that did cross my mind:
the presence of the 2nd argument (the bizdata-object) actually 
indicates that this forwardTo() is only to be used for selection 
of cocoon-pipelines (and not external redirects: what should they 
do with this biz-data?)

so I guess, this adds an argument to your proposal:


(and even if we don't want to have client-side-redirect uri's
ripple through then we should at least check and warn accordingly?)


agreed


2/ when selecting a sitemap-pipeline do we explicitely want to
have everything resolved versus the top level sitemap?
if we would just append 'cocoon:/' (ONE slash) then the
flow-writer can control if he wants to select relative to the
current sitemap or relative to the root sitemap (by letting his
uri start with a '/' or not)
sendPageAndWait('localmap/uri-part');
--> cocoon:/localmap/uri-part
sendPageAndWait('/topmap/whatever);
--> cocoon://topmap/whatever


Makes sense. This could change existing behaviour if people already used
/ at the beginning of the path, but I think that will rarely be the case
and is a change we can still afford now.

3/ is this behaviour a general property of 'flow' or is it 
specific to how the JSInterpreter handles things?

personally I think we can tackle this on the level of the
AbstractInterpreter so this line of thinking becomes available to 
all flow implementations?


I agree.


if all 3 comments make sense the following could become the new
implementation of AbstractInterpreter.forwardTo() (and we could 
offload the burdon from the current implementations)



import org.apache.excalibur.source.SourceUtil;

public void forwardTo(String uri, Object bizData,
WebContinuation continuation,
Environment environment)
  throws Exception
{
  if (SourceUtil.indexOfSchemeColon(uri) == -1) {
  uri = "cocoon:/" + uri;
  }
  Map objectModel = environment.getObjectModel();
  FlowHelper.setContextObject(objectModel, bizData);
  FlowHelper.setWebContinuation(objectModel, continuation);
  PipelinesNode.getRedirector(environment)
   .redirect(false, uri);
}


what do others think?


I would forbid the use of schemes completely (i.e. throw an exception if
the uri contains a scheme), and prepend cocoon:/ (one slash).
makes sense, and makes us need to change existing implementations 
for not doing the same cocoon:/ prepend before the call to 
super.forwardTo()

finally: the exception-throwing prohibits the chaining of 
flow-calls (for which I see no real need, and until somebody does 
that last argument was just an academic remark I'm afraid)

regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at  http://radio.weblogs.com/0116284/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

RE: [RT] Adaptive Caching

[Hunsberger, Peter]

Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:

> NOTE: this is a refactoring of an email I wrote 2 1/2 years 
> ago. 



Stefano,  

had a little more time to read this last week:

Memphis got hit by some 85 mph winds, no power at our house for a week
yet, but I have a printed copy...

(See
http://slideshow.gomemphis.com/slideshow.cfm?type=GOMEMPHIS&ID=stormpics
&NUM=8 for an idea of what we got hit with; as of writing this slides
50, 51, 57 are from just down the block. We had one fence broken, some
torn up screens, one air conditioner damaged, but amazingly no other
damage to our house.)

The little reading I fit in between moving tree branches off our
property  triggered more ancient memories on paging algorithms.  Instead
of trying to dig up my old notes and books I did a Goggle on "paging
algorithm" and found lots of good references that I think may be of some
use.  In particular note:

http://www.cs.duke.edu/~jsv/Papers/catalog/node93.html

Essentially, you can treat Cocoon as having multiple applications
(pipelines) producing working sets (SAX streams) and directly apply the
tons of research done in this area.  You do have to introduce the
concept of "page size", but this can be arbitrarily small or perhaps
using some (average?) OS page size might be reasonable?

If you do the Google search you'll notice the references to randomized
paging algorithms.   I didn't chase these very far other than to
determine that at least one author shows that they can perform as good
as conventional algorithms but not as good as the theoretical best.

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Steven Noels]

On 28/07/2003 15:46 Sylvain Wallez wrote:

Please cast your votes.
Here are mines : +1 for both !
+1 for both, of course.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Christopher Oliver]

+1 for both.

Chris

Sylvain Wallez wrote:

Hi team,

I'd like to propose two people for Cocoon committership : Ugo Cei and 
Marc Portier.

Ugo has been there for years (the archives show his first post back in 
July 2000!), has been an early adopter of flowscript and wrote the 
first Cocoon-based blogging tool.

Marc is working intensively on the binding and flowscript integrations 
of Woody and cares a lot about Cocoon.

Please cast your votes.
Here are mines : +1 for both !
Sylvain

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Bruno Dumon]

On Mon, 2003-07-28 at 15:46, Sylvain Wallez wrote:
> Hi team,
> 
> I'd like to propose two people for Cocoon committership : Ugo Cei and 
> Marc Portier.
> 
> Ugo has been there for years (the archives show his first post back in 
> July 2000!), has been an early adopter of flowscript and wrote the first 
> Cocoon-based blogging tool.
> 
> Marc is working intensively on the binding and flowscript integrations 
> of Woody and cares a lot about Cocoon.

+1 for both!

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

cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/acting HandleFormSubmitAction.java

[bruno]

bruno   2003/07/28 08:54:08

  Modified:src/blocks/woody/java/org/apache/cocoon/woody/acting
HandleFormSubmitAction.java
  Log:
  Respect Avalon lifecycle methods (Serviceable for now) on FormHandlers
  
  Revision  ChangesPath
  1.8   +2 -0  
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/acting/HandleFormSubmitAction.java
  
  Index: HandleFormSubmitAction.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/acting/HandleFormSubmitAction.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- HandleFormSubmitAction.java   26 Jul 2003 14:05:05 -  1.7
  +++ HandleFormSubmitAction.java   28 Jul 2003 15:54:08 -  1.8
  @@ -61,6 +61,7 @@
   import org.apache.cocoon.woody.FormHandler;
   import org.apache.cocoon.woody.formmodel.Form;
   import org.apache.cocoon.i18n.I18nUtils;
  +import org.apache.cocoon.components.LifecycleHelper;
   import org.apache.excalibur.source.Source;
   
   import java.util.Map;
  @@ -103,6 +104,7 @@
   // TODO cache these classes
   Class clazz = Class.forName(formHandlerClassName);
   formHandler = (FormHandler)clazz.newInstance();
  +LifecycleHelper.setupComponent(formHandler, null, null, manager, 
null, null, null);
   formHandler.setup(form);
   form.setFormHandler(formHandler);
   }
  
  
  

cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/samples CarSelectorHandler.java

[bruno]

bruno   2003/07/28 08:54:32

  Added:   src/blocks/woody/java/org/apache/cocoon/woody/samples
CarSelectorHandler.java
  Log:
  initial commit
  
  Revision  ChangesPath
  1.1  
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/samples/CarSelectorHandler.java
  
  Index: CarSelectorHandler.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
  
   3. The end-user documentation included with the redistribution, if any, must
  include  the following  acknowledgment:  "This product includes  software
  developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  Alternately, this  acknowledgment may  appear in the software itself,  if
  and wherever such third-party acknowledgments normally appear.
  
   4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not  be
  used to  endorse or promote  products derived from  this software without
  prior written permission. For written permission, please contact
  [EMAIL PROTECTED]
  
   5. Products  derived from this software may not  be called "Apache", nor may
  "Apache" appear  in their name,  without prior written permission  of the
  Apache Software Foundation.
  
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
   APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
   INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
   DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
   OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
   ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
   (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
   THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
   This software  consists of voluntary contributions made  by many individuals
   on  behalf of the Apache Software  Foundation and was  originally created by
   Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the Apache
   Software Foundation, please see .
  
  */
  package org.apache.cocoon.woody.samples;
  
  import org.apache.cocoon.woody.FormHandler;
  import org.apache.cocoon.woody.datatype.SelectionList;
  import org.apache.cocoon.woody.datatype.DynamicSelectionList;
  import org.apache.cocoon.woody.event.ActionEvent;
  import org.apache.cocoon.woody.formmodel.Form;
  import org.apache.cocoon.woody.formmodel.Field;
  import org.apache.avalon.framework.service.Serviceable;
  import org.apache.avalon.framework.service.ServiceManager;
  import org.apache.avalon.framework.service.ServiceException;
  
  /**
   * FormHandler used by the "carselector" sample form.
   */
  public class CarSelectorHandler implements FormHandler, Serviceable {
  private Form form;
  private ServiceManager serviceManager;
  
  public void service(ServiceManager serviceManager) throws ServiceException {
  this.serviceManager = serviceManager;
  }
  
  public void setup(Form form) {
  this.form = form;
  }
  
  public void handleActionEvent(ActionEvent actionEvent) {
  String action = actionEvent.getActionCommand();
  if (action.equals("updatemodels")) {
  Field make = (Field)form.getWidget("make");
  Field model = (Field)form.getWidget("model");
  
  String src = "cocoon:/cars/" + make.getValue();
  SelectionList list = new DynamicSelectionList(model.getDatatype(), src, 
serviceManager);
  model.setSelectionList(list);
  }
  }
  }
  
  
  

cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype ValidationError.java

[bruno]

bruno   2003/07/28 08:54:57

  Modified:src/blocks/woody/java/org/apache/cocoon/woody/datatype
ValidationError.java
  Log:
  javadoc enhancements
  
  Revision  ChangesPath
  1.3   +8 -0  
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/ValidationError.java
  
  Index: ValidationError.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/ValidationError.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ValidationError.java  14 May 2003 11:45:43 -  1.2
  +++ ValidationError.java  28 Jul 2003 15:54:57 -  1.3
  @@ -88,6 +88,7 @@
   }
   
   /**
  + * @param errorMessageKey a message key, to be translated by the I18nTransformer
* @param parameters parameters to be substituted in the errorMessage (will be
* done by the I18nTransformer)
*/
  @@ -99,6 +100,9 @@
   }
   
   /**
  + * @param errorMessageKey a message key, to be translated by the I18nTransformer
  + * @param parameters parameters to be substituted in the errorMessage (will be
  + * done by the I18nTransformer)
* @param keys Each element in the keys array corresponds to a string in the 
parameters array
* and indicates whether that parameter is in itself again a key.
*/
  @@ -109,6 +113,10 @@
   this.i18n = true;
   }
   
  +/**
  + * @param errorMessage the errormessages as precompiled XML produced by the
  + *[EMAIL PROTECTED] 
org.apache.cocoon.components.sax.XMLByteStreamCompiler XMLByteStreamCompiler}.
  + */
   public ValidationError(Object errorMessage) {
   this.saxFragment = errorMessage;
   }
  
  
  

cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/transformation WidgetReplacingPipe.java

[bruno]

bruno   2003/07/28 08:57:16

  Modified:src/blocks/woody/java/org/apache/cocoon/woody/datatype
Datatype.java
   src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl
AbstractDatatype.java AbstractDatatypeBuilder.java
DateTypeBuilder.java DecimalTypeBuilder.java
LongTypeBuilder.java StringTypeBuilder.java
   src/blocks/woody/java/org/apache/cocoon/woody/formmodel
Field.java FieldDefinition.java
FieldDefinitionBuilder.java MultiValueField.java
MultiValueFieldDefinitionBuilder.java
   src/blocks/woody/java/org/apache/cocoon/woody/transformation
WidgetReplacingPipe.java
  Added:   src/blocks/woody/java/org/apache/cocoon/woody/formmodel
AbstractDatatypeWidgetDefinition.java
AbstractDatatypeWidgetDefinitionBuilder.java
  Log:
  Made selection lists a property of a widget rather than the datatype.
  
  Revision  ChangesPath
  1.3   +0 -5  
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/Datatype.java
  
  Index: Datatype.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/Datatype.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Datatype.java 15 Jul 2003 14:09:25 -  1.2
  +++ Datatype.java 28 Jul 2003 15:57:15 -  1.3
  @@ -108,11 +108,6 @@
   public String getDescriptiveName();
   
   /**
  - * Returns the selection list associated with this datatype, or null if it has 
none.
  - */
  -public SelectionList getSelectionList();
  -
  -/**
* Indicates wether this datatype represents an array type. This approach has 
been
* chosen instead of creating a seperate ArrayDatatype interface (and 
corresponding
* implementations), since almost all functionality is the same between the 
scalar
  
  
  
  1.4   +0 -11 
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl/AbstractDatatype.java
  
  Index: AbstractDatatype.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl/AbstractDatatype.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- AbstractDatatype.java 15 Jul 2003 14:09:25 -  1.3
  +++ AbstractDatatype.java 28 Jul 2003 15:57:15 -  1.4
  @@ -62,7 +62,6 @@
*/
   public abstract class AbstractDatatype implements Datatype {
   private List validationRules = new ArrayList();
  -private SelectionList selectionList;
   private boolean arrayType = false;
   private DatatypeBuilder builder;
   private Convertor convertor;
  @@ -80,16 +79,6 @@
   
   public void addValidationRule(ValidationRule validationRule) {
   validationRules.add(validationRule);
  -}
  -
  -public void setSelectionList(SelectionList selectionList) {
  -if (selectionList.getDatatype() != this)
  -throw new RuntimeException("Error in AbstractDatatype.setSelectionList: 
tried to assign a SelectionList that is not associated with this datatype.");
  -this.selectionList = selectionList;
  -}
  -
  -public SelectionList getSelectionList() {
  -return selectionList;
   }
   
   public boolean isArrayType() {
  
  
  
  1.7   +0 -46 
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl/AbstractDatatypeBuilder.java
  
  Index: AbstractDatatypeBuilder.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl/AbstractDatatypeBuilder.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- AbstractDatatypeBuilder.java  16 Jul 2003 13:59:18 -  1.6
  +++ AbstractDatatypeBuilder.java  28 Jul 2003 15:57:15 -  1.7
  @@ -65,9 +65,6 @@
   import org.apache.excalibur.source.Source;
   import org.apache.excalibur.source.SourceResolver;
   import org.w3c.dom.Element;
  -import org.w3c.dom.Document;
  -import org.xml.sax.InputSource;
  -
   import java.io.IOException;
   
   /**
  @@ -124,49 +121,6 @@
   
   public Convertor getPlainConvertor() {
   return plainConvertor;
  -}
  -
  -protected Source resolve(String src) throws IOException, ServiceException {
  -SourceResolver resolver = null;
  -try {
  -resolver = (SourceResolver)serviceManager.lookup(SourceResolver.ROLE);
  -return resolver.resolveURI(src);
  -} finally {
  -if (resolver != null)
  -

cvs commit: cocoon-2.1/src/blocks/woody/samples/forms form1.xml form2_model.xml

[bruno]

bruno   2003/07/28 08:58:16

  Modified:src/blocks/woody/samples/forms form1.xml form2_model.xml
  Log:
  selection-lists are now part of the widget instead of the datatype.
  
  Revision  ChangesPath
  1.9   +44 -47cocoon-2.1/src/blocks/woody/samples/forms/form1.xml
  
  Index: form1.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/blocks/woody/samples/forms/form1.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- form1.xml 25 Jul 2003 16:23:36 -  1.8
  +++ form1.xml 28 Jul 2003 15:58:16 -  1.9
  @@ -22,38 +22,36 @@
 
   
 
  -  
   
  +
 
   
 
   Indicate the size of your bank account (in m3):
  -
  -  
  -
  -
  -
  -  three
  -
  -
  -
  -  
  -
  +
  +
  +  
  +  
  +  
  +three
  +  
  +  
  +  
  +
 
   
 
   Indicate your height (in cows):
  -
  -  
  -
  -
  -
  -  three
  -
  -
  -
  -  
  -
  +
  +
  +  
  +  
  +  
  +three
  +  
  +  
  +  
  +
 
   
 
  @@ -75,17 +73,17 @@
 
   Indicate which 2 of the following drinks you'd like to 
receive:
   
  -  
  -
  -
  -
  -
  -
  -  
 
   
 
   
  +
  +  
  +  
  +  
  +  
  +  
  +
 
   
 
  @@ -150,24 +148,23 @@
   Select a date on which you'd rather had been born:
   
 
  -
  -  
  -
  -
  -  
  -MMdd
  -  
  -
  -
  -
  -
  -
  -
  -
  -  
   
  +
  +  
  +  
  +
  +  MMdd
  +
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +
 
   
 
  
  
  
  1.4   +8 -9  cocoon-2.1/src/blocks/woody/samples/forms/form2_model.xml
  
  Index: form2_model.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/blocks/woody/samples/forms/form2_model.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- form2_model.xml   24 Jul 2003 12:42:19 -  1.3
  +++ form2_model.xml   28 Jul 2003 15:58:16 -  1.4
  @@ -64,15 +64,14 @@
   
 
   Select a number:
  -
  -  
  -
  -
  -
  -
  -
  -  
  -
  +
  +
  +  
  +  
  +  
  +  
  +  
  +
 
   
 
  
  
  

cvs commit: cocoon-2.1/src/blocks/woody/samples/forms car-db.xml carselector_form.xml carselector_success.xsp carselector_template.xml

[bruno]

bruno   2003/07/28 09:00:28

  Modified:src/blocks/woody/samples sitemap.xmap welcome.xml
  Added:   src/blocks/woody/samples/forms car-db.xml
carselector_form.xml carselector_success.xsp
carselector_template.xml
  Log:
  Added carselector sample, illustrating changing the selectionlist on widget-instance 
level.
  
  Revision  ChangesPath
  1.13  +71 -0 cocoon-2.1/src/blocks/woody/samples/sitemap.xmap
  
  Index: sitemap.xmap
  ===
  RCS file: /home/cvs/cocoon-2.1/src/blocks/woody/samples/sitemap.xmap,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- sitemap.xmap  25 Jul 2003 09:03:19 -  1.12
  +++ sitemap.xmap  28 Jul 2003 16:00:24 -  1.13
  @@ -276,6 +276,77 @@
  
  

  +
  +
  + 
  +
  + 
  +   
  +   
  + 
  +   
  +   
  + 
  +
  + 
  +   
  +   
  + 
  + 
  +   
  +   
  + 
  +
  + 
  +   
  + 
  +   
  + 
  + 
  +   
  + 
  + 
  +   
  + 
  + 
  + 
  +
  + 
  + 
  +   
  +   
  +   
  +   
  +   
  + 
  + 
  +   
  + 
  + 
  +   
  + 
  +   
  +
  +   
  +   
  + 
  +   
  +   
  + 
  +   
  +   
  +   
  + 
  + 
  + 
  + 
  + 
  +   
  +   
  + 
  +
  

   
  
  
  
  1.6   +1 -0  cocoon-2.1/src/blocks/woody/samples/welcome.xml
  
  Index: welcome.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/blocks/woody/samples/welcome.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- welcome.xml   26 Jul 2003 14:05:40 -  1.5
  +++ welcome.xml   28 Jul 2003 16:00:24 -  1.6
  @@ -16,6 +16,7 @@
 This sample shows validation, event handling 
and various Woody features.
 The same sample as above using 
Flowscript.
 A simple registration 
form.
  +  Illustrates programmatically 
changing selectionlists.

   

  
  
  
  1.1  cocoon-2.1/src/blocks/woody/samples/forms/car-db.xml
  
  Index: car-db.xml
  ===
  
  

  
  
  
  
  
  
  


  
  
  


  
  


  
  
  

  
  
  
  
  1.1  cocoon-2.1/src/blocks/woody/samples/forms/carselector_form.xml
  
  Index: carselector_form.xml
  ===
  
  
  http://apache.org/cocoon/woody/definition/1.0";
xmlns:i18n="http://apache.org/cocoon/i18n/2.1";>
  

  Make:
  
  

  

  Model:
  
  

  select a make first

  

  

  Update models

  
  
  
  
  
  1.1  
cocoon-2.1/src/blocks/woody/samples/forms/carselector_success.xsp
  
  Index: carselector_success.xsp
  ===
  
  http://apache.org/xsp";>
  

  org.apache.cocoon.woody.formmodel.*

  

  Car selector result
  

  // get reference to form and some of the widgets on it
  Form form = (Form)request.getAttribute("carselectorform");
  Field make = (Field)form.getWidget("make");
  Field model = (Field)form.getWidget("model");

  
You selected: make.getValue() 
model.getValue()
  

  
  
  
  
  1.1  
cocoon-2.1/src/blocks/woody/samples/forms/carselector_template.xml
  
  Index: carselector_template.xml
  ===
  
  http://apache.org/cocoon/woody/template/1.0";>
Car selector
This example illustrates how you can programmatically update the
  content of a selection list. See the code in the "CarSelectorHandler" class
  to see how this is done.
After selecting a make, press the "Update models" button to see the
  corresponding models. It would be nice to do this with an automatic submit
  when the make list changes, but no effort has been done yet in Woody to
  standarize Javascript-integration, so I've left that out for now.

  

  


  
  

  

  
  


  

  

  

  
  
  
  

cvs commit: cocoon-2.1/src/blocks/woody/samples/xsl carfilter.xsl

[bruno]

bruno   2003/07/28 09:01:26

  Added:   src/blocks/woody/samples/xsl carfilter.xsl
  Log:
  selection-lists are now part of the widget instead of the datatype.
  
  Revision  ChangesPath
  1.1  cocoon-2.1/src/blocks/woody/samples/xsl/carfilter.xsl
  
  Index: carfilter.xsl
  ===
  http://www.w3.org/1999/XSL/Transform";
xmlns:wd="http://apache.org/cocoon/woody/definition/1.0";>
  


  

  

  


  

  

  

  

  

  

  

  

  

  

  
  
  
  
  

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Michael Melhem]

On Mon, Jul 28, 2003 at 03:46:49PM +0200, Sylvain Wallez wrote:
> Hi team,
> 
> I'd like to propose two people for Cocoon committership : Ugo Cei and 
> Marc Portier.
> 
> Ugo has been there for years (the archives show his first post back in 
> July 2000!), has been an early adopter of flowscript and wrote the first 
> Cocoon-based blogging tool.
> 
> Marc is working intensively on the binding and flowscript integrations 
> of Woody and cares a lot about Cocoon.
> 
> Please cast your votes.
> Here are mines : +1 for both !

+1 && +1, of course.

cheers,
Michael

> 
> 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] Ugo Cei and Marc Portier as Cocoon committers

[Gianugo Rabellino]

Sylvain Wallez wrote:
I'd like to propose two people for Cocoon committership : Ugo Cei and 
Marc Portier.

Marc is working intensively on the binding and flowscript integrations 
of Woody and cares a lot about Cocoon.

Please cast your votes.
Here are mines : +1 for both !
Big +1 for both, and welcome aboard!

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: CODE FREEZE for 2.1rc1

[Sylvain Wallez]

Carsten Ziegeler wrote:

Hi,

I will start with the release tomorrow morning around 10:00 european time, so please don't commit from that time on until I finished building the release.

PS: and put the champaigne into the fridge.

It's spelled "champagne" ! Wines are serious things in France ;-)

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] Ugo Cei and Marc Portier as Cocoon committers

[Marc Portier]

Sylvain Wallez wrote:
Hi team,

Hi team again,

many thanx for the welcoming votes, quite a honorable surprise
I'll do my best to live up to the expectations and high standards
Really short introduction on 
http://wiki.cocoondev.org/Wiki.jsp?page=MarcPortier

and there really isn't that much to add (meaning: just ask if 
you'ld like to know)

maybe some more personal remarks:

- my last name looks french-sounding but has a flemish sounding 
variant to be used (no sound files available, but I'm largely 
custom to quite bad international versions anyway, so I will not 
mind... you might just want to consider the first name as a safe 
alternative though)

- live together with the mother of my beautiful two kids (waiting 
for a family BBQ downstairs so I should hurry up)

- 'learning' and his sharing counterpart: 'teaching' is what I 
like most in this life... it happened to get organized around 
java and xml at some point... almost at the moment I met Steven, 
then I met Bruno, then we started outerthought, and now this :-)



As for my much hyped spelling (and general usage) of the English 
language, there is one quote I really like:

http://www.brainyquote.com/quotes/quotes/a/q138608.html
(A.A Milne should be known for Whiney The Poeh --> Winny the Pooh!)
if it gets too messy, then start to think of it as a poem :-)

thx again,

-marc=


I'd like to propose two people for Cocoon committership : Ugo Cei and 
Marc Portier.

Ugo has been there for years (the archives show his first post back in 
July 2000!), has been an early adopter of flowscript and wrote the first 
Cocoon-based blogging tool.

Marc is working intensively on the binding and flowscript integrations 
of Woody and cares a lot about Cocoon.

Please cast your votes.
Here are mines : +1 for both !
Sylvain

--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at  http://radio.weblogs.com/0116284/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [RT] Webdavapps with Cocoon

[Gianugo Rabellino]

Stefano Mazzocchi wrote:

the single pieces that make that result happen. Even the simplest 
XSLT transformation can't be reversely applied, so now there is no 
way to understand how an resource should be treated in a symmetric 
way when requested or uploaded. Oh yes, you can


hm, do we really need to look at it as symmetric?


No, we don't. I've been thinking about this a lot and I think that 
symmetry is not only a holy grail, but it's the wrong grail to consider 
holy. Read on.

I know we are tempted to do so, but is it a must?


It is tempting, but symmetry-driven design is bad. we must understand 
what we want, why and what is limiting us.
I knew that I would have triggered this comment. However, let me just 
state that not everything that contains "simmetry" in inherently bad: in 
most case I'm totally with you, but there are situations where you need 
simmetry, and WebDAV looks to me (potentially) as one of those.

I see that you don't particularily like the "web folders" metaphore, and 
I'm with you when you say that this is just one of the possible DAV 
applications, yet it's quite an important one. However, thinking more 
about it, it might be cool to d&d an SVG and see an XSL popping out: but 
the idea of exposing the wonderful world of Cocoon as a disk is too 
exciting to me to be left behind. :-)

Note that on a real FS, everybody knows the difference between

 /home/blah/news

and

 /home/blah/news/

because the OS enforces type checking on these (on a POSIX file system 
you cannot open a directory for writing as a file, for example).
I don't see it. Actually /home/blah/news is a directory even if you 
don't put a trailing slash on it, and you can't have a file and a 
directory sharing the same name. But this is nitpicking.

If I have a resource like

 http://blah.com/news/

and I want to edit, I could ask for

 http://blah.com:/news/
 http://edit.blah.com/news/
 http://blah.com/news/?view="edit";
Well... yes and no: in a shared folders scenario this doesn't apply. And 
this is *exactly*, besides, where Cocoon might shine when compared to 
Zope: Zope supports WebDAV, but what you see from your shared folders 
are the "bare" zope components, with little or no way (AFAIK) to expose 
an aggregation or trasformation of both. Cocoon, instead, could offer a 
particular "view" to editors which is vitual and assembled on the fly 
for each particular request.

The real problem is what's Nirvana for each of us: to me it would be 
just great to have a way of automatically expose a Cocoon pipeline both 
as an HTTP resource *and* as a DAV (editable) resource. Something like:



This might implemented, as a default, in the Zope way (giving access to 
the bare resources) or, if overridden, in a custom way (filtering, 
aggregating and manipulating resources, as an example). But this 
requires simmetry to happen, so I guess it will remain just a dream.

In your scenario, OTOH, there should be a particular sitemap 
configuration for each pipeline, which means that one will need to 
provide for every webdav exposed resource a particular configuration: 
see Guido's great example, it's really cool but it's also a PITA if you 
are to apply it in a more general way.

I normally prefer the virtual-host approach. something like this

   [frontend] <- [repository] <- [backend]
 http://blah.com http://edit.blah.com
where frontend and backend are separated (frontend might even be a 
static representation of the saved content (say, created by a cronned 
forrest every hour or so).

The above setup removes you from the need from having to be symmetric.
This is yet another approach: a different Cocoon with a different 
configuration. Feasible, but then again possibly unmaintainable since it 
requires to keep in sync two different pipeline *logics*.

(they want to put back where they got I assume?)

actually if you look at the combination of 
matchers/request-method-selector you wrote up it more looks like the 
request-method being part of the uri-request space almost?


I dislike this. the action should not be encoded in the URI space.
Definitely.

2) direction: Cocoon is clearly designed for an "inside-out" type of 
flow in mind, while WebDAV is fully bidirectional.


this is not true anymore. with the ability to have pipeline dump their 
content on an outputstream if called from the flow, cocoon reached 
complete bydirectionality.
I disagree here. Cocoon is bidirectional *if* flow is used, which is a 
serious limitation. Actually I've been struck by this lately, on a 
presentation engine we are building, and I see a possible solution (but 
it deserves an RT on its own).

Design-wise it's difficult to adapt the G-T-S pattern to an incoming 
stream of data,
I can't see why. Admittedly, there are generators who are hardly 
reusable in both in-out and out-in case (StreamGenerator or 
RequestGenerator, for example) but that is not a deficiency of the 
pipeline design, expecially now that the output stream of t

Re: [RT] Webdavapps with Cocoon

[Gianugo Rabellino]

Stefano Mazzocchi wrote:

Way cool, Guido !

But the bad thing about WebDAV on Windoze (aka "webfolders") is that 
it's not a real filesystem : you cannot open the file directly from 
there, but only copy/paste it on a "real" filesystem. Or did I missed 
something ?


no, you are right, webforlders sck! and they are as buggy as 
hell, expecially if you do webdav over https with digital certificates. 
forget it, you have to use a commercial application (don't remember its 
name).
Could it be Xythos WebFile Client?

Quick update about the CVSSource : I did a major rewrite for one of 
our projects (Gianugo : it's a CMS using dynamically-generated sxw 
files to edit content!), and it's now an Excalibur Source and supports 
crawling the version history (only on the main branch), tagging, cache 
validity, etc. I committed this new version this morning on 
cocoondev.org.
OK, you made me drool. I'm updating it right away. :-) Since during this 
weekend I rewrote the repository part of Linotype for that, I want to 
see if it works on CVS too. And the next step is trying Guido's davmap 
example... it would be *extremely* cool!

sure, but will be up to you do decide how to write your webdavapp. 
that's the point: cocoon should provide you the low level components and 
you compose them as you like.
And please, think about not necessarily using flow. :-)

But just as the aggregator is just a special generator, I was thinking 
of introducing the concept of an extractor which is just a generator but 
that expects serious payloads that contain inforamation that might be 
needed by the sitemap/flow to process the request (NOTE: both the 
sitemap and flow DO NOT have access to the pipeline content directly, 
and this should *NOT* change! this is the reason why we should introduce 
this 'extraction' concept)
I'm starting to see some light. Care to come up with an example?

In other words, streamed requests aren't so much different from 
regular requests : it's just that incoming data is more complex and 
that decoding is not handled transparently by the servlet engine. Once 
decoded, the processing model can be the same as usual.


Hmmm, h, h, you are triggering second order thinking 
h... I need a whiteboard... I'll be back soon.
Can't wait. :-)

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/)

cvs commit: cocoon-2.1/src/documentation/xdocs/userdocs/flow api.xml

[coliver]

coliver 2003/07/28 10:04:10

  Modified:src/documentation/xdocs/userdocs/flow api.xml
  Log:
  Minor corrections
  
  Revision  ChangesPath
  1.23  +3 -9  cocoon-2.1/src/documentation/xdocs/userdocs/flow/api.xml
  
  Index: api.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/userdocs/flow/api.xml,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- api.xml   27 Jul 2003 16:10:59 -  1.22
  +++ api.xml   28 Jul 2003 17:04:10 -  1.23
  @@ -332,8 +332,7 @@
   
   
   
  -
  -[name] -> maps to the parameter with that name. For example 
request.blah is equivalent to request.getParameter("blah")
  +Request properties map to request parameters, i.e. 
request.blah is equivalent to request.getParameter("blah").

   
   
  @@ -453,10 +452,7 @@
   
   
   
  -  [name] -> maps to the attribute indicates with the name
  -
  -  For example session.blah is equivalent to session.getAttribute("blah") 
  -
  +  Session properties map to session attributes, i.e. 
session.blah is equivalent to 
session.getAttribute("blah").
   
   
   
  @@ -488,9 +484,7 @@
   
   
   
  -  [name] -> maps to the attribute indicates with the name
  -
  -  For example context.blah is equivalent to context.getAttribute("blah") 
  +  Context properties map to context attributes, i.e. 
context.blah is equivalent to context.getAttribute("blah"). 
   
   
   
  
  
  

DO NOT REPLY [Bug 21609] - [PATCH] NaN error in XSP version of the calc flow example

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21609

[PATCH] NaN error in XSP version of the calc flow example





--- Additional Comments From [EMAIL PROTECTED]  2003-07-28 17:23 ---
Sorry my mistake. It doesn't look like this is still necessary. I misread the
code. I believe cocoon.request.name doesn't work because 'name' is a variable
not the name of a request parameter. So the patch should most likely be

EITHER

-  return parseFloat(cocoon.request.name);
+  return parseFloat(cocoon.request.getParameter(name));

OR

-  return parseFloat(cocoon.request.name);
+  return parseFloat(eval("cocoon.request." + name));

cvs commit: cocoon-2.1/src/documentation/xdocs/userdocs index.xml

[coliver]

coliver 2003/07/28 10:41:58

  Modified:src/documentation/xdocs/userdocs index.xml
  Log:
  added link to continuation page example
  
  Revision  ChangesPath
  1.4   +1 -1  cocoon-2.1/src/documentation/xdocs/userdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/userdocs/index.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- index.xml 27 Jul 2003 00:59:54 -  1.3
  +++ index.xml 28 Jul 2003 17:41:58 -  1.4
  @@ -25,7 +25,7 @@
 
  If you've been writing web applications with any other system you should 
  also take a look at Cocoon Flowscript,
  -   which makes writing complex Web applications easy with Cocoon. Complex 
multi-page interactions can be described easily as blocking function calls.
  +   which makes writing complex Web applications easy with Cocoon. Complex 
multi-page interactions can be described 
easily as blocking function calls.
 
 
 Come back often...this guide is being updated regularly.
  
  
  

Re: Cocoon and OJB with JDO.

[JD Daniels]

Ok question:

I have got lost in the OJB docs... I got your example working ok, but where
can i get some documentation on how to code a structure like this:

class contact:
id
name
phone

class client
id
accountName
address

class timeticket
id
hours
desc
client
contact

ie, have a lookup for contact and client (two separate tables) inside the
timeticket class (its own table with the id values from the other two)

I just dont see how to describe the timticket class in the .jdo file.

JD

- Original Message -
From: "Antonio Gallardo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 28, 2003 5:30 AM
Subject: Cocoon and OJB with JDO.


> Hi Cocooners!
>
> I am currently working trying to use OJB with Cocoon. I already wrote a
> simple example and I invite you to see it at wiki. :=)
>
> http://wiki.cocoondev.org/Wiki.jsp?page=OJBWithJDO
>
> Please note this is a first attempt to use an alternative project to
> Hibernate. I choosed OJB because it is under the Apache umbrella. This
> simple fact will allow us to integrate it in Cocoon. The problem with
> Hibernate it the LPGL. :(
>
> My idea is that we can build a OJB block and make the life easier for
> people building database webapp. this block can be easily used with Flow.
> I am looking for it.
>
> The OJB can be used as the "model" of the MVC design paradigm. Currently
> we are working in the Controller, called "Flow". An for the View we have 2
> candidates Woody and JXForms.
>
> I will keep working on this stuff and post to the list the results of
that.
>
> Of course, I am not too smart ;)
> I need to thanks to Ricardo Rocha for the advise:
>
>   "Forget XSP and check JDO"
>
> Best Regards,
>
> Antonio Gallardo.
>
>
>
>

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor TreeProcessor.java

[cziegeler]

cziegeler2003/07/28 10:50:42

  Modified:src/java/org/apache/cocoon/components/treeprocessor
TreeProcessor.java
  Log:
  Make cocoon work again :( I thought it was that easy...
  
  Revision  ChangesPath
  1.8   +3 -3  
cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/TreeProcessor.java
  
  Index: TreeProcessor.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/TreeProcessor.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- TreeProcessor.java28 Jul 2003 12:55:45 -  1.7
  +++ TreeProcessor.java28 Jul 2003 17:50:41 -  1.8
  @@ -323,7 +323,7 @@
   }
   
   // and now process
  -CocoonComponentManager.enterEnvironment(environment, 
this.sitemapComponentManager, this);
  +CocoonComponentManager.enterEnvironment(environment, this.manager, this);
   try {
   return this.rootNode.invoke(environment, context);
   } finally {
  @@ -342,7 +342,7 @@
   
   context.enableLogging(getLogger());
   
  -CocoonComponentManager.enterEnvironment(environment, 
this.sitemapComponentManager, this);
  +CocoonComponentManager.enterEnvironment(environment, this.manager, this);
   try {
   if ( process(environment, context) ) {
   return context.getProcessingPipeline();
  
  
  

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor TreeProcessor.java

[cziegeler]

cziegeler2003/07/28 11:09:48

  Modified:src/java/org/apache/cocoon/components/treeprocessor
TreeProcessor.java
  Log:
  It's that easy...removed unnecessary environment handling for internal calls and 
finally fixed wrong sitemap manager
  
  Revision  ChangesPath
  1.9   +2 -4  
cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/TreeProcessor.java
  
  Index: TreeProcessor.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/TreeProcessor.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- TreeProcessor.java28 Jul 2003 17:50:41 -  1.8
  +++ TreeProcessor.java28 Jul 2003 18:09:48 -  1.9
  @@ -323,7 +323,7 @@
   }
   
   // and now process
  -CocoonComponentManager.enterEnvironment(environment, this.manager, this);
  +CocoonComponentManager.enterEnvironment(environment, 
this.sitemapComponentManager, this);
   try {
   return this.rootNode.invoke(environment, context);
   } finally {
  @@ -342,7 +342,6 @@
   
   context.enableLogging(getLogger());
   
  -CocoonComponentManager.enterEnvironment(environment, this.manager, this);
   try {
   if ( process(environment, context) ) {
   return context.getProcessingPipeline();
  @@ -350,7 +349,6 @@
   return null;
   }
   } finally {
  -CocoonComponentManager.leaveEnvironment();
   context.dispose();
   }
   }
  
  
  

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components LifecycleHelper.java

[cziegeler]

cziegeler2003/07/28 11:26:01

  Modified:src/java/org/apache/cocoon/components LifecycleHelper.java
  Log:
  Simple code formatting
  
  Revision  ChangesPath
  1.4   +151 -163  
cocoon-2.1/src/java/org/apache/cocoon/components/LifecycleHelper.java
  
  Index: LifecycleHelper.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/LifecycleHelper.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- LifecycleHelper.java  24 Jul 2003 10:30:52 -  1.3
  +++ LifecycleHelper.java  28 Jul 2003 18:26:01 -  1.4
  @@ -84,35 +84,34 @@
   
   // FIXME : need to handle also LogEnabled.
   
  -public class LifecycleHelper
  -{
  +public class LifecycleHelper {
   /** The Logger for the component
*/
  -private Logger  m_logger;
  +final private Logger m_logger;
   
   /** The Context for the component
*/
  -private Context m_context;
  +final private Context m_context;
   
   /** The component manager for this component.
*/
  -private ComponentManagerm_componentManager;
  +final private ComponentManager m_componentManager;
   
   /** The service manager for this component.
*/
  -private ServiceManagerm_serviceManager;
  +final private ServiceManager m_serviceManager;
   
   /** The configuration for this component.
*/
  -private Configuration   m_configuration;
  +final private Configuration m_configuration;
   
   /** The RoleManager for child ComponentSelectors
*/
  -private RoleManager m_roles;
  +final private RoleManager m_roles;
   
   /** The LogKitManager for child ComponentSelectors
*/
  -private LogKitManager   m_logkit;
  +final private LogKitManager m_logkit;
   
   /**
* Construct a new LifecycleHelper that can be used repeatedly to
  @@ -127,34 +126,47 @@
* @param roles the RoleManager to pass to 
DefaultComponentSelectors.
* @param configuration the Configuration object to pass to new 
instances.
*/
  -public LifecycleHelper( final Logger logger,
  -final Context context,
  -final ComponentManager componentManager,
  -final RoleManager roles,
  -final LogKitManager logkit,
  -final Configuration configuration )
  -{
  +public LifecycleHelper(final Logger logger,
  +final Context context,
  +final ComponentManager componentManager,
  +final RoleManager roles,
  +final LogKitManager logkit,
  +final Configuration configuration) {
   m_logger = logger;
   m_context = context;
   m_componentManager = componentManager;
   m_roles = roles;
   m_logkit = logkit;
   m_configuration = configuration;
  +m_serviceManager = null;
   }
   
  -public LifecycleHelper( final Logger logger,
  -final Context context,
  -final ServiceManager serviceManager,
  -final RoleManager roles,
  -final LogKitManager logkit,
  -final Configuration configuration )
  -{
  +/**
  + * Construct a new LifecycleHelper that can be used repeatedly to
  + * setup several components. Note : if a parameter is null,
  + * the corresponding method isn't called (e.g. if configuration is
  + * null, configure() isn't called).
  + *
  + * @param logger the Logger to pass to LogEnableds, 
unless there is
  + *a LogKitManager and the configuration specifies a logger 
name.
  + * @param context the Context to pass to 
Contexutalizables.
  + * @param serviceManager the service manager to pass to 
Serviceables.
  + * @param roles the RoleManager to pass to 
DefaultComponentSelectors.
  + * @param configuration the Configuration object to pass to new 
instances.
  + */
  +public LifecycleHelper(final Logger logger,
  +final Context context,
  +final ServiceManager serviceManager,
  +final RoleManager roles,
  +final LogKitManager logkit,
  +final Configuration configuration) {
   m_logger = logger;
   m_context = context;
   m_serviceManager = serviceManager;
   m_roles = roles;
   m_logkit = logkit;
   m_configuration = configuration;
  +m_componentManager = null;
   }
   
   /**
  @@ -164,9 +176,7 @@
* @return the component passed in, to allow function chaining.
* @throws Exception if something went wrong.
*/
  -public Ob

Re: [RT] Webdavapps with Cocoon

[Guido Casper]

Sylvain Wallez wrote:
> But the bad thing about WebDAV on Windoze (aka "webfolders") is that
> it's not a real filesystem : you cannot open the file directly from
> there, but only copy/paste it on a "real" filesystem. Or did I missed
> something ?

No. To open a file from a MS webfolder you need to use a WebDAV enabled
editor.

Tools like Webdrive
http://www.southrivertech.com/products/webdrive/index.html
allow you to mount WebDAV as disk drive. AFAIK WinXP does this natively
(please somebody correct me if I'm wrong).

Guido
--

Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

Re: [PATCH] CocoonCrawler enhancements

[Vadim Gritsenko]

Upayavira wrote:

Unico,

I've seen this crawler before, and wondered what it is used for. Can you
tell me?
 

It is used to create a lucene search index. See lucene block, 
SimpleLuceneCocoonIndexerImpl, and samples

Vadim

Re: [RT] Webdavapps with Cocoon

[Guido Casper]

Gianugo Rabellino wrote:
> Stefano Mazzocchi wrote:



>>> this stuff sounds like flow integration on a separate section of the
>>> uri-request-space?
>>
>> I totally agree. i think it would be fairly easy to implement a full
>> dav stack with flowscript and a few java components that wrap around
>> a repository (could be as simple as a file system)
>
> Then again, you're not talking about integrating WebDAV into Cocoon,
> but just give some hooks (something that can be done pretty much now
> already) to make webdavapps using flow. Now, while flow surely rocks,
> I feel that WebDAV support, as an HTTP extension, should be reflected
> in the sitemap too.

Please let me add that a major difference between a webapp and a webdavapp
is that (as Stefano already pointed out) we don't control the client side.

A webdavapp is always stateless on the server as the (fat) client manages
the state. So it should be possible (and more maintainable in the long run?)
to build a webdavapp in a mostly declarative fashion.

Guido
--

Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Vadim Gritsenko]

Sylvain Wallez wrote:

Hi team,

I'd like to propose two people for Cocoon committership : Ugo Cei and 
Marc Portier. 


+1 and +1

Vadim

RE: [PATCH] CocoonCrawler enhancements

[Unico Hommes]

Hi Upayavira,

I missed your email somehow. Yep this one is used by the Lucene block.
It depends on a link view being available in the sitemap and crawls
cocoon over http. I had started implementing a publisher block in the
same vein as the Lucene block because I couldn't really see how to
achieve it the way we discussed a few weeks back, i.e. within the VM,
without first changing a lot internals. This patch is a step toward
that.

I haven't had time to continue with it unfortunately. Also, the boss
decided on our current publisher - that depends on incompatible usage of
cocoon internals - as we already put some effort into that. But I can't
see how I could change the code easily so that it integrates with the
current cocoon. I hope to continue with the cocoon publisher block in
the fall. Sorry, I should have let you know what was happening before
especially because you showed so much interest before.

In a nutshell the idea I had for the Publisher interface:

interface Publisher extends SingleThreaded {
  
  /**
   * parametrize the publisher with the location where
   * from where to start publishing and the depth to publish
   * to.
   */
  void publish(URL url, int depth);
  
  /**
   * after parametrizing the publisher as above, obtain a 
   * an iterator of Publications on the publish path.
   */
  Iterator iterator();

}

This interface is inspired by the CocoonCrawler interface that I found
very elegantly allows client code control over it through the iterator.
The Iterator could hold Publication objects:

Interface Publication {
   
  Long lastModifiedDate();
  
  Long lastPublicationDate();
  
  void publish();

}

The publisher could eventually also have an implementation that
processes directly on the Cocoon object instead of over http. That were
my initial ideas about that I haven't been able to continue yet. Off
course it could be implemented in a hundred other ways equally elegant
:)

Regards,
Unico

> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
> Sent: maandag 28 juli 2003 20:37
> To: [EMAIL PROTECTED]
> Subject: Re: [PATCH] CocoonCrawler enhancements
> 
> Upayavira wrote:
> 
> >Unico,
> >
> >I've seen this crawler before, and wondered what it is used for. Can
you
> >tell me?
> >
> >
> 
> It is used to create a lucene search index. See lucene block,
> SimpleLuceneCocoonIndexerImpl, and samples
> 
> Vadim
> 

Re: Cocoon and OJB with JDO.

[Antonio Gallardo]

JD Daniels dijo:
> Ok question:
>
> I have got lost in the OJB docs... I got your example working ok, but
> where can i get some documentation on how to code a structure like this:
>
> class contact:
> id
> name
> phone
>
> class client
> id
> accountName
> address
>
> class timeticket
> id
> hours
> desc
> client
> contact
>
> ie, have a lookup for contact and client (two separate tables) inside
> the timeticket class (its own table with the id values from the other
> two)
Hi:

Thanks for take your time checking the example. :)

I am currently working on another example integrating now with woody.

For a nice introduction on JDO see (as usual) on IBM developers network.
The tutorial is called: Hands on Java Data Objects
http://www-106.ibm.com/developerworks/java/edu/j-dw-javajdo-i.html

For OJB check the tutorial4:
http://db.apache.org/ojb/tutorial4.html

>
> I just dont see how to describe the timticket class in the .jdo file.

The answer is on the IBM tutorial linked above. ;)

Best Regards,

Antonio Gallardo

DO NOT REPLY [Bug 21945] New: - [PATCH] WebDAV sitemap sample

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21945

[PATCH] WebDAV sitemap sample

   Summary: [PATCH] WebDAV sitemap sample
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


A simplified sitemap using request input module instead of RequestMethodSelector

DO NOT REPLY [Bug 21945] - [PATCH] WebDAV sitemap sample

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21945

[PATCH] WebDAV sitemap sample





--- Additional Comments From [EMAIL PROTECTED]  2003-07-28 19:50 ---
Created an attachment (id=7549)
sitemap.xmap

cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl AbstractDatatypeBuilder.java

[cziegeler]

cziegeler2003/07/28 13:03:13

  Modified:src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl
AbstractDatatypeBuilder.java
  Log:
  Organizing imports
  
  Revision  ChangesPath
  1.8   +9 -10 
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl/AbstractDatatypeBuilder.java
  
  Index: AbstractDatatypeBuilder.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl/AbstractDatatypeBuilder.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- AbstractDatatypeBuilder.java  28 Jul 2003 15:57:15 -  1.7
  +++ AbstractDatatypeBuilder.java  28 Jul 2003 20:03:13 -  1.8
  @@ -50,22 +50,21 @@
   */
   package org.apache.cocoon.woody.datatype.typeimpl;
   
  -import org.apache.cocoon.woody.datatype.*;
  -import org.apache.cocoon.woody.datatype.convertor.Convertor;
  -import org.apache.cocoon.woody.datatype.convertor.ConvertorBuilder;
  -import org.apache.cocoon.woody.util.DomHelper;
  -import org.apache.cocoon.woody.util.SimpleServiceSelector;
  -import org.apache.cocoon.woody.Constants;
   import org.apache.avalon.framework.configuration.Configurable;
   import org.apache.avalon.framework.configuration.Configuration;
   import org.apache.avalon.framework.configuration.ConfigurationException;
   import org.apache.avalon.framework.service.ServiceException;
  -import org.apache.avalon.framework.service.Serviceable;
   import org.apache.avalon.framework.service.ServiceManager;
  -import org.apache.excalibur.source.Source;
  -import org.apache.excalibur.source.SourceResolver;
  +import org.apache.avalon.framework.service.Serviceable;
  +import org.apache.cocoon.woody.Constants;
  +import org.apache.cocoon.woody.datatype.DatatypeBuilder;
  +import org.apache.cocoon.woody.datatype.DatatypeManager;
  +import org.apache.cocoon.woody.datatype.ValidationRule;
  +import org.apache.cocoon.woody.datatype.convertor.Convertor;
  +import org.apache.cocoon.woody.datatype.convertor.ConvertorBuilder;
  +import org.apache.cocoon.woody.util.DomHelper;
  +import org.apache.cocoon.woody.util.SimpleServiceSelector;
   import org.w3c.dom.Element;
  -import java.io.IOException;
   
   /**
* Abstract base class for datatype builders, most concrete datatype builders
  
  
  

[RT] Revisiting Woody's form definition

[Sylvain Wallez]

Hi all,

One week after my first RT about Woody, after having read Marc and 
Bruno's answers and after lots of background thinking high in the 
mountain, here comes some more about Woody. I have abandoned (for now?) 
my idea of "form-defining template" which seems not so intuitive nor 
realistic, and tackled the problem of reuse and distribution of the 
various concerns between the different configuraiton files. So let's go...

From a developper point of view, two of the main usability differences 
between Woody and XMLForm are that :
1/ XMLForm doesn't require datatypes to be declared, since it relies on 
JXPath's (limited) parsing features to parse values.
2/ Woody requires forms to be defined separately from their usage (i.e. 
the form template) while XMLForm defines forms "inline" without 
requiring a separate file.

These differences, implied by Woody's greater structuration and 
validation features introduces some usage "heaviness" (see my previous 
RT). Now isn't it possible to make Woody's more lightweight without 
sacrificing any of its features ? My opinion is yes, and this RT 
proposes some modifications towards this goal.

Please read the whole thing before replying, since after the analysis 
come some more concrete proposals !

   +---+
   | Analysis of a Woody field |
   +---+
Let's split a Woody field into its various components (repeaters are a 
special case that will be considered separately) to find out how we can 
reorganize the form definition, template and binding.

Considering all Woody files, a field is composed of :
- a base datatype (string, integer, boolean, etc) and its constraints 
(range, regexp pattern, etc)
- convertors (conversion between a typed value and its string 
representation)
- a selection list of possible values
- visual elements (label, hint, hotkey, etc)
- styling data (foreing markup inside  in the form template)
- a binding to application data

Base type and its constraints
-
A field's datatype is defined by a base type (integer, date, boolean, 
etc) and some validation constraints (length, range, regexp pattern, etc).

Such datatypes are very likely to belong to the application model 
domain, and a given datatype is very likely to be used by several fields 
and in several forms. We could thus clearly benefit of having some 
form-independent datatypes catalogues, ensuring overall consistency.

Example (leaving out namespaces) :

 
   
 

We can then define a field using :

 

or even, if no additional elements are required inside the 

Separating the datatypes dictionary would also allow to use other type 
definition languages, such as XMLSchema datatype (i.e.  
declarations). When forms are used to edit XML documents, this can avoid 
the need to rewrite the existing schema into a Woody-speficic 
definition, with all the implied consistency and maintainability burdens.

Of course, there will be some fields whose datatype will not be reused. 
For these, the current definition ( inside ) is still 
valid, and can be considered as an anonymous inline datatype. 
Furthermore, validations can be chained : a field can define constraints 
that augment those defined on a datatype. Let's consider the password 
example :

Datatypes dictionary :

 
   

 

Form definition :

 
   
 
   The passwords must be equal
 
   
 


Convertors
--
Convertors (or should it be "converters" ?) define the locale-dependent 
conversions between a value and its string representation. This is where 
e.g. date formats are defined. Currently, Woody defines converters 
inside  which is inside . But if we separate datatypes 
as suggested above, do converters belong to fields or to datatypes ?

In my opinion, to neither and to both :
- to neither, because just as datatypes are independent from fields, 
convertors act on a particular base type (double, date, etc) and have no 
relationships with the particular constraints defined by a datatype nor 
with any particular form field. So just as for datatypes, we can thus 
have a format catalogue reused by several forms and/or datatypes.
- to both, because a datatype may have a "default" or "preferred" 
converter, but still leave room for a particular field to use a special 
custom format.

The format catalogue could then be composed of formats as in the 
following example :

 MM/dd/
 dd/MM/


We can then have a field defined using :

 
 

Or even 

With "past-date" being defined as

 

 

As for datatypes, formats for which reuse is not envisioned can be 
inlined inside the datatype or field definition.

Selection list
--
Selection lists define an enumeration in which the user has to choose a 
value.

Selection lists currently can be defined in datatypes, but it may make 
sense for fields to also allow selection lists, thus restricting the 
values allowed by their datatypes. If both the datatype a

[2.1cvs][flow] Properties files cannot be located?

[Steven Cummings]

Hello,

Is it possible for javascript code in the flow engine to locate properties
files that it might need. I have a JAXBContext that I'm trying to use from the
javascript and i get 

javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package
my.jaxb.package

Any immediate ideas? TIA

/S


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[Jeff Turner]

On Mon, Jul 28, 2003 at 03:46:49PM +0200, Sylvain Wallez wrote:
> Hi team,
> 
> I'd like to propose two people for Cocoon committership : Ugo Cei and 
> Marc Portier.

+1 and +1 

--Jeff

> -- 
> 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
> 
> 

DO NOT REPLY [Bug 21925] - FOM Request object does not provide access to all the request's values

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925

FOM Request object does not provide access to all the request's values





--- Additional Comments From [EMAIL PROTECTED]  2003-07-28 22:22 ---
Created an attachment (id=7553)
Rest of missing functions

DO NOT REPLY [Bug 21925] - FOM Request object does not provide access to all the request's values

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925

FOM Request object does not provide access to all the request's values

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-07-28 22:23 ---
I've attached a patch with the rest of the missing FOM_Request functions.
Hope it's not too late for inclusion before tomorrow's code freeze.

DO NOT REPLY [Bug 21925] - FOM Request object does not provide access to all the request's values

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925

FOM Request object does not provide access to all the request's values

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-07-28 22:58 ---
But setting status to FIXED before the patch is applied is not so good - could
get lost.

DO NOT REPLY [Bug 21925] - FOM Request object does not provide access to all the request's values

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925

FOM Request object does not provide access to all the request's values

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|NEW

Re: [2.1cvs][flow] Properties files cannot be located?

[Vadim Gritsenko]

Steven Cummings wrote:

Hello,

Is it possible for javascript code in the flow engine to locate properties
files that it might need. I have a JAXBContext that I'm trying to use from the
javascript and i get 

javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package
my.jaxb.package
Any immediate ideas? TIA

IIRC: Have your properties in 
WEB-INF/classes/my/jaxb/package/jaxb.properties. Jaxb uses classloader 
to locate properties.

(OT?)

Vadim

Re: [2.1cvs][flow] Properties files cannot be located?

[Steven Cummings]

--- Vadim Gritsenko <[EMAIL PROTECTED]> wrote:
> Steven Cummings wrote:
> 
> >Hello,
> >
> >Is it possible for javascript code in the flow engine to locate properties
> >files that it might need. I have a JAXBContext that I'm trying to use from
> the
> >javascript and i get 
> >
> >javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package
> >my.jaxb.package
> >
> >Any immediate ideas? TIA
> >
> 
> IIRC: Have your properties in 
> WEB-INF/classes/my/jaxb/package/jaxb.properties. Jaxb uses classloader 
> to locate properties.

Actually I've tried both, unpacked in classes and in the original jar in lib.
Neither works through flow. But my JAXB works otherwise, so I don't think it's
as simple as that.

> 
> (OT?)

Off topic? I hope not, I started it! I just thought it would be more
appropriate for the dev-list since it is still changing. Sorry if it's not!

> 
> Vadim
> 
> 

/S

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [RT] Webdavapps with Cocoon

[Vadim Gritsenko]

Stefano Mazzocchi wrote:

On Monday, Jul 28, 2003, at 14:23 Europe/Rome, Sylvain Wallez wrote:
...


In other words, streamed requests aren't so much different from 
regular requests : it's just that incoming data is more complex and 
that decoding is not handled transparently by the servlet engine. 
Once decoded, the processing model can be the same as usual.


Hmmm, h, h, you are triggering second order thinking 
h... I need a whiteboard... I'll be back soon. 


Are you thinking in terms of "MultipartParser, SOAPParser, ..."?

Vadim

Re: [2.1cvs][flow] Properties files cannot be located?

[Vadim Gritsenko]

Steven Cummings wrote:

--- Vadim Gritsenko <[EMAIL PROTECTED]> wrote:
 

Steven Cummings wrote:

   

Hello,

Is it possible for javascript code in the flow engine to locate properties
files that it might need. I have a JAXBContext that I'm trying to use from
 

the
   

javascript and i get 

javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package
my.jaxb.package
Any immediate ideas? TIA

 

IIRC: Have your properties in 
WEB-INF/classes/my/jaxb/package/jaxb.properties. Jaxb uses classloader 
to locate properties.
   

Actually I've tried both, unpacked in classes and in the original jar in lib.
Neither works through flow. But my JAXB works otherwise, so I don't think it's
as simple as that.
 

Does not work through flow but works through, say, XSP? Then it might be 
some flow related issue.

Vadim

cvs commit: cocoon-2.1/lib jars.xml

[vgritsenko]

vgritsenko2003/07/28 19:07:32

  Modified:.status.xml
   lib  jars.xml
  Added:   src/blocks/fop/lib fop-0.20.5.jar
  Removed: src/blocks/fop/lib fop-0.20.5rc3a.jar
  Log:
  Update FOP to the released version.
  Update todo list: remove some items.
  
  Revision  ChangesPath
  1.97  +11 -30cocoon-2.1/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/status.xml,v
  retrieving revision 1.96
  retrieving revision 1.97
  diff -u -r1.96 -r1.97
  --- status.xml28 Jul 2003 11:28:22 -  1.96
  +++ status.xml29 Jul 2003 02:07:31 -  1.97
  @@ -7,7 +7,7 @@
   
   
   
  -  
  + 
   
 
 
  @@ -51,7 +51,7 @@
 
 
 
  -  
  + 
 
 
  
  @@ -70,13 +70,9 @@
   
   
   
  -  For 2.1: use (only) released versions of excalibur (xml, source, store etc).
  -  This requires a release of those components in excalibur.
  -
  -
  -
  -  Complete (means put everything we know of into even if it has to be
  -  commented) the cocoon.xconf file and put descriptions into it
  +  For 2.1: use (only) released versions of excalibur (collections,
  +  concurrent, source, store, xmlutil). This requires a release of those
  +  components in excalibur.
   
   
   
  @@ -92,7 +88,7 @@
   
 For 2.1: Make comprehensive samples with the handle-errors sitemap and real 
world
 use cases. Add also specific Selector and a FaqBuilder to be used by the
  -  as a NotifyingBuilder.
  +  NotifyingBuilder.
   
   
   
  @@ -112,18 +108,6 @@
   
   
   
  -  Move complete Source implementation to Excalibur.
  -
  -
  -
  -  Documentation to be published by Forrest.
  -  See the
  -  http://wiki.cocoondev.org/Wiki.jsp?page=ForrestProposal";>proposal
  -  under development. (Note: the generation of the docs should be completely 
done by
  -  Forrest. So we should remove the deprecated docs generation stuff within 
Cocoon.)
  -
  -
  -
 Finish moving the scratchpad stuff in main trunk.
   
   
  @@ -145,7 +129,6 @@
 a problem during the serialization of the transient store, if the servlet 
container were
 stopped.
   
  -
  
   
  
  @@ -167,13 +150,8 @@
   
   
   
  -
  -  For 2.1: Make a guide on how to upgrade Cocoon, and see how this can be eased.
  -
  -
  -
 For 2.1: Redesign FragmentExtractorGenerator/Transformer so that it works on 
a clustered
  -  server : store fragments in the session rather than in a local store. 
  +  server: store fragments in the session rather than in a local store. 
 This couldn't work, because if you working with caching pipelines, you cannot 
be sure
 that the entries are in the session(Stephan).
   
  @@ -189,6 +167,9 @@
 
   

  +  
  +Updated FOP to the latest released version, 0.20.5.
  +  
 
   Added delete capabilities to the SourceWritingTransformer.
 
  
  
  
  1.1  cocoon-2.1/src/blocks/fop/lib/fop-0.20.5.jar
  
<>
  
  
  1.71  +2 -2  cocoon-2.1/lib/jars.xml
  
  Index: jars.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/lib/jars.xml,v
  retrieving revision 1.70
  retrieving revision 1.71
  diff -u -r1.70 -r1.71
  --- jars.xml  26 Jul 2003 13:26:47 -  1.70
  +++ jars.xml  29 Jul 2003 02:07:32 -  1.71
  @@ -430,7 +430,7 @@
  the XSL recommendation and then turns it into a PDF document.
 
 FOP serializer (fop block)
  -  fop/lib/fop-0.20.5rc3a.jar
  +  fop/lib/fop-0.20.5.jar
 http://xml.apache.org/fop/

   
  
  
  

Re: [2.1cvs][flow] Properties files cannot be located?

[Steven Cummings]

--- Vadim Gritsenko <[EMAIL PROTECTED]> wrote:
> Steven Cummings wrote:
> 
> >--- Vadim Gritsenko <[EMAIL PROTECTED]> wrote:
> >  
> >
> >>Steven Cummings wrote:
> >>
> >>
> >>
> >>>Hello,
> >>>
> >>>Is it possible for javascript code in the flow engine to locate properties
> >>>files that it might need. I have a JAXBContext that I'm trying to use from
> >>>  
> >>>
> >>the
> >>
> >>
> >>>javascript and i get 
> >>>
> >>>javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package
> >>>my.jaxb.package
> >>>
> >>>Any immediate ideas? TIA
> >>>
> >>>  
> >>>
> >>IIRC: Have your properties in 
> >>WEB-INF/classes/my/jaxb/package/jaxb.properties. Jaxb uses classloader 
> >>to locate properties.
> >>
> >>
> >
> >Actually I've tried both, unpacked in classes and in the original jar in
> lib.
> >Neither works through flow. But my JAXB works otherwise, so I don't think
> it's
> >as simple as that.
> >  
> >
> 
> Does not work through flow but works through, say, XSP? Then it might be 
> some flow related issue.
> 
> Vadim
> 
> 

I've not used XSP, but I have used actions. I'm going to just try implementing
my form-wizard as an action like in the samples instead of flow for now and try
flow again later (after I've met my deadlines!). One last question, I've
noticed in cvs there's "javascript" flow using FOM and the older "JavaScript"
engine. What are the differences there (just in case it would matter)?

/S


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

cvs commit: cocoon-2.1/src/webapp/samples/i18n/translations menu.xml menu_de.xml menu_el.xml menu_en.xml menu_in.xml menu_ja.xml menu_ko.xml menu_ru.xml menu_zh_CN.xml menu_zh_TW.xml messages.xml messages_de.xml messages_el.xml messages_en.xml messages_es.xml messages_fr.xml messages_fr_CH.xml messages_hy.xml messages_in.xml messages_ja.xml messages_ko.xml messages_pl.xml messages_pt.xml messages_ru.xml messages_tr.xml messages_zh_CN.xml messages_zh_TW.xml

[vgritsenko]

vgritsenko2003/07/28 19:36:31

  Modified:src/webapp/samples/i18n/translations menu.xml menu_de.xml
menu_el.xml menu_en.xml menu_in.xml menu_ja.xml
menu_ko.xml menu_ru.xml menu_zh_CN.xml
menu_zh_TW.xml messages.xml messages_de.xml
messages_el.xml messages_en.xml messages_es.xml
messages_fr.xml messages_fr_CH.xml messages_hy.xml
messages_in.xml messages_ja.xml messages_ko.xml
messages_pl.xml messages_pt.xml messages_ru.xml
messages_tr.xml messages_zh_CN.xml
messages_zh_TW.xml
  Log:
  Update japanese translation.
  Changed file headers to corporate standard while I was at it.
  Submitted by: Tetsuya Kitahata <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.2   +7 -2  cocoon-2.1/src/webapp/samples/i18n/translations/menu.xml
  
  Index: menu.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/menu.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- menu.xml  9 Mar 2003 00:11:11 -   1.1
  +++ menu.xml  29 Jul 2003 02:36:30 -  1.2
  @@ -1,6 +1,11 @@
   
  -
  -
  +
  +
  +
   
   Apache Cocoon i18n Samples
   Samples
  
  
  
  1.2   +6 -2  cocoon-2.1/src/webapp/samples/i18n/translations/menu_de.xml
  
  Index: menu_de.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/menu_de.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- menu_de.xml   26 Mar 2003 07:32:20 -  1.1
  +++ menu_de.xml   29 Jul 2003 02:36:30 -  1.2
  @@ -1,6 +1,10 @@
   
  -
  -
  +
  +
   
   
   Apache Cocoon i18n Beispiele
  
  
  
  1.2   +7 -3  cocoon-2.1/src/webapp/samples/i18n/translations/menu_el.xml
  
  Index: menu_el.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/menu_el.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- menu_el.xml   9 Mar 2003 00:11:11 -   1.1
  +++ menu_el.xml   29 Jul 2003 02:36:30 -  1.2
  @@ -1,7 +1,11 @@
   
  -
  -
  -
  +
  +
  +
   
Apache Cocoon i18n 
Παραδείγματα
Παραδείγματα
  
  
  
  1.2   +7 -2  cocoon-2.1/src/webapp/samples/i18n/translations/menu_en.xml
  
  Index: menu_en.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/menu_en.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- menu_en.xml   9 Mar 2003 00:11:11 -   1.1
  +++ menu_en.xml   29 Jul 2003 02:36:30 -  1.2
  @@ -1,6 +1,11 @@
   
  -
  -
  +
  +
  +
   
   Apache Cocoon i18n Samples
   Samples
  
  
  
  1.2   +7 -2  cocoon-2.1/src/webapp/samples/i18n/translations/menu_in.xml
  
  Index: menu_in.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/menu_in.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- menu_in.xml   26 Mar 2003 07:32:20 -  1.1
  +++ menu_in.xml   29 Jul 2003 02:36:30 -  1.2
  @@ -1,6 +1,11 @@
   
  -
  -
  +
  +
  +
   
   Contoh Apache Cocoon i18n
   Contoh
  
  
  
  1.2   +21 -16cocoon-2.1/src/webapp/samples/i18n/translations/menu_ja.xml
  
  Index: menu_ja.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/menu_ja.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- menu_ja.xml   9 Mar 2003 00:11:11 -   1.1
  +++ menu_ja.xml   29 Jul 2003 02:36:30 -  1.2
  @@ -1,19 +1,24 @@
   
  -
  -
  +
  +
  +
   
  -アパチ　コクン　国際化　例題
  -例題
  -入門
  -静的 (XML)
  -動的 (XSP)
  -サイトマップ　ソース
  -言語設定
  -文書
  -国際化変換機文書
  -国際化変換機文書 
ジャヴァドク
  -LocaleAction ジャヴァドク
  -提供者
  -コンスタンチン　ピオルミアン
  -その外の沢山の方々。。。
  +Apache Cocoon 
国際化サンプル
  +サンプル
  +始めに
  +スタティック(XML)
  +ダイナミック(XSP)
  +サイトマップ・ソース
  +ロケール
  +ドキュメント
  +i18nトランスフォーマ文書
  +i18nトランスフォーマJavaDoc
  +LocaleAction JavaDoc
  +謝辞
  +コンスタンティン・ピルミャン
  +その他大勢の方々...
   
  
  
  
  1.2   +7 -2  cocoon-2.1/src/webapp/samples/i18n/translations/menu_ko.xml
  
  Index: menu_ko.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/menu_ko.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  

Re: [PATCH] japanized src/webapp/samples/i18n/translations/

[Vadim Gritsenko]

Tetsuya Kitahata wrote:

Hello, Cocoon-ers!

I modified sample i18n menu and message of japanese found at
/home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/
Here I put (attached) a zipped file named "i18n_japanized_sample.zip",
which contains:
1. messages_ja.xml
2. menu_ja.xml
 

Ok, checked in, but I have no even slightest idea what's in these files. 
So I suggest you to check that everything is ok now.

PS Windows notepad (my guess you have used it) adds some gibberish in 
front of the files which does not make valid xml file -- I've removed this

Vadim

Re: [RT] Updating our marketing strategy

[Vadim Gritsenko]

Stefano Mazzocchi wrote:

Cocoon is glue and duct tape for your web needs.
...

I propose to choose the humble one.


I guess we are all agree with your RT. What's next -- what we are going 
to update? :)

Vadim

cvs commit: cocoon-2.1/src/webapp/samples/xinclude sitemap.xmap

[vgritsenko]

vgritsenko2003/07/28 20:15:48

  Modified:src/blocks/authentication-fw/conf authentication-gen.xmap
   src/blocks/authentication-fw/samples sitemap.xmap
   src/blocks/batik/conf svg.generation.xmap
   src/blocks/batik/samples sitemap.xmap
   src/blocks/bsf/conf bsf.xmap
   src/blocks/databases/samples sitemap.xmap
   src/blocks/fop/samples sitemap.xmap
   src/blocks/html/conf tidy.xmap
   src/blocks/html/samples sitemap.xmap
   src/blocks/jsp/conf jsp.generator.xmap
   src/blocks/linotype/samples sitemap.source.xmap sitemap.xmap
   src/blocks/mail/samples sitemap.xmap
   src/blocks/petstore/samples sitemap.xmap
   src/blocks/php/conf php.xmap
   src/blocks/poi/samples sitemap.xmap
   src/blocks/portal-fw/conf portal-gen.xmap
   src/blocks/profiler/conf profiler.xmap
   src/blocks/profiler/samples sitemap.xmap
   src/blocks/proxy/conf proxy.xmap wsproxy.xmap
   src/blocks/slide/conf slide-generator.xmap
   src/blocks/slide/samples sitemap.xmap
   src/blocks/velocity/conf velocity.xmap
   src/blocks/web3/samples sitemap.xmap
   src/blocks/woody/samples sitemap.xmap
   src/blocks/xmldb/conf xmldb.deprecated.xmap
   src/webapp sitemap.xmap
   src/webapp/samples sitemap.xmap
   src/webapp/samples/hello-world sitemap.xmap
   src/webapp/samples/i18n sitemap.xmap
   src/webapp/samples/simpleform sitemap.xmap
   src/webapp/samples/sites sitemap.xmap
   src/webapp/samples/sources sitemap.xmap
   src/webapp/samples/stream sitemap.xmap
   src/webapp/samples/xinclude sitemap.xmap
  Log:
  Add views definitions to the samples sitemaps.
  Removed label "data", it was almost identical to label "content".
  "data" was used by "content" view, "content" was used by "pretty-content"
  (or was it the other way?). Now both views use same label which makes more sense.
  
  Revision  ChangesPath
  1.3   +1 -1  
cocoon-2.1/src/blocks/authentication-fw/conf/authentication-gen.xmap
  
  Index: authentication-gen.xmap
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/authentication-fw/conf/authentication-gen.xmap,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- authentication-gen.xmap   3 May 2003 16:12:23 -   1.2
  +++ authentication-gen.xmap   29 Jul 2003 03:15:45 -  1.3
  @@ -5,5 +5,5 @@
   
   
  +   label="content"/>
   
  
  
  
  1.5   +61 -72cocoon-2.1/src/blocks/authentication-fw/samples/sitemap.xmap
  
  Index: sitemap.xmap
  ===
  RCS file: /home/cvs/cocoon-2.1/src/blocks/authentication-fw/samples/sitemap.xmap,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- sitemap.xmap  26 May 2003 07:54:09 -  1.4
  +++ sitemap.xmap  29 Jul 2003 03:15:45 -  1.5
  @@ -1,35 +1,27 @@
   
   
  -http://apache.org/cocoon/sitemap/1.0";>
  -
  -
  - 
  -
  -  
  -  
  -  
  -  
  -  
  -  
  - 
  +
   
  +http://apache.org/cocoon/sitemap/1.0";>
   
   
  +  
  +
  +  
  +
  +  
  +
  +
  +  
  +
  +  
  +
   
  - 
  -  
  -  
  -
  -  
  - 
  - 
  -  
  - 
  -   
  -  
  -
  -  
  -
  +
 
   
 
  @@ -39,13 +31,13 @@
 
 
   
  - 
  -  
  - 
  -  
  -
  - 
  - 
  +
  +   
  +  
  + 
  +
  +
  +
   
 
   
  @@ -53,59 +45,56 @@
 
 
 
  -
  - 
  - 
  - 
  - 
  -   
  -
  -
  +
  +
  +  
  +  
  +  
  +
  +
  +
 
   
 
 
 
 
  - 
  -  
  +
  +   
   
  -
  -
  - 
  - 
  -
  -
  -
  -
  +  
  +  
  +  
  +  
  +  
  +
  +
  +
 
   
 
 
 
 
  - 
  -  
  +
  +   
   
  -
  -
  -
  -  
  -
  -  
  -
  -  
  -
  - 
  - 
  - 
  - 
  -   

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

[David Crossley]

Sylvain Wallez wrote:
> Hi team,
> 
> I'd like to propose two people for Cocoon committership : Ugo Cei and 
> Marc Portier.
> 
> Ugo has been there for years (the archives show his first post back in 
> July 2000!), has been an early adopter of flowscript and wrote the first 
> Cocoon-based blogging tool.

+1

> Marc is working intensively on the binding and flowscript integrations 
> of Woody and cares a lot about Cocoon.

+1

--David

DO NOT REPLY [PATCH QUEUE] Summary July 29 2003

[nicolaken]

---
 This mail is generated automatically using
 Jakarta Ant. Contents are automatically
 downloaded from Apache's Bugzilla.
---
 Please do not reply to this mail.
---

***
COCOON PATCH QUEUE UPDATE
 
patches in queue:  36 
***


---
13070:[PATCH] Add a new tag  to XSP
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13070

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
17063:[PATCH] XSP Request docs, demo out of sync with logicsheet
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17063

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
9728:[PATCH] CocoonServlet getClassPath() enhancements Tomcat4
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9728

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
12173:[PATCH] SQLTransformer Query object prematurely closes conne
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12173

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
14144:[Patch] add CompressionFilter declaration to web.xml
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14144

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
14845:[PATCH] Patch to generate a key with new resources in XMLDBT
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14845

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
15100:[patch]/[donation] Sample app xml form popup with sourcewrit
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15100

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
15150:[PATCH]: HSSFSerializer Support for Gnumeric MergedRegions
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15150

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
16537:[PATCH] fixed redirect under JRun 3.1
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16537

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
16718:[PATCH] Using only one connection in SQLTransformer
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16718

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
17771:[PATCH] new logging category never set when using log logics
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17771

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
19138:[Contrib]/[Patch] Made SQLTransformer paginatable.
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19138

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
19638:[PATCH] Same cell definitions blows document (problem with
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19638

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
19641:[PATCH] HSSFSerializer Support for FreezePane
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19641

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
20033:[PATCH]LDAPTransformer patch
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20033

REVIEWER:[EMAIL PROTECTED]
RESOLUTIO

RE: CODE FREEZE for 2.1rc1

[Carsten Ziegeler]

Sylvain Wallez wrote:
> >
> >PS: and put the champaigne into the fridge.
> >
> 
> It's spelled "champagne" ! Wines are serious things in France ;-)
> 
Oh, what a faux pas - sorry for that one, Sylvain! Now, I guess
the best thing in helping me to spell this one correctly in the
future, is to offer me one or two bottles the next time we meet.
I'm sure then, I will not do that again :)

Carsten