Re: Garbage or The Quest for the Perfect Template Language

[Ugo Cei]

Christopher Oliver wrote:
Ugo Cei wrote:

These days I'm banging my head against the limitations of template
languages. I've tried XSP and it's not in any way limited, but it has
its share of problems (difficult to debug and offers too many ways to
shoot oneself in the foot), JXTemplate{Transformer,Generator} (no way to
call methods on context objects, no decent arithmetic) 


What exactly is the problem with the arithmetic in Jexl and/or JXPath? 
What problem did you encounter calling methods? You should be able to 
with do that with both Jexl and JXPath.

Regards,

Chris
I'll try to come up with an example but I seem to remember having 
problems doing even a simple counter. And WRT calling Java methods, I 
must admit I didn't even try it. Since it's not documented I thought it 
wasn't even implemented ;-).

	Ugo

--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED]

Apache newsletter in progress

[Steven Noels]

fyi: Tetsuya Kitahata is in the process of preparing the first 
all-Apache newsletter, and his late work on the Jakarta newsletter sure 
makes it warrant some attention.

I added a little statement as to how the Cocoon project is faring on the 
draft Wiki version: 
http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue1

If there's anything completely wrong or stuff you really want to be 
added, please LMK.

Cheers,


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

DO NOT REPLY [Bug 14348] - Caching problem with XSP, XSL and cocoon pseudo protocol

[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=14348

Caching problem with XSP, XSL and cocoon pseudo protocol





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 07:51 ---
the bug is the way SitemapSource (here cocoon:/bar) computes its last modified 
date; it hashes a combination of the event pipeline's cache key and the 
corresponding validity. this yields (in most cases?) a negative number. when 
ProgramGeneratorImpl checks the xsp's creation date against the source's last 
modified date it 'finds out' that the xsp is 'newer' and must be updated.

in cocoon 2.1 (from a quick look at a checkout) the SitemapSource just returns 
0; can't determine. which means that recompilation of the XSP would be done 
here also.


so, the solution is to get a valid last modification date for the 
SitemapSource, for which there are probably many ways, e.g.

- store the creation/modification date for a cached stream/event pipeline, and 
make it accessible
- store that date and the pipeline's validity in transient cache and later on 
check previous (stored) validity against current validity and if validity 
changed, update last modified and store validity

I've tried the latter one. if there's any interest I could provide a patch.

DO NOT REPLY [Bug 14348] - Caching problem with XSP, XSL and cocoon pseudo protocol

[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=14348

Caching problem with XSP, XSL and cocoon pseudo protocol





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 08:00 ---
correction:

since the xsp's creation date is 'newer' it isn't updated.

Promotion of [XPath]TraversableGenerators to main trunk

[Gianugo Rabellino]

Before the upcoming release, I'd like to promote the 
TraversableGenerator stuff to the main trunk. There are several things 
to discuss, though:

1. naming. TraversableGenerator sucks, yes. I guess the best option as 
of now is SourceHierarchyGenerator, any others?

2. merge Sylvain's stuff (caching, directory filter...). Sylvain, do you 
think you can take care of that?

3. namespace: is http://apache.org/cocoon/collection/1.0 ok?

4. back-compatibility: should we deprecate DirectoryGenerator? Should we 
provide a stylesheet to convert the output of Traversable to Directory's?

5. xpath: I'm starting to wonder whether is OK to have a separate 
XPathTraversableGenerator or if it would be better having a single 
SourceHierarchyGenerator with (optional) XPath capabilities. How about it?

Let's discuss all these issue (and I might well have forgotten some): I 
think that at a very least we need a [VOTE] on the namespace afterwards.

--
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: Garbage or The Quest for the Perfect Template Language

[Sylvain Wallez]

Ugo Cei wrote:

Christopher Oliver wrote:

Ugo Cei wrote:

These days I'm banging my head against the limitations of template
languages. I've tried XSP and it's not in any way limited, but it has
its share of problems (difficult to debug and offers too many ways to
shoot oneself in the foot), JXTemplate{Transformer,Generator} (no 
way to
call methods on context objects, no decent arithmetic) 


What exactly is the problem with the arithmetic in Jexl and/or 
JXPath? What problem did you encounter calling methods? You should be 
able to with do that with both Jexl and JXPath.

Regards,

Chris


I'll try to come up with an example but I seem to remember having 
problems doing even a simple counter. And WRT calling Java methods, I 
must admit I didn't even try it. Since it's not documented I thought 
it wasn't even implemented ;-).


Checkout the last paragraph of JXPath's PackageFunctions description 
[1], this may be what you're looking for : the whole classpath is 
accessible through fully-qualified names.

[1] 
http://jakarta.apache.org/commons/jxpath/apidocs/org/apache/commons/jxpath/PackageFunctions.html 

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

[Vote] Make Xalan the default xslt processor again [was: RE: Releasing 2.1]

[Carsten Ziegeler]

There are several problems with xsltc which makes Cocoon in some
scenarios unusable. We have several problem reports and I know
from many customers that they all had to disable xsltc and use
xslt in their environment.

It's ok to have xsltc as the default for development cycles to
help the xalan team find bugs, but I think it's not good to
have it as the default for the final release as most users
have to change this default setting anyway.

So, I'm +1 on making xalan the default for the final release again.

What do you think?

Carsten

Simon Hürlimann wrote:
>
> Am Donnerstag, 31. Juli 2003 17.46 schrieb Joerg Heinicke:
> > Some issues:
> >
> > 1. POI: No real problem, but what about the code move to the POI
> > project? They seem to prepare the 2.0 release, so I guess they only have
> > no time at the moment ...
> >
> > 2. XSLTC: Geoff already mentioned it. I know of two heavy bugs in our
> > 2.5.1 XSLTC:
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20308 : stylesheet
> > includes, seems to be already fixed in XSLTC CVS.
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20381 : top-level
> > variable with document(). This bug is so annoying because the stylesheet
> > "works" in a way, but the cause of the failure is not obvious. And we
> > don't know the reason for it until now: XSLTC command line works, Xalan
> > works. But if we switch from Xalan to XSLTC in Cocoon the stylesheet
> > stops working.
>
> There's another XSLTC Bug that affects Cocoon. If you use a
> cocoon:/ URL in
> XSLTs document() function, the URI is prepended by the
> stylesheets path. That
> was a realy annoying bug that took me quite some time. The only "fix" for
> this bug is to switch back to Xalan:
>   http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21857

RE: [RT] New Input for woody

[Carsten Ziegeler]

Marc Portier wrote:
> 
> 
> as I understood from earlier discussions this also serves as a 
> form-model-definition (meaning dywel doesn't require an aditional 
> file for that)
More or less: yes - you need the "binding".

> > 
> > How does it work? A component (a java implementation) parses
> > the template and the binding file, the first time it's used.
> > The template is compiled and the bindings are attached to
> > the internal tree representing the template.
> > 
> 
> could you elaborate on 'attached'
> is an instance of the business object involved in this process?
No, a tree is created is created with java objects for the different
elements or fields used. So you have a java object representing
one particular input field. This object gets the binding, so
it knows from where to get it's input. But this is only the
definition, so the object does not get the business object
itself only the string like "user.name".

> > A special generator uses the java component and asks it to
> > render the page. Now the tree is processed. Each field
> > knows how to render itself. To get the values for a
> > form field, the field asks the component for the
> > value for e.g. "user.name". The component now has
> > a getUser() method and the returned user object has
> > a getName() method.
> > 
> 
> this sounds like the business object instance values are only 
> read at this time...
> 
Exactly. The tree I mentioned above is traversed and the java
object for the field gets a "component" and can ask that
component for the value of let's say "user.name".

> 
> > For each form or better web page, you have to write
> > the java component = controller. You simply inherit
> > from a base class and provided methods to get your
> > business objects. (I'm looking to simplify this using
> > fom when everything else is set).
> > So, this solution is tied to java objects (currently).
> > 
> 
> well, it is tied to a custom-to-be-written java object
> 
> from a distance it looks like you'll need some luck for hooking 
> up some existing java objects from a long-before-dywel designed 
> business application (e.g. the validation method, but also the 
> type of the argument in the setXXX methods, the web is presenting 
> you with Strings, how is the conversion done? <-- this is the 
> crux of my current understanding of dywel)
Ah, ok, you don't need something in between you can directly connect
to existing business objects. E.g. JXPath can do most of the
conversions for you, if you have a string with a number and have
a setAge(int) the conversion is done for you automatically etc.
So most conversions can be done by that, you can set optional
formatter objects in the binding that do the conversion for you,
e.g. for date objects.

> 
> if that is the case then one is going to need to write a specific 
> javabean to accomodate for the intermediate step before actually 
> talking to the legacy backend system
No, as explained above.

> 
> woody's proposition is to use not Java code but the 
> form-definition file to describe this intermediate model... AFAIU 
> both approaches use this kind of intermediate stage as a basis 
> for validation and string-type conversion
> 
> (remembering Bruno's recent rumblings on jxpath addressing inside 
> form-widgets the line could get very thin)
> 
> > Now, it is possible to specify additional validation and
> > formatting in the binding, like:
> >   
> > user.address.city
> > a rule
> > a formatter
> >   
> > 
> > etc.
> 
> similar
> 
> I'm still looking for the reverse of the formatter (string to type?)
The formatter does both.

> 
> As I see it now, the integration is not trivial (but possible)
> Your bean seems to provide an alternative to the declarative 
> woody-widget tree (form-model)
> 
> We could argue about the woody-widget tree being the real CORE of 
> woody, so the 'not trivial' gets to have some meaning I guess :-)
> 
> 'Integration' then becomes making the form-model pluggable which 
>   would come down to
> 1/ making the woody-template-transformer can pull out the values 
> using jxpath rather then using the widget API
> 2/ and the other way around the form.process(request) needs to 
> evolve to Dywel.process(bean-or-widgetTree, request); which could 
> again use some jxpath-like approach to perform its setValues...
> 
> not trivial, maybe possible, useful?
Hmm, I'm a little unsure. Now, I don't want to destroy the design
of woody only to make me happy. If it makes sense, to change
woody: great. If it doesn't, well, then I can live with that
as well. It's a decision I'm currently not able to make or
contribute to.

I think, currently if Dywel will ever work sometime in the distant
future, it's more elegant to connect to existing business objects
than woody; but on the other hand woody has great advantage in
all the other form areas where you don't connect to business objects.

Carsten

Re: Garbage or The Quest for the Perfect Template Language

[Ugo Cei]

Sylvain Wallez wrote:
Checkout the last paragraph of JXPath's PackageFunctions description 
[1], this may be what you're looking for : the whole classpath is 
accessible through fully-qualified names.
Uh, cool. This deserves to be documented more clearly. I'll try to find 
the time to do it.

	Ugo

--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED]

RE: [Vote] Make Xalan the default xslt processor again [was: RE: Releasing 2.1]

[Reinhard Pötz]

From: Carsten Ziegeler
 
> There are several problems with xsltc which makes Cocoon in
> some scenarios unusable. We have several problem reports and 
> I know from many customers that they all had to disable xsltc 
> and use xslt in their environment.
> 
> It's ok to have xsltc as the default for development cycles
> to help the xalan team find bugs, but I think it's not good 
> to have it as the default for the final release as most users 
> have to change this default setting anyway.
> 
> So, I'm +1 on making xalan the default for the final release again

+1 too for the release (XSLTC is hell if you use namespaces)

then we should set XSLTC as default xslt processor again.

Cheers,
Reinhard

RE: Cocoon Schools of Development [was: Re: Cool (work)flow GUIeditor]

[Reinhard Pötz]

> For the actual code see 
> http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=21900

Marc, why don't you put Apples it into scratchpad?

Cheers,
Reinhard

RE: Releasing 2.1

[Reinhard Pötz]

From: Carsten Ziegeler

> I just want to collect opinions how to manage the final release.
> 
> Now, it seems 2.1rc1 is relative stable, no real complains,
> some minor issues but no showstoppers. From that we could 
> say: the current cvs is the final version. point. I don't 
> think we need a rc2.
> 
> Should we take before we do the release some actions? Like...
> ..updating docs ..changing readme ..asking users for testing 
> (which was a success for 2.0.3 and 2.0.4) etc.

IMO there are two important issues:
 
 - the docs must reflect that Cocoon is not a publishing framework
_only_
 - decide what we do with alpha blocks and scratchpad
   I would exclude them from the build properties by default

Cheers,
Reinhard

> 
> Whatever we do, I think a timeframe of two weeks is good, so
> I suggest a final release on tuesday, 12th.
> 
> Carsten
> 
> 

RE: Releasing 2.1

[Reinhard Pötz]

From: Carsten Ziegeler

> I just want to collect opinions how to manage the final release.
> 
> Now, it seems 2.1rc1 is relative stable, no real complains,
> some minor issues but no showstoppers. From that we could 
> say: the current cvs is the final version. point. I don't 
> think we need a rc2.
> 
> Should we take before we do the release some actions? Like...
> ..updating docs ..changing readme ..asking users for testing 
> (which was a success for 2.0.3 and 2.0.4) etc.

IMO there are two important issues:
 
 - the docs must reflect that Cocoon is not a publishing framework
_only_
 - decide what we do with alpha blocks and scratchpad
   I would exclude them from the build properties by default

Cheers,
Reinhard

> 
> Whatever we do, I think a timeframe of two weeks is good, so
> I suggest a final release on tuesday, 12th.
> 
> Carsten
> 
> 

Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUIeditor]

[Steven Noels]

On 1/08/2003 11:15 Reinhard Pötz wrote:

For the actual code see 
http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=21900


Marc, why don't you put Apples it into scratchpad?
Karma request is in process, he isn't listed in the avail file yet.


--
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: Cocoon Schools of Development [was: Re: Cool (work)flow GUIeditor]

[Reinhard Pötz]

From: Steven Noels

> On 1/08/2003 11:15 Reinhard Pötz wrote:
> > 
> >>For the actual code see
> >>http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=21900
> > 
> > 
> > Marc, why don't you put Apples it into scratchpad?
> 
> Karma request is in process, he isn't listed in the avail file yet.

Ah, thanks! I thought that those things have already happend.

Reinhard

DO NOT REPLY [Bug 22042] New: - [PATCH] LDAPTransformer

[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=22042

[PATCH] LDAPTransformer

   Summary: [PATCH] LDAPTransformer
   Product: Cocoon 2
   Version: 2.1m3
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Now LDAPTransformer supports 'modify attribute' and 'add attribute' methods.
'Modify attribute' method, in additional, supports the 'append' modify mode.
LDAPTransformer now can works without any search filter (with full path) also.

DO NOT REPLY [Bug 22042] - [PATCH] LDAPTransformer

[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=22042

[PATCH] LDAPTransformer





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 09:39 ---
Created an attachment (id=7612)
With this patch, LDAPTransformer supports the add and modify attribute methods

cvs commit: cocoon-2.1/src/blocks/jxforms/samples/wizard confirm.xml deployment.xml end.xml schematron.xml system.xml userIdentity.xml

[reinhard]

reinhard2003/08/01 02:39:27

  Modified:src/blocks/jxforms/samples sitemap.xmap
   src/blocks/jxforms/samples/stylesheets jxforms-default.xsl
wizard2html.xsl
   src/blocks/jxforms/samples/wizard confirm.xml deployment.xml
end.xml schematron.xml system.xml userIdentity.xml
  Log:
  - use standard stylesheet for presentation
  
  Revision  ChangesPath
  1.3   +5 -1  cocoon-2.1/src/blocks/jxforms/samples/sitemap.xmap
  
  Index: sitemap.xmap
  ===
  RCS file: /home/cvs/cocoon-2.1/src/blocks/jxforms/samples/sitemap.xmap,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- sitemap.xmap  20 Jul 2003 22:53:40 -  1.2
  +++ sitemap.xmap  1 Aug 2003 09:39:27 -   1.3
  @@ -75,7 +75,11 @@
  

  
  -   
  +   
  +
  +  
  +
  +  
   
  
   
  
  
  
  1.2   +11 -17
cocoon-2.1/src/blocks/jxforms/samples/stylesheets/jxforms-default.xsl
  
  Index: jxforms-default.xsl
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/jxforms/samples/stylesheets/jxforms-default.xsl,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jxforms-default.xsl   12 Jul 2003 19:22:30 -  1.1
  +++ jxforms-default.xsl   1 Aug 2003 09:39:27 -   1.2
  @@ -21,16 +21,13 @@



  - 
  - 
  - 
  - 
  + 

  - 
  - 
  + 
  + 

  - 
  - 
  + 
  + 



  @@ -103,15 +100,12 @@



  - 
  - 
  - 
  - 
  -   : 
 
  - 
  - 
  - 
  + 
  + 
  + 
  +   :  
  + 



  
  
  
  1.2   +16 -18
cocoon-2.1/src/blocks/jxforms/samples/stylesheets/wizard2html.xsl
  
  Index: wizard2html.xsl
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/jxforms/samples/stylesheets/wizard2html.xsl,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- wizard2html.xsl   12 Jul 2003 19:22:30 -  1.1
  +++ wizard2html.xsl   1 Aug 2003 09:39:27 -   1.2
  @@ -18,25 +18,23 @@


JXForms - Cocoon Feedback Wizard
  + 
  
  +  B{color : white;background-color : blue;}
  +  input { background-color: #FF; color: #99; border: 1px 
solid #FF; }
  +  select { background-color: #

cvs commit: cocoon-2.1/src/webapp/samples/flow samples.xml

[reinhard]

reinhard2003/08/01 02:41:23

  Modified:src/documentation/xdocs/userdocs book.xml index.xml
   src/documentation/xdocs/userdocs/flow book.xml tutor.xml
   src/webapp/samples samples.xml
   src/webapp/samples/flow samples.xml
  Log:
  - first steps for consistent naming:
* use "Control Flow" for conceptual stuff
* use "Flowscript" for javascript flows
  
  Revision  ChangesPath
  1.4   +2 -2  cocoon-2.1/src/documentation/xdocs/userdocs/book.xml
  
  Index: book.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/userdocs/book.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- book.xml  25 Mar 2003 15:39:08 -  1.3
  +++ book.xml  1 Aug 2003 09:41:23 -   1.4
  @@ -23,8 +23,8 @@
   
 
   
  -  
  -
  +  
  +
 
   
 
  
  
  
  1.5   +4 -2  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.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- index.xml 28 Jul 2003 17:41:58 -  1.4
  +++ index.xml 1 Aug 2003 09:41:23 -   1.5
  @@ -24,8 +24,10 @@
   look at the web application 
documentation.
 
  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.
  +   also take a look at Cocoon Control Flow,
  +   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.
  
  
  
  1.11  +1 -1  cocoon-2.1/src/documentation/xdocs/userdocs/flow/book.xml
  
  Index: book.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/userdocs/flow/book.xml,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- book.xml  26 Jul 2003 19:29:08 -  1.10
  +++ book.xml  1 Aug 2003 09:41:23 -   1.11
  @@ -10,7 +10,7 @@
   
 
 
  -  
  +  
   
   
   
  
  
  
  1.4   +2 -2  cocoon-2.1/src/documentation/xdocs/userdocs/flow/tutor.xml
  
  Index: tutor.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/userdocs/flow/tutor.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- tutor.xml 30 Jul 2003 15:20:10 -  1.3
  +++ tutor.xml 1 Aug 2003 09:41:23 -   1.4
  @@ -10,9 +10,9 @@
 
 
   
  -
  +
 In this tutorial, we will create a simple number guessing game using
  - Cocoon's Flowscript engine.
  + Cocoon's Control Flow engine.
 After you have Cocoon 2.1 deployed and running, go to where you have
   Cocoon deployed and create a new subdirectory named game.
   Cocoon's default main sitemap will automatically mount the sitemap in
  
  
  
  1.21  +16 -8 cocoon-2.1/src/webapp/samples/samples.xml
  
  Index: samples.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/samples.xml,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- samples.xml   5 Jul 2003 14:46:14 -   1.20
  +++ samples.xml   1 Aug 2003 09:41:23 -   1.21
  @@ -40,6 +40,16 @@
them, into one document.
  
 
  +
  +  
  +   
  +Examples of Cocoon's control flow of Web pages.
  +   
  +   
  +Since the Cocoon Control Flow is a core technology you find more examples
  +that make use of it e.g. the Petstore, JXForms and Woody block
  + 
  +

 
  
  @@ -61,18 +71,13 @@
  
 
 
  -  
  -   
  -Examples of Cocoon's control flow of Web pages.
  -   
  -  
  -  
 
  
Extensible Server Pages.
  
 
   
  +  
   
  +  
 
   
 Show the usage of the Paginator Transformer to paginate document based on 
items count limit.
  @@ -89,7 +96,8 @@
 Show the usage of the Paginator Transformer to paginate document based on 
characters count limit.
   
 
  -  
  +
  +
 
   
 Image of original size
  
  
  
  1.4   +2 -2  cocoon-2.1/src/webapp/samples/flow/samples.xml
  
  Index: samples.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/flow/samples.xml,v
  retrieving re

Paginator and ImageReader --> core components?

[Reinhard Pötz]

Quick question: 
Is there a reason why the paginator and the image reader are part of
Cocoon core and not put into blocks? 

I'm asking because if you call http://localhost:/samples/ you get
the impression that they are major parts of Cocoon ...

Reinhard

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/servlet CocoonServlet.java

[cziegeler]

cziegeler2003/08/01 03:06:41

  Modified:src/java/org/apache/cocoon/servlet CocoonServlet.java
  Log:
  Remove unused import
  
  Revision  ChangesPath
  1.12  +1 -2  cocoon-2.1/src/java/org/apache/cocoon/servlet/CocoonServlet.java
  
  Index: CocoonServlet.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/servlet/CocoonServlet.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- CocoonServlet.java31 Jul 2003 13:29:54 -  1.11
  +++ CocoonServlet.java1 Aug 2003 10:06:41 -   1.12
  @@ -50,7 +50,6 @@
   */
   package org.apache.cocoon.servlet;
   
  -import java.io.EOFException;
   import java.io.File;
   import java.io.FileInputStream;
   import java.io.FileOutputStream;
  
  
  

Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's formdefinition)

[Sylvain Wallez]

Marc Portier wrote:

Sylvain Wallez wrote:

Andreas Hochsteger wrote:

Hi!

A short question comes to my mind, while reading your RT:
Is it possible to use data types which are composed of several HTML 
input fields?
We are currently using three input fields for dates (day, month, 
year) at our current form solution.

Thanks for clearification! 




Marc explained how this can technically occur using AggregatedField.

Now from a more semantical point of view, AggregateField is something 
I'm not very comfortable with. Let's consider its two use cases :

1/ Phone number example
In this example, the displayed form shows only one input box, and its 
value is split into several non-visual subfields used by the 
application (country code, area code, number). Do these non-visual 
subfields really belong to the form definition if it never displays 
them ? Doesn't this split belong to the binding more than to the form 
definition ?

2/ Date split in several inputs
The day/month/year inputs are just a particular visual implementation 
of a date widget (in the GUI meaning of "widget"). What if we finally 
decide to use a calendar popup instead of 3 inputs ? Do we have to 
change all form definitions ?

Maybe that's just nitpicking, but I find this somewhat breaks Woody's 
clean SoC.

Touché. 


;-) Actually, this is something I was uncomfortable with right from the 
beginning, but did not want to throw on the table immediately as it's 
rather peripheral.

Indeed: The aggregatefield was only introduced when we started 
thinking about binding... however, by now I have learned to appreciate 
the concept as having its own value in the woody-model

You are right: it does somewhat hook up some back-end business-model 
vision onto the form-fields...but then again the (other) discussion we 
are having on the business-model-specific datatyping and even 
business-model-specific-validation does introduce the same level of 
mixing, no? 


Yes and no. Yes, because business-model-specific-validation introduces 
the application into the form definition, but no as it does not impact 
the structure of the form (i.e. the number of widgets it contains).

And while we try to manage the good SoC here, the reality of the app 
will always be that people *know* (influenced by their business-domain 
knowledge on the app they write) about these aggregations when they 
model the form. And not unlikely the form will need to be able to 
exploit that knowledge.
(In fact I guess that the reality vision expressed above is the real 
drive behind your current effort to make Woody more lightweight and 
generally usable?)

Purely technical I have also the following argument: I expressed 
earlier that the Woody model should be seen as the insulation layer 
between how the end user sees things and how the business-models need 
to be presented... now, I'm ready to change that into: it is the 
insulation-POINT where the two worlds are meeting.

The Woody form-model is what sits in between how the end-user consumes 
and edits his HTML-form and how the back-end presents and expects 
business data...

On the HTML form there is weak typing (only strings) and weak 
structuring (only a map-like structure of request-params) compared to 
the back-end view of things (rigid structure of staticly typed values)

The Woody-form-model takes up the responsibility of making the match 
between both, therefor it largely needs to know everything about both! 
(maybe this explains why it is perceived heavy at first glance?)

So it needs
- datatype knowledge and convertors (doing the string to YourType in 2 
directions)
- validation rules (making sure we're not handing over gibberish to 
the backend-model)
- mapping pointers into the backend-structure (binding)
- ...

What the introduction of the Aggregate-field is adding to the show is 
something I would call 'granularity of information', and to date I'm 
convinced that the woody-model needs to be aware of the smallest 
granularity either it be imposed by the end-user view or the back-end 
structure:

1/ phone number example:
 end-user sees 1 field
 back-end expects 3 distinct ones (ctr, zone, local)
  --> imposed granularity == 3
2/ date example
 end-user sees 3 fields (day, month, year)
 back-end expects 1
  --> imposed granularity == 3
The above also illustrates that the usage of the aggregate-field will 
only be useful to people actually having the intent to map stuff onto 
a backend-business model.
(but by now we already aggreed(?) that such is not really tied to 
actually using the declarative data mapping provided by the binding)

What do you think? 


This technically makes sense, but I'm not comfortable with the actual 
widget implementation having an impact on the form definition...

I also like the practical consequences introduced by the 
aggregate-field notion:

- it becomes a template-designer choice to present the date as one 
field or as separate fields 


In fact, I think there can be various 

Re: Promotion of [XPath]TraversableGenerators to main trunk

[Sylvain Wallez]

Gianugo Rabellino wrote:

Before the upcoming release, I'd like to promote the 
TraversableGenerator stuff to the main trunk. There are several things 
to discuss, though:

1. naming. TraversableGenerator sucks, yes. I guess the best option as 
of now is SourceHierarchyGenerator, any others? 


+1 for SourceHierarchyGenerator

2. merge Sylvain's stuff (caching, directory filter...). Sylvain, do 
you think you can take care of that? 


Sorry, I should have done this before. Will do it today.

3. namespace: is http://apache.org/cocoon/collection/1.0 ok? 


Mmmh... "collection" it a bit too vague IMO. Why not keeping the current 
"directory" namespace ?

4. back-compatibility: should we deprecate DirectoryGenerator? Should 
we provide a stylesheet to convert the output of Traversable to 
Directory's? 


There's no need to convert if we keep the current namespace. This would 
allow a smooth transition by just changing the class name in 

5. xpath: I'm starting to wonder whether is OK to have a separate 
XPathTraversableGenerator or if it would be better having a single 
SourceHierarchyGenerator with (optional) XPath capabilities. How about 
it? 


Dunno...

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/servlet CocoonServlet.java

[cziegeler]

cziegeler2003/08/01 03:28:38

  Modified:.status.xml
   src/java/org/apache/cocoon/servlet CocoonServlet.java
  Log:
  logkit.xconf can be located at any uri
  
  Revision  ChangesPath
  1.101 +4 -1  cocoon-2.1/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/status.xml,v
  retrieving revision 1.100
  retrieving revision 1.101
  diff -u -r1.100 -r1.101
  --- status.xml30 Jul 2003 08:21:42 -  1.100
  +++ status.xml1 Aug 2003 10:28:38 -   1.101
  @@ -167,6 +167,9 @@
 
   

  +  
  +Configuration logkit.xconf can now be read from any location.
  +  
 
  Fix the ignoreErrors handling in the cinclude transformer.
 
  
  
  
  1.13  +10 -3 cocoon-2.1/src/java/org/apache/cocoon/servlet/CocoonServlet.java
  
  Index: CocoonServlet.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/servlet/CocoonServlet.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- CocoonServlet.java1 Aug 2003 10:06:41 -   1.12
  +++ CocoonServlet.java1 Aug 2003 10:28:38 -   1.13
  @@ -823,8 +823,15 @@
   //Configure the logkit management
   String logkitConfig = getInitParameter("logkit-config", 
"/WEB-INF/logkit.xconf");
   
  -InputStream is = this.servletContext.getResourceAsStream(logkitConfig);
  -if (is == null) is = new FileInputStream(logkitConfig);
  +// test if this is a qualified url
  +InputStream is = null;
  +if ( logkitConfig.indexOf(':') == -1) {
  +is = this.servletContext.getResourceAsStream(logkitConfig);
  +if (is == null) is = new FileInputStream(logkitConfig);
  +} else {
  +URL logkitURL = new URL(logkitConfig);
  +is = logkitURL.openStream();
  +}
   final DefaultConfigurationBuilder builder = new 
DefaultConfigurationBuilder();
   final Configuration conf = builder.build(is);
   logKitManager.configure(conf);
  
  
  

Re: Promotion of [XPath]TraversableGenerators to main trunk

[Stephan Michels]

On Fri, 1 Aug 2003, Sylvain Wallez wrote:

> Gianugo Rabellino wrote:
>
> > Before the upcoming release, I'd like to promote the
> > TraversableGenerator stuff to the main trunk. There are several things
> > to discuss, though:
> >
> > 1. naming. TraversableGenerator sucks, yes. I guess the best option as
> > of now is SourceHierarchyGenerator, any others?
>
>
> +1 for SourceHierarchyGenerator
>
> > 2. merge Sylvain's stuff (caching, directory filter...). Sylvain, do
> > you think you can take care of that?
>
>
> Sorry, I should have done this before. Will do it today.
>
> > 3. namespace: is http://apache.org/cocoon/collection/1.0 ok?
>
>
> Mmmh... "collection" it a bit too vague IMO. Why not keeping the current
> "directory" namespace ?

At least, we should agree on one name

SourceHierarchyGenerator -> http://apache.org/cocoon/hierachy/1.0
SourceCollectionGenerator -> http://apache.org/cocoon/collection/1.0
SourceDirectoryGenerator -> http://apache.org/cocoon/directory/1.0

or DirectoryGenerator.

My 2cents, Stephan.

Re: Promotion of [XPath]TraversableGenerators to main trunk

[Gianugo Rabellino]

Stephan Michels wrote:


Mmmh... "collection" it a bit too vague IMO. Why not keeping the current
"directory" namespace ?


At least, we should agree on one name

SourceHierarchyGenerator -> http://apache.org/cocoon/hierachy/1.0
SourceCollectionGenerator -> http://apache.org/cocoon/collection/1.0
SourceDirectoryGenerator -> http://apache.org/cocoon/directory/1.0
or DirectoryGenerator.

Makes sense. I'm a bit against using "directory" since it's definitely 
filesystem oriented. Both WebDAV and XML:DB have the more generic 
concept of "collection" and "resource", which I like. I now tend to 
think that, semantically, the best option is to use "hierarchy" and have 
the output as:


  
 
 

 
  

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

DO NOT REPLY [Bug 21213] - [PATCH] Paginator caches dynamic pagesheet rules

[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=21213

[PATCH] Paginator caches dynamic pagesheet rules

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

DO NOT REPLY [Bug 21213] - [PATCH] Paginator caches dynamic pagesheet rules

[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=21213

[PATCH] Paginator caches dynamic pagesheet rules

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/transformation/pagination Pagesheet.java

[cziegeler]

cziegeler2003/08/01 03:52:20

  Modified:.status.xml
   src/java/org/apache/cocoon/transformation/pagination
Pagesheet.java
  Log:
  Paginator caches dynamic pagesheet rules. Patch from Frank Taffelt.
  PR:21213
  
  Revision  ChangesPath
  1.102 +5 -1  cocoon-2.1/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/status.xml,v
  retrieving revision 1.101
  retrieving revision 1.102
  diff -u -r1.101 -r1.102
  --- status.xml1 Aug 2003 10:28:38 -   1.101
  +++ status.xml1 Aug 2003 10:52:20 -   1.102
  @@ -167,6 +167,10 @@
 
   

  +  
  +Paginator now caches dynamic pagesheet correctly.
  +
 
   Configuration logkit.xconf can now be read from any location.
 
  
  
  
  1.2   +2 -2  
cocoon-2.1/src/java/org/apache/cocoon/transformation/pagination/Pagesheet.java
  
  Index: Pagesheet.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/transformation/pagination/Pagesheet.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Pagesheet.java27 Jun 2003 20:10:42 -  1.1
  +++ Pagesheet.java1 Aug 2003 10:52:20 -   1.2
  @@ -496,7 +496,7 @@
   }
   
   public boolean modifiedSince(long date) {
  -return (date!=this.lastModified);
  +return (this.lastModified == 0 || date!=this.lastModified);
   }
   
   public Object clone() {
  
  
  

RE: Paginator and ImageReader --> core components?

[Carsten Ziegeler]

Reinhard Pötz wrote:
>
> Quick question:
> Is there a reason why the paginator and the image reader are part of
> Cocoon core and not put into blocks?
>
> I'm asking because if you call http://localhost:/samples/ you get
> the impression that they are major parts of Cocoon ...
>
I think these are two different issues:
a) why the things are in the core and not a block?
Simply (I guess) because they were moved from the scratchpad into the core.
I think this is not that bad, because having a block for one single
class can't be the way. I still think that we need an "optional" block
for those, but I don't like changing these things before the 2.1 release.

b) why are the samples put very prominently on the main samples page?
I don't know, this is something we could change. And move them into a
different
location. But I think, it's not a big problem.

Carsten

Re: Apache newsletter in progress

[Stefano Mazzocchi]

On Friday, Aug 1, 2003, at 09:44 Europe/Rome, Steven Noels wrote:

fyi: Tetsuya Kitahata is in the process of preparing the first  
all-Apache newsletter, and his late work on the Jakarta newsletter  
sure makes it warrant some attention.

I added a little statement as to how the Cocoon project is faring on  
the draft Wiki version:  
http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/ 
Issue1

If there's anything completely wrong or stuff you really want to be  
added, please LMK.
You could add a link to the GT page, so that people would know how to  
follow up on that (and maybe how to submit proposals for talks and  
stuff like that)

Other than that, I like it.

--
Stefano.

Re: [Vote] Make Xalan the default xslt processor again [was: RE: Releasing 2.1]

[Stefano Mazzocchi]

On Friday, Aug 1, 2003, at 10:16 Europe/Rome, Carsten Ziegeler wrote:

There are several problems with xsltc which makes Cocoon in some
scenarios unusable. We have several problem reports and I know
from many customers that they all had to disable xsltc and use
xslt in their environment.
It's ok to have xsltc as the default for development cycles to
help the xalan team find bugs, but I think it's not good to
have it as the default for the final release as most users
have to change this default setting anyway.
So, I'm +1 on making xalan the default for the final release again.

What do you think?
+1

--
Stefano.

Re: Paginator and ImageReader --> core components?

[Stefano Mazzocchi]

On Friday, Aug 1, 2003, at 11:48 Europe/Rome, Reinhard Pötz wrote:

Quick question:
Is there a reason why the paginator and the image reader are part of
Cocoon core and not put into blocks?
lazyness ;-)

I'm asking because if you call http://localhost:/samples/ you get
the impression that they are major parts of Cocoon ...
Yes, I was going to correct that but forgot.

I'm all for moving the sample in a less prominent location, but I would 
be -1 on moving the imagereader into a block. it's just a class after 
all and a really useful one. for the paginator, I'm +0 on moving it 
into a block.

--
Stefano.

Re: [Vote] Make Xalan the default xslt processor again [was: RE:Releasing 2.1]

[Gianugo Rabellino]

Carsten Ziegeler wrote:

So, I'm +1 on making xalan the default for the final release again.

What do you think?
+1

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

Re: [Vote] Make Xalan the default xslt processor again [was: RE:Releasing 2.1]

[Geoff Howard]

Carsten Ziegeler wrote:

So, I'm +1 on making xalan the default for the final release again.

What do you think?
+1

Geoff

Re: Apache newsletter in progress

[Steven Noels]

On 1/08/2003 13:04 Stefano Mazzocchi wrote:

You could add a link to the GT page, so that people would know how to  
follow up on that (and maybe how to submit proposals for talks and  
stuff like that)
I'm busily preparing a real website for the GetTogether and hope to get 
ready to have that link included in the Newsletter by August 8th.


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

Possible Wiki vandalism

[J.Pietschmann]

Hi,
could someone have a look at
  http://wiki.cocoondev.org/Wiki.jsp?page=UnusedPages
and perhaps clean up, just in case this wasn't intended...
J.Pietschmann

Re: Apache newsletter in progress

[Tetsuya Kitahata]

Yes, I am now preparing the Apache Newsletter.

There are "New Committers" section, so those who
had voted in as cocoon committer can add your name
to it.

Also, anticipating a nice blurb :-)

-- Tetsuya. ([EMAIL PROTECTED])

P.S. I think Steven's blurb is very catchy. :D

--

On Fri, 01 Aug 2003 09:44:37 +0200
(Subject: Apache newsletter in progress)
Steven Noels <[EMAIL PROTECTED]> wrote:

> fyi: Tetsuya Kitahata is in the process of preparing the first 
> all-Apache newsletter, and his late work on the Jakarta newsletter sure 
> makes it warrant some attention.
> 
> I added a little statement as to how the Cocoon project is faring on the 
> draft Wiki version: 
> http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue1
> 
> If there's anything completely wrong or stuff you really want to be 
> added, please LMK.
> 
> Cheers,
> 
> 
> -- 
> 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

-
Tetsuya Kitahata --  Terra-International, Inc.
E-mail: [EMAIL PROTECTED]
http://www.terra-intl.com/
(Apache Jakarta Translation, Japanese)
http://jakarta.terra-intl.com/

DO NOT REPLY [Bug 21101] - NullPointerException in authentication component.

[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=21101

NullPointerException in authentication component.





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 11:42 ---
Does this problem still exist?

DO NOT REPLY [Bug 22050] New: - esql and max open cursors

[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=22050

esql and max open cursors

   Summary: esql and max open cursors
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm using the esql with an Oracle database and when I have too many SQL errors
during the connection, Oracle returns an ORA-1000 Maximum open cursors exceeded.
After a search on the web, I found the problem occurs when resultSet and
Statement are not closed.
It seems that in the esql.xsl file, in the "esql:connection//esql:execute-query"
template, when a SQLException exception is catch, the resultSet and the
statement are effectively not closed.
After addin a finally condition to close the resultSet and the Statement, the
error did not occur anymore.

DO NOT REPLY [Bug 22050] - esql and max open cursors

[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=22050

esql and max open cursors





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 12:15 ---
Created an attachment (id=7615)
patch for esql.xsl

DO NOT REPLY [Bug 22050] - [PATCH] esql and max open cursors

[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=22050

[PATCH] esql and max open cursors

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|esql and max open cursors   |[PATCH] esql and max open
   ||cursors

Re: Promotion of [XPath]TraversableGenerators to main trunk

[Vadim Gritsenko]

Gianugo Rabellino wrote:

Stephan Michels wrote:



Mmmh... "collection" it a bit too vague IMO. Why not keeping the 
current
"directory" namespace ?


At least, we should agree on one name

SourceHierarchyGenerator -> http://apache.org/cocoon/hierachy/1.0
SourceCollectionGenerator -> http://apache.org/cocoon/collection/1.0
SourceDirectoryGenerator -> http://apache.org/cocoon/directory/1.0
or DirectoryGenerator.

Makes sense. I'm a bit against using "directory" since it's definitely 
filesystem oriented. Both WebDAV and XML:DB have the more generic 
concept of "collection" and "resource", which I like. I now tend to 
think that, semantically, the best option is to use "hierarchy" and 
have the output as:


  
 
 

 
  

How does it sound?


I'm damn sure that CollectionGenerator sounds much more simple. However 
I can spell "hierarchy" too when not too drunk, it just takes more 
mental resources ;-P

Is there anybody against CollectionGenerator?

Vadim

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/servlet ParanoidCocoonServlet.java

[cziegeler]

cziegeler2003/08/01 05:45:05

  Modified:src/java/org/apache/cocoon/servlet
ParanoidCocoonServlet.java
  Log:
  Reset classloader
  
  Revision  ChangesPath
  1.6   +17 -7 
cocoon-2.1/src/java/org/apache/cocoon/servlet/ParanoidCocoonServlet.java
  
  Index: ParanoidCocoonServlet.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/servlet/ParanoidCocoonServlet.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- ParanoidCocoonServlet.java9 Jul 2003 07:42:22 -   1.5
  +++ ParanoidCocoonServlet.java1 Aug 2003 12:45:05 -   1.6
  @@ -125,10 +125,15 @@
   
// Always set the context classloader. JAXP uses it to find a 
ParserFactory,
// and thus fails if it's not set to the webapp classloader.
  - Thread.currentThread().setContextClassLoader(this.classloader);
  +final ClassLoader old = Thread.currentThread().getContextClassLoader();
  +try {
  +Thread.currentThread().setContextClassLoader(this.classloader);
   
  - // Inlitialize the actual servlet
  - this.initServlet();
  +// Inlitialize the actual servlet
  +this.initServlet();
  +} finally {
  +Thread.currentThread().setContextClassLoader(old);
  +}
   
}

  @@ -242,10 +247,15 @@
 * Service the request by delegating the call to the real servlet
 */
public void service(ServletRequest request, ServletResponse response)
  -   throws ServletException, IOException {
  +throws ServletException, IOException {
   
  - Thread.currentThread().setContextClassLoader(this.classloader);
  - this.servlet.service(request, response);
  +final ClassLoader old = Thread.currentThread().getContextClassLoader();
  +try {
  + Thread.currentThread().setContextClassLoader(this.classloader);
  + this.servlet.service(request, response);
  +} finally {
  +Thread.currentThread().setContextClassLoader(old);
  +}
}
   
/**
  
  
  

Re: [RT] New Input for woody

[Marc Portier]

Carsten,

Thx. This extra explanation on dywel added onto the understanding 
I already had (important nuances noted)


not trivial, maybe possible, useful?
Hmm, I'm a little unsure. Now, I don't want to destroy the design
of woody only to make me happy. If it makes sense, to change
woody: great. If it doesn't, well, then I can live with that
as well. It's a decision I'm currently not able to make or
contribute to.
I think, currently if Dywel will ever work sometime in the distant
future, it's more elegant to connect to existing business objects
than woody; but on the other hand woody has great advantage in
all the other form areas where you don't connect to business objects.
I agree.

That all of this largely resembles each other (Bruno saying I 
reinvented xmlforms adds to that) should be no big surprise since 
all of it tries to solve the same set of problems...

The resemblence is a great way IMO to realize none of us is 
completely on the wrong track, but it can't prevent the different 
alternatives to take specific differentiating positions that will 
make them more elegant to use in very specific situations.

Woody has everything in it to grow into a system that can handle 
your bean backends equally well as pure XML backends given the 
loose connection ideas to be found everywhere in the design...

There surely is the commitment (effort currently going on if you 
ask me) to ensure that specific broadly recognised usage models 
could get a simplified mapping onto the current Woody-soc...

but rest assured: none of that effort will ever ensure that in a 
given case there could not be a more specific implementation that 
will be able to cut some corners and provide a more elegant solution.

The above statement probably fits to a large extend to what 
Cocoon as a whole is providing. (and how it is sometimes perceived)

In any case, thx for your input, it already added some nice 
features into the woody-basket (and possibly touching woody 
returned you some of the favor).

I hope you can continue the effort of feeding us your progress on 
Dywel.

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: Promotion of [XPath]TraversableGenerators to main trunk

[Steven Noels]

On 1/08/2003 14:28 Vadim Gritsenko wrote:

I can spell "hierarchy" too when not too drunk, it just takes more 
mental resources ;-P

Is there anybody against CollectionGenerator?
Could we have that with one 'l' for alcoholics, since they tend to 
draw anyhow?


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

[Woody] ids or refs ?

[Sylvain Wallez]

While reviewing the file formats, I was wondering...

Currently, Woody uses the "id" attribute everywhere for identifiers be 
there on a defining element (e.g. ) or a referring element 
(e.g. ).

Now that we will start to mix namespaces and have format & datatype 
dictionaries referred to by other files, it seems to me cleaner and more 
understandable to differentiate defining and referring attribute.

For this, I propose to keep the current "id" on defining elements and 
use "ref" attribute on referring elements.

Thoughts ? Is it nitpicking ?

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] New Input for woody

[Sylvain Wallez]

Marc Portier wrote:

Carsten,

Thx. This extra explanation on dywel added onto the understanding I 
already had (important nuances noted)

not trivial, maybe possible, useful?


Hmm, I'm a little unsure. Now, I don't want to destroy the design of 
woody only to make me happy. If it makes sense, to change woody: 
great. If it doesn't, well, then I can live with that as well. It's a 
decision I'm currently not able to make or contribute to. 

I'm not sure Woody's design has to be destroyed to include Dywel's way 
of binding. With the upcoming separate datatype and format catalogues, 
it would be possible to write an implementation that builds the datatype 
catalogue using introspection.

Same applies to binding : there can be another implementation of the 
binding.

I think, currently if Dywel will ever work sometime in the distant 
future, it's more elegant to connect to existing business objects 
than woody; but on the other hand woody has great advantage in all 
the other form areas where you don't connect to business objects.

I agree.

That all of this largely resembles each other (Bruno saying I 
reinvented xmlforms adds to that) should be no big surprise since all 
of it tries to solve the same set of problems...


I would add that it's good that you reinvented XMLForm : there are nice 
ideas in it, but it's hardly usable for serious formatting and 
connection to back-end data. Every framework builds on the lessons taken 
from the previous one. And when good ideas exist, there's no reason to 
trash them.

The resemblence is a great way IMO to realize none of us is completely 
on the wrong track, but it can't prevent the different alternatives to 
take specific differentiating positions that will make them more 
elegant to use in very specific situations.

Woody has everything in it to grow into a system that can handle your 
bean backends equally well as pure XML backends given the loose 
connection ideas to be found everywhere in the design...

There surely is the commitment (effort currently going on if you ask 
me) to ensure that specific broadly recognised usage models could get 
a simplified mapping onto the current Woody-soc... 


Yep. Woody is currently able to map to XML and JavaBean backends, which 
should already cover many of the needs. Another need I foresee is direct 
mapping to an SQL backend.

but rest assured: none of that effort will ever ensure that in a given 
case there could not be a more specific implementation that will be 
able to cut some corners and provide a more elegant solution.

The above statement probably fits to a large extend to what Cocoon as 
a whole is providing. (and how it is sometimes perceived)

In any case, thx for your input, it already added some nice features 
into the woody-basket (and possibly touching woody returned you some 
of the favor).

I hope you can continue the effort of feeding us your progress on Dywel. 


Yes, please. And keep following the work on Woody. You may find that it 
is able to host your ideas as particular implementations of one of its 
components.

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: [ANNOUNCEMENT]: Xerces-J 2.5.0 now available

[Vadim Gritsenko]

Elena Litani wrote:

Hi all, 

The Xerces-J team is very happy to announce that version 2.5.0 of
Xerces-J is now available.  

This release provides a partial partial implementation of the XML
Inclusions (XInclude) W3C Candidate Recommendation
Has anybody seen this / tried this with Cocoon?

Vadim

Re: StoreJanitorImpl in scratchpad

[Vadim Gritsenko]

Geoff Howard wrote:

OTOMH, I think Vadim was going to look into syncing them as some felt 
the scratchpad version better in areas. [20 words ;)]

Geoff

Carsten Ziegeler wrote:

Does anyone know the status of the StoreJanitorImpl in the scratchpad?

Is it obsolete or is it better than the version in excalibur store? 

Just to delete this from my mailbox (grew too big): Issue is taken care of.

Vadim

Re: [Woody] ids or refs ?

[Bruno Dumon]

On Fri, 2003-08-01 at 15:04, Sylvain Wallez wrote:
> While reviewing the file formats, I was wondering...
> 
> Currently, Woody uses the "id" attribute everywhere for identifiers be 
> there on a defining element (e.g. ) or a referring element 
> (e.g. ).
> 
> Now that we will start to mix namespaces and have format & datatype 
> dictionaries referred to by other files, it seems to me cleaner and more 
> understandable to differentiate defining and referring attribute.
> 
> For this, I propose to keep the current "id" on defining elements and 
> use "ref" attribute on referring elements.
> 
> Thoughts ? Is it nitpicking ?

No, ref is better.

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

Re: [Woody] ids or refs ?

[Sylvain Wallez]

Bruno Dumon wrote:

On Fri, 2003-08-01 at 15:04, Sylvain Wallez wrote:
 



For this, I propose to keep the current "id" on defining elements and 
use "ref" attribute on referring elements.

Thoughts ? Is it nitpicking ?
   

No, ref is better.
 

Kewl ;-)

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: Paginator and ImageReader --> core components?

[Reinhard Pötz]

Responding to Carsten's mail too:

Then (if anybody else is faster) I modify the examples and wait with a
paginator block.

Reinhard


> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] 
> Sent: Friday, August 01, 2003 1:09 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Paginator and ImageReader --> core components?
> 
> 
> 
> On Friday, Aug 1, 2003, at 11:48 Europe/Rome, Reinhard Pötz wrote:
> 
> >
> > Quick question:
> > Is there a reason why the paginator and the image reader 
> are part of 
> > Cocoon core and not put into blocks?
> 
> lazyness ;-)
> 
> > I'm asking because if you call 
> http://localhost:/samples/ you get 
> > the impression that 
> they are major parts of Cocoon ...
> 
> Yes, I was going to correct that but forgot.
> 
> I'm all for moving the sample in a less prominent location, 
> but I would 
> be -1 on moving the imagereader into a block. it's just a class after 
> all and a really useful one. for the paginator, I'm +0 on moving it 
> into a block.
> 
> --
> Stefano.
> 

deprecate DOMUtil.node2String and friends ?

[Christian Haul]

Team,

picking up the thread on invalid XML produced by DOMUtil.node2String
and the fact that XMLUtils.serializeNodeToXML covers the same
functionality, I would like to deprecate the node2String* methods in
DOMUtil and make them point to XMLUtils.serializeNodeToXML
instead. The methods seems to be used only by DocumentWrapper which
adds a useful toString() method to any Document.
Of course we could just remove the methods from DOMUtil as well...

Thoughts?

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

RE: Paginator and ImageReader --> core components?

[Reinhard Pötz]

> -Original Message-
> From: Reinhard Pötz [mailto:[EMAIL PROTECTED] 
> Sent: Friday, August 01, 2003 4:21 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Paginator and ImageReader --> core components?
> 
> 
> Responding to Carsten's mail too:
> 
> Then (if anybody else is faster) I modify the examples and 

uuups, of course *is not* faster ;-)

Reinhard

> wait with a paginator block.
> 
> Reinhard
> 
> 
> > -Original Message-
> > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
> > Sent: Friday, August 01, 2003 1:09 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Paginator and ImageReader --> core components?
> > 
> > 
> > 
> > On Friday, Aug 1, 2003, at 11:48 Europe/Rome, Reinhard Pötz wrote:
> > 
> > >
> > > Quick question:
> > > Is there a reason why the paginator and the image reader
> > are part of
> > > Cocoon core and not put into blocks?
> > 
> > lazyness ;-)
> > 
> > > I'm asking because if you call
> > http://localhost:/samples/ you get
> > > the impression that
> > they are major parts of Cocoon ...
> > 
> > Yes, I was going to correct that but forgot.
> > 
> > I'm all for moving the sample in a less prominent location,
> > but I would 
> > be -1 on moving the imagereader into a block. it's just a 
> class after 
> > all and a really useful one. for the paginator, I'm +0 on moving it 
> > into a block.
> > 
> > --
> > Stefano.
> > 
> 

[Woody] explicit in

[Sylvain Wallez]

Continuing my file format polishing...

Currently, any markup inside a  is copied as is, but 
surrounded by a  by WoodyTransformer, i.e.
 
   
 

is transformed into :
 
   
   fooValue
 
I found several annoyances related to the fact that  isn't 
explicit in the template :
- it appears automagically and thus is a bit confusing...
- it forbids the use of attributes for styling (e.g. class) unless 
they're placed on a dummy element
- we agreed that  could contain visual characteristics of the 
widget, such as . This means that wi: markup inside 
 should not be included in the produced  while 
non-wi: markup should. Confusing...

For these reasons, I propose to make  explicit in the template 
file, e.g. :
  
   
   overriden label
 

Thoughts ?

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: Paginator and ImageReader --> core components?

[Vadim Gritsenko]

Reinhard Pötz wrote:

-Original Message-
From: Reinhard Pötz [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 01, 2003 4:21 PM
To: [EMAIL PROTECTED]
Subject: RE: Paginator and ImageReader --> core components?

Responding to Carsten's mail too:

Then (if anybody else is faster) I modify the examples and 
   

uuups, of course *is not* faster ;-)

Reinhard

 

wait with a paginator block.

You mean "optional" block. Paginator is not that big to deserve own block.

Vadim

DO NOT REPLY [Bug 22050] - [PATCH] esql and max open cursors

[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=22050

[PATCH] esql and max open cursors

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]   |[EMAIL PROTECTED]
   ||darmstadt.de

a different version of LuceneIndexTransformer ..

[maisonneuve nico]

i made a different version of the LuceneIndexTransformer nearer to the 
Lucene concepts
(more basic and flexible) based on the old LuceneIndexTransformer

Example of input source:

http://apache.org/cocoon/lucene/1.0";>


sqdqsdq
 bla bal blalael balbal 

10/12/2002 (see java API Class 
SimpleDateFormat for more explanation about the dateFormat attribut)
just indexed information (not 
stored)
just stored information (not 
indexed)



Mr 
Author (boost the field for the search (see Lucene 
documentation)
french




 //delete all documents with the 
field id ="1E3RFE"






Example of Output Source :

http://apache.org/cocoon/lucene/1.0";>



_
MSN Messenger 6 http://g.msn.fr/FR1001/866  : dialoguez en son et en image 
avec vos amis.
package org.paris5.cocoon.transformation;

import java.io.File;
import java.io.IOException;
import java.io.Serializable;
import java.util.Map;
import java.util.Stack;
import java.util.Date;
import java.text.SimpleDateFormat;

import org.apache.avalon.framework.activity.Disposable;
import org.apache.avalon.framework.component.ComponentException;
import org.apache.avalon.framework.component.ComponentManager;
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.context.Context;
import org.apache.avalon.framework.context.ContextException;
import org.apache.avalon.framework.context.Contextualizable;
import org.apache.avalon.framework.parameters.Parameters;

import org.apache.avalon.excalibur.pool.Recyclable;

import org.apache.cocoon.Constants;
import org.apache.cocoon.ProcessingException;
import org.apache.cocoon.caching.CacheableProcessingComponent;
import org.apache.cocoon.components.search.LuceneCocoonHelper;
import org.apache.cocoon.components.search.LuceneXMLIndexer;
import org.apache.cocoon.transformation.AbstractSAXTransformer;

import org.apache.cocoon.environment.SourceResolver;
import org.apache.excalibur.source.SourceValidity;
import org.apache.excalibur.source.impl.validity.NOPValidity;

import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
import org.apache.lucene.document.DateField;
import org.apache.lucene.store.*;
import org.apache.lucene.index.*;

import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.AttributesImpl;
import java.text.*;

/**
 * A lucene index creation transformer.
 * @author Nicolas Maisoneuve
 *
 Example of input source:
 ;<
   lucene:index create="true" 
   analyzer="org.apache.lucene.analysis.standard.StandardAnalyzer"
   directory="d:/indexbase"
   merge-factor="merge-factor">
 
 sqdqsdq
  bla bal
   blalael balbal 
 10/12/2002 
 (see
 java API Class SimpleDateFormat for more explanation about the dateFormat attribut)
 
 just indexed
 information (not stored)
 just stored
 information (not indexed)
 
  
 Mr
 Author (boost the field for the search (see Lucene documentation))
 french
 
 < /lucene:index>
 
   (delete
 all documents with the field author ="Mr Author") 
 < /lucene:delete>

Example of Output Source
;
<
  lucene:index nbdocuments="2"/>
<
lucene:delete nbdocuments="1"/>



 */

public class LuceneIndexTransformer
extends AbstractSAXTransformer
implements Disposable, CacheableProcessingComponent, Recyclable,
Configurable, Contextualizable {

  public static final String ANALYZER_CLASSNAME_CONFIG = "analyzer-classname";
  public static final String ANALYZER_CLASSNAME_PARAMETER =
  "analyzer-classname";

  public static final String DIRECTORY_CONFIG = "directory";
  public static final String DIRECTORY_PARAMETER = "directory";

  public static final String MERGE_FACTOR_CONFIG = "merge-factor";
  public static final String MERGE_FACTOR_PARAMETER = "merge-factor";

  public static final String DIRECTORY_DEFAULT = "index";
  public static final int MERGE_FACTOR_DEFAULT = 20;
  public static final String ANALYZER_CLASSNAME_DEFAULT =
  "org.apache.lucene.analysis.standard.StandardAnalyzer";

  public static fi

Re: Possible Wiki vandalism

[Steven Noels]

On 1/08/2003 13:26 J.Pietschmann wrote:
Hi,
could someone have a look at
  http://wiki.cocoondev.org/Wiki.jsp?page=UnusedPages
and perhaps clean up, just in case this wasn't intended...
That page is autogenerated from a list of non-linked pages & attachments 
- something I tend to clean out in my copious free time.


--
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: [ANNOUNCEMENT]: Xerces-J 2.5.0 now available

[Steven Noels]

On 1/08/2003 15:29 Vadim Gritsenko wrote:

The Xerces-J team is very happy to announce that version 2.5.0 of
Xerces-J is now available. 
This release provides a partial partial implementation of the XML
Inclusions (XInclude) W3C Candidate Recommendation

Has anybody seen this / tried this with Cocoon?
Our own Transformer already does XPointer & XML Base.


--
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: [RT] New Input for woody

[Carsten Ziegeler]

Sylvain Wallez wrote:
> 
> Marc Portier wrote:
> 
> > Carsten,
> >
> > Thx. This extra explanation on dywel added onto the understanding I 
> > already had (important nuances noted)
> >
> >>> not trivial, maybe possible, useful?
> >>
> >>
> >> Hmm, I'm a little unsure. Now, I don't want to destroy the design of 
> >> woody only to make me happy. If it makes sense, to change woody: 
> >> great. If it doesn't, well, then I can live with that as well. It's a 
> >> decision I'm currently not able to make or contribute to. 
> >
> 
> I'm not sure Woody's design has to be destroyed to include Dywel's way 
> of binding. With the upcoming separate datatype and format catalogues, 
> it would be possible to write an implementation that builds the datatype 
> catalogue using introspection.
> 
> Same applies to binding : there can be another implementation of the 
> binding.
Sounds good!

> 
> 
> > The resemblence is a great way IMO to realize none of us is completely 
> > on the wrong track, but it can't prevent the different alternatives to 
> > take specific differentiating positions that will make them more 
> > elegant to use in very specific situations.
> >
> > Woody has everything in it to grow into a system that can handle your 
> > bean backends equally well as pure XML backends given the loose 
> > connection ideas to be found everywhere in the design...
> >
> > There surely is the commitment (effort currently going on if you ask 
> > me) to ensure that specific broadly recognised usage models could get 
> > a simplified mapping onto the current Woody-soc... 
> 
> 
> Yep. Woody is currently able to map to XML and JavaBean backends, which 
> should already cover many of the needs. Another need I foresee is direct 
> mapping to an SQL backend.
> 
This sounds a little bit like mixing concerns, but let's see how it comes
out.

> > but rest assured: none of that effort will ever ensure that in a given 
> > case there could not be a more specific implementation that will be 
> > able to cut some corners and provide a more elegant solution.
> >
> > The above statement probably fits to a large extend to what Cocoon as 
> > a whole is providing. (and how it is sometimes perceived)
> >
> > In any case, thx for your input, it already added some nice features 
> > into the woody-basket (and possibly touching woody returned you some 
> > of the favor).
> >
> > I hope you can continue the effort of feeding us your progress 
> on Dywel. 
> 
> 
> Yes, please. And keep following the work on Woody. You may find that it 
> is able to host your ideas as particular implementations of one of its 
> components.
> 
Yes, of course I will do both. And I thank you all for trying to explain
Woody to me and to see how dywel and woody might fit together.

Perhaps we will see at a later time when both things will be used how the
real implementation should look like (perhaps for Cocoon 3.1).

Thanks
Carsten

Re: [Woody] explicit in

[Bruno Dumon]

On Fri, 2003-08-01 at 16:31, Sylvain Wallez wrote:
> Continuing my file format polishing...
> 
> Currently, any markup inside a  is copied as is, but 
> surrounded by a  by WoodyTransformer, i.e.
>   
> 
>   
> 
> is transformed into :
>   
> 
> fooValue
>   
> 
> I found several annoyances related to the fact that  isn't 
> explicit in the template :
> - it appears automagically and thus is a bit confusing...
> - it forbids the use of attributes for styling (e.g. class) unless 
> they're placed on a dummy element
> - we agreed that  could contain visual characteristics of the 
> widget, such as . This means that wi: markup inside 
>  should not be included in the produced  while 
> non-wi: markup should. Confusing...
> 
> For these reasons, I propose to make  explicit in the template 
> file, e.g. :
>
> 
> overriden label
>   
> 
> Thoughts ?

Again: yeah, it is better ;-)

While I'm thinking of it, there is a somewhat similar situation in the
form definition files: widgets that have child widgets, such as wd:form
and wd:repeater, currently have these child widgets listed immediately
inside the wd:form and wd:repeater elements. It would be better to wrap
those inside a wd:children element (or similar), so that forms and
repeaters can have other configuration elements too.

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

Re: [Woody] explicit in

[Sylvain Wallez]

Bruno Dumon wrote:

On Fri, 2003-08-01 at 16:31, Sylvain Wallez wrote:
 



For these reasons, I propose to make  explicit in the template file, e.g. :
  
   
   overriden label
 
Thoughts ?
   

Again: yeah, it is better ;-)

Kewl again ;-)

While I'm thinking of it, there is a somewhat similar situation in the
form definition files: widgets that have child widgets, such as wd:form
and wd:repeater, currently have these child widgets listed immediately
inside the wd:form and wd:repeater elements. It would be better to wrap
those inside a wd:children element (or similar), so that forms and
repeaters can have other configuration elements too.
This totally makes sense :
- in XMLForm, I used  on  to produce the  of 
a 
- an aggregate field, being a leaf from the GUI point of view, must have 
its label, format, etc.

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: [ANNOUNCEMENT]: Xerces-J 2.5.0 now available

[Gianugo Rabellino]

Steven Noels wrote:
On 1/08/2003 15:29 Vadim Gritsenko wrote:

The Xerces-J team is very happy to announce that version 2.5.0 of
Xerces-J is now available. This release provides a partial partial 
implementation of the XML
Inclusions (XInclude) W3C Candidate Recommendation

Has anybody seen this / tried this with Cocoon?


Our own Transformer already does XPointer & XML Base.
But I would *love* to delegate that to the Xerces guys, if possible... 
out implementation is partial and probably not going anywhere, theirs 
might be much more supported and vital.

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: Cocoon Schools of Development [was: Re: Cool (work)flowGUIeditor]

[Bruno Dumon]

On Fri, 2003-08-01 at 11:15, Reinhard Pötz wrote:
> > For the actual code see 
> > http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=21900
> 
> Marc, why don't you put Apples it into scratchpad?

>From the practical side of things: is there much difference between
scratchpad and an unstable block? The current patch Marc prepared is set
up as a block. Among other things, this makes it easy to add things to
cocoon.xconf as part of the build (I don't think scratchpad supports
that?).

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

Re: [ANNOUNCEMENT]: Xerces-J 2.5.0 now available

[Bruno Dumon]

On Fri, 2003-08-01 at 17:06, Gianugo Rabellino wrote:
> Steven Noels wrote:
> > On 1/08/2003 15:29 Vadim Gritsenko wrote:
> > 
> >>> The Xerces-J team is very happy to announce that version 2.5.0 of
> >>> Xerces-J is now available. This release provides a partial partial 
> >>> implementation of the XML
> >>> Inclusions (XInclude) W3C Candidate Recommendation
> >>>
> >>
> >> Has anybody seen this / tried this with Cocoon?
> > 
> > 
> > Our own Transformer already does XPointer & XML Base.
> 
> But I would *love* to delegate that to the Xerces guys, if possible... 
> out implementation is partial and probably not going anywhere, theirs 
> might be much more supported and vital.
> 

I find it quite odd that XInclude is part of the parser. They could as
well start putting XSLT support in there.

A cocoon XInclude transformer has the advantage that you can put it
anywhere in the pipeline, i.e. after another transformation has been
applied. And it allows to do XInclude processing on stuff that's not
parsed from an XML file.

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

RE: Cocoon Schools of Development [was: Re: Cool (work)flowGUIeditor]

[Reinhard Pötz]

From: Bruno Dumon

> 
> On Fri, 2003-08-01 at 11:15, Reinhard Pötz wrote:
> > > For the actual code see
> > > http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=21900
> > 
> > Marc, why don't you put Apples it into scratchpad?
> 
> >From the practical side of things: is there much difference between
> scratchpad and an unstable block? The current patch Marc 
> prepared is set up as a block. Among other things, this makes 
> it easy to add things to cocoon.xconf as part of the build (I 
> don't think scratchpad supports that?).

A block is fine too - I just wondered why Marc hasn't checked it in into
the CVS. In the meantime Steven told me that Marc didn't had the karma
to do it.

Reinhard 

Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's formdefinition)

[Marc Portier]

Sylvain Wallez wrote:
Marc Portier wrote:

Sylvain Wallez wrote:

Andreas Hochsteger wrote:

Hi!



Maybe that's just nitpicking, but I find this somewhat breaks Woody's 
clean SoC.

Touché. 


;-) Actually, this is something I was uncomfortable with right from the 
beginning, but did not want to throw on the table immediately as it's 
rather peripheral.

hehe, I needed some time to come up with a sensible defense for 
the aggregate-existence towards myself and Bruno as well, so this 
is not a real surprise :-)

however once you get into the view that 'Woody needs to know the 
most details from both sides' this aggregatefield isn't that big 
of hack IMO

Indeed: The aggregatefield was only introduced when we started 
thinking about binding... however, by now I have learned to appreciate 
the concept as having its own value in the woody-model

You are right: it does somewhat hook up some back-end business-model 
vision onto the form-fields...but then again the (other) discussion we 
are having on the business-model-specific datatyping and even 
business-model-specific-validation does introduce the same level of 
mixing, no? 
Yes and no. Yes, because business-model-specific-validation introduces 
the application into the form definition, but no as it does not impact 
the structure of the form (i.e. the number of widgets it contains).

agree, specially on the no-yes-no grey area about this :-)



What do you think? 
This technically makes sense, but I'm not comfortable with the actual 
widget implementation having an impact on the form definition...

maybe that feeling has more to do with the fact that the basic 
woody-model building block is called WIDGET, and not something 
more decoupled from its visual representation on the (HTML) form? 
 Something like 'INFORMATION-NODE' or even 'SUBMIT-ARGUMENT' (I 
don't like nor propose these, but I hope it helps you understand 
how I look at them as they live in the woody-model-definition)

as explained my feeling is that woody's model should be as 
decoupled from the 'template' as it is from the 'backend-model'

(note: the above is the conceptual view I have, it does not come 
back on me supporting your effort into defining a sensible mix of 
the definition/config files to make specific usage patterns 
easier fit onto using woody in real life)


I also like the practical consequences introduced by the 
aggregate-field notion:

- it becomes a template-designer choice to present the date as one 
field or as separate fields 
In fact, I think there can be various interpretation of the 
"template-designer" role. It seems like you consider the template 
designer more like an HTML-guy, while I my experience shows that he's 
more an application-domain-related guy.

I think the main thing I wanted to say was about the 
'model-designer' role: he is the one that defines which 
http-request parameters can be sent to the form.

The template-designer will need to live by the rules he set.

Using the aggregateField in the model will leave some option to 
the template-designer to actually choose for a form-layout that 
is to ask/submit either the aggregated or the split-part params.


What I'd like to achieve is to have the form template define the overall 
form layout (fieldsets, columns, etc) but not the details of the layout, 


I think the form-model-designer is the one that defines the 
details of the HTTP-API (which request-params can be sent) - not 
the details of the form-layout

the latter is I'm afraid the role of the template-designer (who 
might cooperate with a nifty client-side-javascript designer but 
that is a different story)

especially for low-level widgets. IMO, the form designer should not have 
to worry about the fact that the date input is actually implemented 
using a combination of 3 popups instead of a single input. Moreover, 
requiring the form designer to explicitely write these 3 popups in the 
template each time a date input is needed will certainly lead to 
inconsistencies in the GUI.

How the defined HTTP-API-request params are mapped onto actual 
(HTML) form layout (and granularity in the case of the 
aggregate-field) is up to the template-designer

the issue of consistency between the different layouts is up to 
the template-designer to tackle (but we could help him of course, 
as you are proposing below?)

So actually, what I'd like to see in the form template for this date 
example is :



Which should be expanded into :

 
 
 
 


 
 
 
 

hm, would like it more if the template transformer would be able 
to make the decission that was handed to him by the template-hint 
 handed in the template file...

this would leave the xslt sheet following unchanged (which is not 
a goal per se, but having nested wi:field feals unnatural)

this probably would ask for the styling decission to be added to 
the wt:field as an attribute.

This can be easily achieved if we consider two types of AggregateField 
that are SAXed differently :
- app-related aggregat

Re: Promotion of [XPath]TraversableGenerators to main trunk

[Guido Casper]

Stephan Michels wrote:
> At least, we should agree on one name
>
> SourceHierarchyGenerator -> http://apache.org/cocoon/hierachy/1.0
> SourceCollectionGenerator -> http://apache.org/cocoon/collection/1.0
> SourceDirectoryGenerator -> http://apache.org/cocoon/directory/1.0
>
> or DirectoryGenerator.

Probably I should shut up and sit down before adding yet another opinion but
FWIW I prefer DirectoryGenerator. It's most user-friendly (immediately
understood by everyone) and compatible. I can already imagine:

"What the heck is SourceHierarchyGenerator"
"A DirectoryGenerator for other sources as well"
:-)

I see no strong reason to rename DirectoryGenerator just because now it
operates on other sources as well. It is semantically as correct as the
other.

The next step is renaming FileGenerator? Although this would even make more
sense. But given that these components will mostly be used for the
filesystem for a long time to come ...

But I'm fine with any of these names.

Guido

Re: Promotion of [XPath]TraversableGenerators to main trunk

[Gianugo Rabellino]

Guido Casper wrote:
Stephan Michels wrote:

At least, we should agree on one name

SourceHierarchyGenerator -> http://apache.org/cocoon/hierachy/1.0
SourceCollectionGenerator -> http://apache.org/cocoon/collection/1.0
SourceDirectoryGenerator -> http://apache.org/cocoon/directory/1.0
or DirectoryGenerator.


Probably I should shut up and sit down before adding yet another opinion but
FWIW I prefer DirectoryGenerator. It's most user-friendly (immediately
understood by everyone) and compatible. 
I could easily live with it, but the problem is that someone might have 
extended DirectoryGenerator, and such extensions would not be compatible 
anymore if we just drop it in favor of the source based one. You don't 
want this, don't you? :-)

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: Promotion of [XPath]TraversableGenerators to main trunk

[Stephan Michels]

On Fri, 1 Aug 2003, Guido Casper wrote:

> Stephan Michels wrote:
> > At least, we should agree on one name
> >
> > SourceHierarchyGenerator -> http://apache.org/cocoon/hierachy/1.0
> > SourceCollectionGenerator -> http://apache.org/cocoon/collection/1.0
> > SourceDirectoryGenerator -> http://apache.org/cocoon/directory/1.0
> >
> > or DirectoryGenerator.
>
> Probably I should shut up and sit down before adding yet another opinion but
> FWIW I prefer DirectoryGenerator. It's most user-friendly (immediately
> understood by everyone) and compatible. I can already imagine:
>
> "What the heck is SourceHierarchyGenerator"
> "A DirectoryGenerator for other sources as well"
> :-)
>
> I see no strong reason to rename DirectoryGenerator just because now it
> operates on other sources as well. It is semantically as correct as the
> other.
>
> The next step is renaming FileGenerator? Although this would even make more
> sense. But given that these components will mostly be used for the
> filesystem for a long time to come ...

+1, KISS like.

DirectoryGenerator and
FileGenerator.

99% of the used sources are files.

And I don't think backward compatibility is here a must have.

Stephan.

Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's formdefinition)

[Sylvain Wallez]

Marc Portier wrote:



Sylvain Wallez wrote:

Marc Portier wrote:

Sylvain Wallez wrote:

Andreas Hochsteger wrote:

Hi!



Maybe that's just nitpicking, but I find this somewhat breaks 
Woody's clean SoC.

Touché. 




;-) Actually, this is something I was uncomfortable with right from 
the beginning, but did not want to throw on the table immediately as 
it's rather peripheral.

hehe, I needed some time to come up with a sensible defense for the 
aggregate-existence towards myself and Bruno as well, so this is not a 
real surprise :-)

however once you get into the view that 'Woody needs to know the most 
details from both sides' this aggregatefield isn't that big of hack IMO

Indeed: The aggregatefield was only introduced when we started 
thinking about binding... however, by now I have learned to 
appreciate the concept as having its own value in the woody-model

You are right: it does somewhat hook up some back-end business-model 
vision onto the form-fields...but then again the (other) discussion 
we are having on the business-model-specific datatyping and even 
business-model-specific-validation does introduce the same level of 
mixing, no? 


Yes and no. Yes, because business-model-specific-validation 
introduces the application into the form definition, but no as it 
does not impact the structure of the form (i.e. the number of widgets 
it contains).

agree, specially on the no-yes-no grey area about this :-)



What do you think? 


This technically makes sense, but I'm not comfortable with the actual 
widget implementation having an impact on the form definition...

maybe that feeling has more to do with the fact that the basic 
woody-model building block is called WIDGET, and not something more 
decoupled from its visual representation on the (HTML) form? 
 Something like 'INFORMATION-NODE' or even 'SUBMIT-ARGUMENT' (I don't 
like nor propose these, but I hope it helps you understand how I look 
at them as they live in the woody-model-definition)

as explained my feeling is that woody's model should be as decoupled 
from the 'template' as it is from the 'backend-model' 


Agree. But the date-with-3-fields use case if the perfect example where 
GUI decisions (using these 3 fields instead of a single input) have an 
impact on the Woody model.

(note: the above is the conceptual view I have, it does not come back 
on me supporting your effort into defining a sensible mix of the 
definition/config files to make specific usage patterns easier fit 
onto using woody in real life) 


I understood it clearly.


I also like the practical consequences introduced by the 
aggregate-field notion:

- it becomes a template-designer choice to present the date as one 
field or as separate fields 


In fact, I think there can be various interpretation of the 
"template-designer" role. It seems like you consider the template 
designer more like an HTML-guy, while I my experience shows that he's 
more an application-domain-related guy.

I think the main thing I wanted to say was about the 'model-designer' 
role: he is the one that defines which http-request parameters can be 
sent to the form.

The template-designer will need to live by the rules he set. 


Sure. But in my experience, the model designer and template designer are 
the same person (knowledged about the application domain), while the 
"layout designer" is a webdesigner that defines the formatting XSLs 
according to the project graphical requirements.

This is what I've seen on most projects we've done here. And for the 
current one, the customer has to be able to modify the forms (both model 
and template) without knowing html (or very roughly).

Using the aggregateField in the model will leave some option to the 
template-designer to actually choose for a form-layout that is to 
ask/submit either the aggregated or the split-part params.


In my experience (again), this is the layout-designer that will take 
this decision.

What I'd like to achieve is to have the form template define the 
overall form layout (fieldsets, columns, etc) but not the details of 
the layout, 


I think the form-model-designer is the one that defines the details of 
the HTTP-API (which request-params can be sent) - not the details of 
the form-layout

the latter is I'm afraid the role of the template-designer (who might 
cooperate with a nifty client-side-javascript designer but that is a 
different story)

especially for low-level widgets. IMO, the form designer should not 
have to worry about the fact that the date input is actually 
implemented using a combination of 3 popups instead of a single 
input. Moreover, requiring the form designer to explicitely write 
these 3 popups in the template each time a date input is needed will 
certainly lead to inconsistencies in the GUI.

How the defined HTTP-API-request params are mapped onto actual (HTML) 
form layout (and granularity in the case of the aggregate-field) is up 
to the template-designer

the issue of consistency betw

Re: Promotion of [XPath]TraversableGenerators to main trunk

[Sylvain Wallez]

Stephan Michels wrote:

+1, KISS like.

DirectoryGenerator and
FileGenerator.
99% of the used sources are files.

And I don't think backward compatibility is here a must have.

Yes it is, since some users (of which I am) extended DirectoryGenerator 
to add their own filtering strategies and additional attributes...

Back to the discussion about protected/private and "officially public" 
APIs...

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: Promotion of [XPath]TraversableGenerators to main trunk

[Geoff Howard]

Gianugo Rabellino wrote:
Guido Casper wrote:

Stephan Michels wrote:

At least, we should agree on one name

SourceHierarchyGenerator -> http://apache.org/cocoon/hierachy/1.0
SourceCollectionGenerator -> http://apache.org/cocoon/collection/1.0
SourceDirectoryGenerator -> http://apache.org/cocoon/directory/1.0
or DirectoryGenerator.


Probably I should shut up and sit down before adding yet another 
opinion but
FWIW I prefer DirectoryGenerator. It's most user-friendly (immediately
understood by everyone) and compatible. 


I could easily live with it, but the problem is that someone might have 
extended DirectoryGenerator, and such extensions would not be compatible 
anymore if we just drop it in favor of the source based one. You don't 
want this, don't you? :-)
I suggested in the past creating a "name only" extension of this 
generator to make it clearer to the casual observer that it can work 
with simple directories.  Since the name DirectoryGenerator is used and
should be protected wouldn't "SourceDirectoryGenerator" do? 
Alternatively, adding a deprecation note on DirectoryGenerator which 
points to whatever extremely-accurate-but-unclear-to-outsiders name we
want might be all that is needed.

Geoff

Re: Promotion of [XPath]TraversableGenerators to main trunk

[Gianugo Rabellino]

Sylvain Wallez wrote:
+1, KISS like.

DirectoryGenerator and
FileGenerator.
99% of the used sources are files.

And I don't think backward compatibility is here a must have.

Yes it is, since some users (of which I am) extended DirectoryGenerator 
to add their own filtering strategies and additional attributes...

Not to mention the 4-5 Generators we have in the Cocoon codebase which 
are extending DirectoryGenerator...

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

Questions/Suggestions for Woody

[Andreas Hochsteger]

Hi!

Most form examples in the current woody discussions assume, that the forms are
presented in HTML.
Is it (or will it be) possible to support different output formats while 
reusing most of the form definition?

I'm interested in the following output formats:
* HTML with JavaScript (for Client-Side validation)
* Pure HTML
* XHTML + XForms
* WML
* PDF Forms (not that important)
* Word Forms (not that important either)
* Web Services (isn't that something XMLForm supported?)
* anything else?

Can someone explain to me how such a scenario would look like (in terms 
of woody config files)?

Additionally I've got a suggestion for the many woody config files which 
my satisfy both simple and advanced forms:
For really simple forms it is better to have everything in one file.
For advanced forms this becomes easily unmaintainable and doesn't 
support SoC.
In this case it might be possible to swap certain parts out to other 
files and include these.

The only problem which might be with this solution is that this way all 
parts of the config have to be parsed during each request, even if they 
wouldn't have to.
But I don't know much of the woody internals to answer this question myself.

Thanks,

Andreas Hochsteger
http://highstick.blogspot.com/

cvs commit: cocoon-2.1/src/scratchpad/src/org/apache/cocoon/generation TraversableGenerator.java

[sylvain]

sylvain 2003/08/01 10:21:15

  Modified:src/scratchpad/src/org/apache/cocoon/generation
TraversableGenerator.java
  Added:   src/scratchpad/src/org/apache/cocoon/components/source/impl
MultiSourceValidity.java
  Log:
  Smarter validity for TraversalGenerator : takes into account the validity of each 
individual source instead of just lastModified
  
  Revision  ChangesPath
  1.1  
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/components/source/impl/MultiSourceValidity.java
  
  Index: MultiSourceValidity.java
  ===
  /*
   * The Apache Software License, Version 1.1
   *
   *
   * Copyright (c) 2003 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, 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 (INCLUDING, 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.  For more
   * information on the Apache Software Foundation, please see
   * .
   */
  package org.apache.cocoon.components.source.impl;
  
  import java.io.IOException;
  import java.util.ArrayList;
  import java.util.List;
  
  import org.apache.excalibur.source.Source;
  import org.apache.excalibur.source.SourceResolver;
  import org.apache.excalibur.source.SourceValidity;
  
  /**
   * An aggregated validity for multiple sources.
   * 
   * @author http://www.apache.org/~sylvain";>Sylvain Wallez
   * @version CVS $Id: MultiSourceValidity.java,v 1.1 2003/08/01 17:21:15 sylvain Exp $
   */
  public class MultiSourceValidity implements SourceValidity{
  
  private long expiry;
  private long delay;
  private List data = new ArrayList();
  private boolean isClosed = false;
  
  /** SourceResolver. Transient in order not to be serialized */
  private transient SourceResolver resolver;
  
  public MultiSourceValidity(SourceResolver resolver, long delay) {
  this.resolver = resolver;
  this.expiry = System.currentTimeMillis() + delay;
  this.delay = delay;
  }
  
  public void addSource(Source src) {
  if (this.data != null) {
  SourceValidity validity = src.getValidity();
  if (validity == null) {
  // one of the sources has no validity : this object will always be 
invalid
  this.data = null;
  } else {
  // Add the validity and URI to the list
  this.data.add(validity);
  this.data.add(src.getURI());
  }
  }
  }
  
  public void close() {
  this.isClosed = true;
  thi

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/xml/dom DOMStreamer.java

[vgritsenko]

vgritsenko2003/08/01 10:48:44

  Modified:src/java/org/apache/cocoon/xml/dom DOMStreamer.java
  Log:
  align
  
  Revision  ChangesPath
  1.11  +2 -2  cocoon-2.1/src/java/org/apache/cocoon/xml/dom/DOMStreamer.java
  
  Index: DOMStreamer.java
  ===
  RCS file: /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/xml/dom/DOMStreamer.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- DOMStreamer.java  19 Mar 2003 09:40:42 -  1.10
  +++ DOMStreamer.java  1 Aug 2003 17:48:44 -   1.11
  @@ -741,7 +741,7 @@
   }
   
   SAXResult result = new SAXResult(handler);
  -result.setLexicalHandler(lexicalHandler);
  +result.setLexicalHandler(lexicalHandler);
   
   try {
   transformer.transform(source, result);
  
  
  

Re: Moving Cocoon wiki to proper ASF equipment [was: Re: Releasing2.1]

[Gianugo Rabellino]

Justin Erenkrantz wrote:
Infrastructure peeps: this is about the JSPWiki-based Cocoon wiki 
running on
wiki.cocoondev.org. Having run & regularly upgraded this beasty for
considerable time, I can attest it's a neat Wiki implementation and runs
quite well. I'd be happy to further help maintaining it anywhere it is
hosted.
If you are willing to take the initiative and set it up and maintain it, 
we can figure out a solution that works.  But, the infrastructure@ group 
can't/won't baby-sit everything on its own.  So, at least two committers 
have to step up and be willing to maintain it.
OK, count me in. I have a quite extensive experience as a Unix/network 
sysadm and, even if I don't exercise much lately, I'more than willing to 
help you out. Please consider this as an offer to help not only for this 
particular issue, but for everything in Apache where you might see a 
need for some sysop helping hand (I'm a bit rusty on FreeBSD, but I use 
and maintain daily Sun, Linux and AIX boxes). Yes, this is the long 
overdue "may I help you guys on infrastructure" that has been sitting 
somewhere for way too long. :-)

As a starting point, I'd recommend setting up the server on a high port 
on minotaur and get everything working just right.  Once it's all 'up', 
infrastructure@ can figure out what to do next.  But, doing this first 
will ensure that all of the software can/does run on minotaur.  If it 
doesn't run on FreeBSD (or there are problems), then you'll have to run 
it on nagoya (which is a Solaris box).
Makes sense. I understand that there is a long overdue upgrade on 
nagoya: again, if it's OK to you, I can do my best to help on this too 
(maybe when Pier gets back).

Ciao,

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

DO NOT REPLY [Bug 22064] New: - XMLDBTransformer generation Key id

[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=22064

XMLDBTransformer generation Key id

   Summary: XMLDBTransformer generation Key id
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: Minor
  Priority: Other
 Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In the case where we let the generation of keyID to the database (the attribut 
oid=""),there a bug : the resuls oid is empty (

Example :


Hi erverybody


the result is  :

and not



so i propose this little patch.. just add key=resource.getId(); after the 
creation

if("create".equals(operation)) {
try {
Resource resource = collection.createResource(key, 
"XMLResource");
resource.setContent(document);
collection.storeResource(resource);
result = "success";
  ---> key=resource.getId();
} catch (XMLDBException e) {
message = "Failed to create resource " + key + ": " 
+ e.errorCode;
getLogger().debug(message, e);
}

Re: [VOTE] Commit access for Guido Casper

[Christian Haul]

Gianugo Rabellino wrote:
I want to propose Guido Casper ([EMAIL PROTECTED]) as a new Cocoon 
committer.
OK, OK, I'm late welcome!
+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

Re: Moving Cocoon wiki to proper ASF equipment [was: Re: Releasing2.1]

[Steven Noels]

On 1/08/2003 19:32 Justin Erenkrantz wrote:

If you are willing to take the initiative and set it up and maintain it, 
we can figure out a solution that works.  But, the infrastructure@ group 
can't/won't baby-sit everything on its own.  So, at least two committers 
have to step up and be willing to maintain it.
Of course, and count me in on that.

As a starting point, I'd recommend setting up the server on a high port 
on minotaur and get everything working just right.  Once it's all 'up', 
infrastructure@ can figure out what to do next.  But, doing this first 
will ensure that all of the software can/does run on minotaur.  If it 
doesn't run on FreeBSD (or there are problems), then you'll have to run 
it on nagoya (which is a Solaris box).
The upgrade Pier was planning seems a bit over my capabilities to assist 
with, but if someone can point me out how a servlet container _should_ 
be installed on minotaur (where on the FS, what UID should be owning it, 
any related suggestions) I'd like to step up (together with Gianugo 
would be great) to start with a trial instance on a higher port. 
Integrating it with the httpd daemon in a sensible way might require 
access and assistance from root people anyhow, depending on the strategy 
we follow (mod_proxy, or mod_name_your_favourite_version_jk), so 
assistance in that perspective is welcomed as well.

If you do run into problems, please let infrastructure@ know and we can 
try to help you work through it.  But, it's unlikely we'll take 
initiative on our own.
I never meant to force work upon you guys, but if there's thoughts 
towards a shared servlet container setup where JSPWiki for Cocoon is one 
of many deployed webapps, it's better to discuss here before moving in, 
IMHO.

As an aside, have you considered using the SubWiki install?  ;-)  If 
you'd be willing to use that, I might be enticed to help you migrate to 
that away from JSPWiki.  See:

http://cvs.apache.org/wiki/

It's written in Python!  Oh no!  -- justin
For the record: I like Python - and I'm pretty much agnostic towards 
specific WikiEngine implementations. But I don't like migrating 533 
pages of Wiki content from one WikiEngine to another.

In terms of sizing, here's some rough stats on the current instance:

(per month, rough rounding)

Successful requests: ~400K
Average successful requests per day: ~15K
Successful requests for pages: ~120K
Average successful requests for pages per day: ~4K
Data transferred: ~2.5 GB
Average data transferred per day: ~85 MB

--
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: [ANNOUNCEMENT]: Xerces-J 2.5.0 now available

[Steven Noels]

On 1/08/2003 17:06 Gianugo Rabellino wrote:

out implementation is partial and probably not going anywhere, theirs 
might be much more supported and vital.
That _might_ be just the case. ;-)

I wouldn't downplay what we are doing with low-level XML handling stuff, 
and also this often results in bugs being reported to the parser gurus. 
I've been doing some light XSLT development today, and I ended up being 
slightly annoyed with the quality of error handling in Xalan (let alone 
the way the eventual messages are being thrown forward in Cocoon).

I'd like to see a more unified approach however to the (n)Include stuff, 
it might be better to extend the standards syntax with specific 
constructs available as features in Cocoon's own Include transformer, 
rather than having two Include transformers side-by-side.


--
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: Moving Cocoon wiki to proper ASF equipment [was: Re: Releasing2.1]

[Justin Erenkrantz]

--On Thursday, July 31, 2003 11:04 PM +0200 Steven Noels 
<[EMAIL PROTECTED]> wrote:
Infrastructure peeps: this is about the JSPWiki-based Cocoon wiki running on
wiki.cocoondev.org. Having run & regularly upgraded this beasty for
considerable time, I can attest it's a neat Wiki implementation and runs
quite well. I'd be happy to further help maintaining it anywhere it is
hosted.
If you are willing to take the initiative and set it up and maintain it, we 
can figure out a solution that works.  But, the infrastructure@ group 
can't/won't baby-sit everything on its own.  So, at least two committers have 
to step up and be willing to maintain it.

As a starting point, I'd recommend setting up the server on a high port on 
minotaur and get everything working just right.  Once it's all 'up', 
infrastructure@ can figure out what to do next.  But, doing this first will 
ensure that all of the software can/does run on minotaur.  If it doesn't run 
on FreeBSD (or there are problems), then you'll have to run it on nagoya 
(which is a Solaris box).

If you do run into problems, please let infrastructure@ know and we can try to 
help you work through it.  But, it's unlikely we'll take initiative on our own.

As an aside, have you considered using the SubWiki install?  ;-)  If you'd be 
willing to use that, I might be enticed to help you migrate to that away from 
JSPWiki.  See:

http://cvs.apache.org/wiki/

It's written in Python!  Oh no!  -- justin

Re: Moving Cocoon wiki to proper ASF equipment [was: Re: Releasing2.1]

[Steven Noels]

On 1/08/2003 22:22 Justin Erenkrantz wrote:

Does that make sense?  -- justin
Perfect. Going offlist with Gianugo to discuss details.

Just a last one: for the sake of having Cool URIs, could someone 
afterwards suggest (or configure) proxy_pass on httpd so that we are 
able to release Cocoon 2.1 (in three weeks) with the Wiki running on its 
definitive URI (http://cocoon.apache.org/wiki/)? Or can we do that 
ourselves using .htaccess?

Thanks!


--
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: Moving Cocoon wiki to proper ASF equipment [was: Re: Releasing2.1]

[Justin Erenkrantz]

--On Friday, August 01, 2003 22:07:16 +0200 Steven Noels 
<[EMAIL PROTECTED]> wrote:

The upgrade Pier was planning seems a bit over my capabilities to assist
with, but if someone can point me out how a servlet container _should_ be
installed on minotaur (where on the FS, what UID should be owning it, any
related suggestions) I'd like to step up (together with Gianugo would be
great) to start with a trial instance on a higher port. Integrating it
with the httpd daemon in a sensible way might require access and
assistance from root people anyhow, depending on the strategy we follow
(mod_proxy, or mod_name_your_favourite_version_jk), so assistance in that
perspective is welcomed as well.
Yes, what I would recommend is installing everything in your home directory 
anyway you (or Gianugo) see fit.  Setup an httpd as a front-end, or use the 
native server - don't much care for feasibility checks.  Use a high port, 
run it as your UID - make sure that the wiki serves pages reliably.

To do the above, you shouldn't need any special privs or rights.

Once we know that the JDK/servlet container work on FreeBSD (which is an 
open question), we can continue the conversation as to how to integrate it 
with the cocoon.apache.org site.  I'd prefer using mod_jk2 (if using Tomcat 
- or if using Jetty its connector - it has one, right?) over a ProxyPass 
connection, but let's cross that bridge when we get to it.

Does that make sense?  -- justin

Re: Moving Cocoon wiki to proper ASF equipment [was: Re: Releasing2.1]

[Tony Collen]

Justin Erenkrantz wrote:

&snip;

Once we know that the JDK/servlet container work on FreeBSD (which is an 
open question), we can continue the conversation as to how to integrate 
it with the cocoon.apache.org site.  I'd prefer using mod_jk2 (if using 
Tomcat - or if using Jetty its connector - it has one, right?) over a 
ProxyPass connection, but let's cross that bridge when we get to it.
What version of BSD is running?  I've had problems with the JDK and slightly older versions of 
FreeBSD, where Java would only run as root (!), and it was a documented bug in the FreeBSD kernel... 
it was pretty nasty AFAIR.  I hear they've fixed the problem in the latest releases (4.8-R, etc), 
but I wouldn't be 100% on anything older than 4.8 or 4.7-R.



Tony

Getting an X from a FOM_X

[Ugo Cei]

I need to call a Java method from the flowscript that takes an 
org.apache.cocoon.environment.Request as a parameter. But in the 
flowscript, I only have cocoon.request which is a FOM_Request that wraps 
an o.a.c.e.Request. How do I get the latter from the former?

In general, how do I get a {Request,Response,Session,Cookie} from a 
FOM_{Request,Response,Session,Cookie} ?

	Thanks in Advance,

		Ugo

RE: Getting an X from a FOM_X

[Christopher Oliver]

FOM_Cocoon has Java methods to get the Request, Response, Session, and
Context, and ComponentManager.

-Original Message-
From: Ugo Cei [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 01, 2003 2:17 PM
To: [EMAIL PROTECTED]
Subject: Getting an X from a FOM_X

I need to call a Java method from the flowscript that takes an 
org.apache.cocoon.environment.Request as a parameter. But in the 
flowscript, I only have cocoon.request which is a FOM_Request that wraps

an o.a.c.e.Request. How do I get the latter from the former?

In general, how do I get a {Request,Response,Session,Cookie} from a 
FOM_{Request,Response,Session,Cookie} ?

Thanks in Advance,

Ugo

Re: Getting an X from a FOM_X

[Ugo Cei]

Christopher Oliver wrote:
FOM_Cocoon has Java methods to get the Request, Response, Session, and
Context, and ComponentManager.
Like this one, I suppose:

   /**
 * Get the current request
 * @return The request
 */
public Request getRequest() {
return jsGet_request().request;
}
But is it callable from Javascript? If I try to call 
"cocoon.getRequest()" I get this exception:

org.apache.avalon.framework.CascadingRuntimeException: getRequest is not 
a function".

	Ugo

DO NOT REPLY [Bug 21925] - [PATCH] 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

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





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 21:53 ---
Created an attachment (id=7620)
Expose Context.getRealPath (includes previous patches)

Re: Getting an X from a FOM_X

[Ugo Cei]

Ugo Cei wrote:
Christopher Oliver wrote:

FOM_Cocoon has Java methods to get the Request, Response, Session, and
Context, and ComponentManager.
But is it callable from Javascript? If I try to call 
"cocoon.getRequest()" I get this exception:

org.apache.avalon.framework.CascadingRuntimeException: getRequest is not 
a function".

Ugo
While waiting for a reply, I went ahead and simply wrapped the method in 
a new method that takes a FOM_Cocoon as an argument, gets the Request 
from it and calls the original method.

Oh, by the way, this is related to porting Linotype to the FOM, which I 
have just completed, so if someone would be so kind as to activate my 
CVS committer account, I'd be glad to commit it myself ;-).

	Ugo

Re: Getting an X from a FOM_X

[Christopher Oliver]

Ugo Cei wrote:

Christopher Oliver wrote:

FOM_Cocoon has Java methods to get the Request, Response, Session, and
Context, and ComponentManager.


Like this one, I suppose:

   /**
 * Get the current request
 * @return The request
 */
public Request getRequest() {
return jsGet_request().request;
}
But is it callable from Javascript? If I try to call 
"cocoon.getRequest()" I get this exception:

org.apache.avalon.framework.CascadingRuntimeException: getRequest is 
not a function".

Ugo


No, it is not - and intentionally so. You can access 
org.apache.cocoon.environment.Request from Java code, but from 
JavaScript you can only access FOM objects.

Regards,

Chris

Re: Getting an X from a FOM_X

[Vadim Gritsenko]

Ugo Cei wrote:

Ugo Cei wrote:

Christopher Oliver wrote:

FOM_Cocoon has Java methods to get the Request, Response, Session, and
Context, and ComponentManager.
But is it callable from Javascript? If I try to call 
"cocoon.getRequest()" I get this exception:

org.apache.avalon.framework.CascadingRuntimeException: getRequest is 
not a function".

Ugo


While waiting for a reply, I went ahead and simply wrapped the method 
in a new method that takes a FOM_Cocoon as an argument, gets the 
Request from it and calls the original method.

Oh, by the way, this is related to porting Linotype to the FOM, which 
I have just completed, so if someone would be so kind as to activate 
my CVS committer account, I'd be glad to commit it myself ;-). 


You see... Here lies the problem: everything not wrapped in js_ should 
not be accessible. See all those discussions on "less is more" and 
"FOM". Before adding anything into the FOM (adding some new wrapper) 
vote should take place. FOM was limited by design.

Vadim

Re: Questions/Suggestions for Woody

[Marc Portier]

Andreas Hochsteger wrote:
Hi!

Most form examples in the current woody discussions assume, that the forms are
presented in HTML.
Is it (or will it be) possible to support different output formats while 
reusing most of the form definition?

I'm interested in the following output formats:
* HTML with JavaScript (for Client-Side validation)
* Pure HTML
* XHTML + XForms
* WML
* PDF Forms (not that important)
* Word Forms (not that important either)
* Web Services (isn't that something XMLForm supported?)
* anything else?
Can someone explain to me how such a scenario would look like (in terms 
of woody config files)?

(note: there is some changes underway so some of this might change)

most of the above look like you need the correct **ML-specific 
version of the form (supposing you can render all of the above 
from specific XML gramars)
I am not sure about PDF and Word Forms sending back valid HTTP 
request params from within their respective clients, if they 
don't you probably don't need to bother using woody at all

but if they all do, then you'll have to make some decissions on 
smart management of stylesheets and the like to get most if not 
everything from one (at least a limited number of) source-file...
I think it will take some of us actually doing these things 
before we get a real feel to the matter (we plan on a smaller 
try-out with WML in the not too distant future)

Another issue I see however is the mismatch of number of widgets 
per screen for each of these targets... this might call for 
splitting up a lot more of these sources then the big XML dream 
was promising :-)

Still Woody could at least do a best effort to ensure that all 
these targets can be reached by applying the same competence mix 
somewhat.


Additionally I've got a suggestion for the many woody config files which 
my satisfy both simple and advanced forms:
For really simple forms it is better to have everything in one file.
For advanced forms this becomes easily unmaintainable and doesn't 
support SoC.
In this case it might be possible to swap certain parts out to other 
files and include these.

As I understand it the current work Sylvain is doing is exactly 
about finding this balance

The only problem which might be with this solution is that this way all 
parts of the config have to be parsed during each request, even if they 
wouldn't have to.
But I don't know much of the woody internals to answer this question myself.

It largely depends on the upcoming proposal, knowing Sylvain a 
bit that will be quite well-balanced by his broad experience

the future bringing in more of our different experiences will 
most likely fine-tune that

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]