RE: Design of unmarshaling sitemap component

[DURDINA Michal]

> -Original Message-
> From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 29, 2004 7:06 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Design of unmarshaling sitemap component
> 
> 
> DURDINA Michal <[EMAIL PROTECTED]> writes:
> 
> > Hi,
> > I would like to discuss the design problem of the sitemap 
> > component. My plan is to develop special let's call it 
> > transformer for transforming sources for pages written or 
> > generated by analysts (model) to dynamic pages generating 
> > required results (implementation). The form of model is 
> > custom XML according to given XMLSchema and the 
> > implementation pages should be in form of jxtemplates (or xsp).
> > 
> > The transformation should go like this:
> > 
> > pipeline:
> > additional data
> >|
> > modelXML -> populated modelXML -> computed model -> 
> jxtemplate source
> > 
> > The intent of the pipeline is to generate executable source 
> > from model that will generate required dynamic page. The 
> > trick is that the computed modelXML is not trivial and should 
> > be implemented as Java OM. 
> 
> Wow.  You're overall requirements sounds a lot like ours so I'm
> interested in how you reached this design?  Given your use of 
> jxtemplate
> I can't see that it's performance driven? If not, why not just keep
> everything in XML from end to end and use XSLT to derive the computed
> model?  
> 
> Castor/java implementation issues
> 
> 

Yes, keeping everything in XML and using XSLT would also realize the transformation. 
Given that it would involve a XSL stylesheet that will do all the computations. Such a 
stylesheet would not be easy to write and it will be probably too complex to maintain. 
Using Java for computation on input XML should be more straightforward and using 
jxtemplate for outputing the resulting XML gains from clear view how the resulting XML 
will look like. Performance was not the main requirement as the source generation 
occures only once and then it is cached although this should perform better than XSLT.

I already started the implementation and have first version of such a component 
implemented as a transformer (case A.). I hope it will meet my requirements and we 
will profit form this kind of concept.

Thank you for comment,
Michal

Re: [proposal] Private Branches

[Giacomo Pati]

Stefano Mazzocchi wrote:
My proposal is to create a private branch for every committer that wants 
it and place it in

 http://svn.apache.org/repos/asf/cocoon/private/[id]
+1
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

Re: [proposal] Private Branches

[Steven Noels]

On 29 Jul 2004, at 23:50, Stefano Mazzocchi wrote:
fine, what about
  
http://svn.apache.org/repos/asf/cocoon/ 
(whiteboard|scratchpad|research)
Much better. But you are suggesting a branch for all these, no? I'm not  
so sure about that - branches tend to hide things away. Of course,  
branching is better|easier than scratchpad areas, so this might be the  
better solution.

For the record: I'm -1 on any labelling or classification system which  
includes the name|id|alias of a contributor. Anything else which is  
workable, facilitates creativity, groups common work areas under a  
single name, and doesn't create code islands, I'm violently +1.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Re: [proposal] Private Branches

[Nicola Ken Barozzi]

Steven Noels wrote:
On 29 Jul 2004, at 23:50, Stefano Mazzocchi wrote:
fine, what about
  http://svn.apache.org/repos/asf/cocoon/ 
(whiteboard|scratchpad|research)
We had already discussed (was it 1, 2 years ago) that personal 
playgrounds are bad...

Much better. But you are suggesting a branch for all these, no? I'm not  
so sure about that - branches tend to hide things away. Of course,  
branching is better|easier than scratchpad areas, so this might be the  
better solution.
If something is a branch, it should actually be a branch (ie copy from 
the main code), so it can merge. If not it can still reside in branches, 
as in subversion it's just a dir.

For the record: I'm -1 on any labelling or classification system which  
includes the name|id|alias of a contributor. 
Same here.
Anything else which is  
workable, facilitates creativity, groups common work areas under a  
single name, and doesn't create code islands, I'm violently +1.
If someone wants to experiment on a branch, just say so and do it, and 
label the branch with a significant name. When/if time to merge back 
will occur, we will vote. Simple IMHO.

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

Re: [proposal] Private Branches

[Reinhard Poetz]

Stefano Mazzocchi wrote:
 http://svn.apache.org/repos/asf/cocoon/(whiteboard|scratchpad|research)

I like research or playground best. Anyway, let's make it more concrete: 
These days I started to work on the Cocoon BlockDeployer and I plan to 
share my work within the next two or three weeks. I would put it into

http://svn.apache.org/repos/asf/cocoon/playground/block-deployer
(I don't think putting it into the branches directory is appropriate 
because it is definitly no branch.)

Any objections or other proposals?
--
Reinhard

[GUMP@brutus]: cocoon-2.1/cocoon failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact folk at [EMAIL PROTECTED]

Project cocoon has an issue affecting its community integration.
This issue affects 54 projects, and has been outstanding for 5 runs.
Project State : 'Failed', Reason 'Build Failed'
The following are affected:
- cocoon :  Java XML Framework
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-linotype :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-mail :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-php :  Java XML Framework
- cocoon-block-poi :  Java XML Framework
- cocoon-block-portal :  Java XML Framework
- cocoon-block-portal-fw :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-scratchpad :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slide :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-webdav :  Java XML Framework
- cocoon-block-woody :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- cocoon-lenya :  Content Management System


Full details are available at:

http://brutus.apache.org/gump/public/cocoon-2.1/cocoon/index.html

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Jar [cocoon.jar] identifier set to jar basename: [cocoon]
 -DEBUG- Jar [cocoon-tests.jar] identifier set to jar basename: [cocoon-tests]
 -DEBUG- Jar [cocoon-deprecated.jar] identifier set to jar basename: 
[cocoon-deprecated]
 -DEBUG- Dependency on avalon-framework exists, no need to add for property 
avalonapi.jar.
 -INFO- Made directory 
[/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-20040730/test]
 -INFO- Enable "verbose" output, due to 5 previous error(s).
 -INFO- Failed with reason build failed
 -INFO- Enable "debug" output, due to build failure.
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-20040730/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-20040730/test/output]


The following work was performed:
http://brutus.apache.org/gump/public/cocoon-2.1/cocoon/gump_work/build_cocoon-2.1_cocoon.html
Work Name: build_cocoon-2.1_cocoon (Type: Build)
State: Failed
Elapsed: 13 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -verbose 
-Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Davalonapi.jar=/usr/local/gump/public/workspace/avalon/framework/api/target/avalon-framework-api-20040730.jar
 
-Dlogkit.jar=/usr/local/gump/public/workspace/avalon-logkit/target/avalon-logkit-20040730.jar
 -Dversion=20040730 gump-core 
[Working Directory: /usr/local/gump/public/workspace/cocoon-2.

Re: [RT] A Groovy Kind of Sitemap

[Nicola Ken Barozzi]

Ugo Cei wrote:
Il giorno 30/lug/04, alle 00:24, Sylvain Wallez ha scritto:
Don't take all this badly Ugo: I see much more dangers in turning the 
sitemap into a scripting language than the advantages brought by 
saving a few keystokes or the ease of implementation. But I'm all for 
a simplified implementation of the current syntax.
...
One thing I *hate* about flowscript is that it's in a different file 
from the sitemap. Kinda like writing a java class with methods in one 
file and fields in another.

Having both in the same file, even if with a different language but 
still with a readable format (like python), would be really cool.

cocoon<<<
  version = 2
  sitemap--->
mypipeline
  if (request.match(".*\.html")) then
generate("input.xml")
transform("xslt", "stylesheet1.xsl")
transform("xslt", "stylesheet2.xsl")
serialize("xml")
  <---
  javascript--->
void myfunction(continuation,javascript){
   blah...blah...
   (can call "mypipeline" pipeline from here)
   (can call "mypipeline2" pipeline from here)
}
  <---
  sitemap--->
mypipeline2
  if (request.match(".*\.html")) then
generate("input.xml")
transform("xslt", "stylesheet1.xsl")
transform("xslt", "stylesheet2.xsl")
serialize("xml")
  <---
  jtyhon--->
myfunction(continuation)
   blah...blah...
   (can call "mypipeline" pipeline from here)
   (can call "mypipeline2" pipeline from here)
  <---
>>>
So I needed something that could enable me to reach very 
rapidly the target of having an actual program that would be able to 
take an HTTP request, feed it to a sitemap that is (semantically if not 
syntactically) equivalent to a subset of the Cocoon sitemap and send out 
an appropriate response.
One attempt is the CocoonBean, that has tried to do this by wrapping 
instead of redoing. Same problem, different implementation. Personally i 
think that it's wierd to have a bean wrap a component wrap some classes, 
although necessary not to redo things (like you are doing :-)

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

JavaFlow class problem

[Bart Molenkamp]

Hello,

I've found a problem with JavaFlow. I use OJB in my flow class. When I
try to execute the following code:

QueryByCriteria query = new QueryByCriteria(Account.class, new
Criteria());

I get a black page returned (the flow code is not executed). But the
following code is correctly executed:

QueryByCriteria query = new
QueryByCriteria(Class.forName("com.bizzdesign.persistence.risks.Account"
), new Criteria());

The difference is obviously Account.class and Class.forName(...). What
could be the problem?

Bart.

Re: [RT] A Groovy Kind of Sitemap

[Vilya Harvey]

You raise a few good points, but I don't agree with all of them.
You're right that XML is a given for working with Cocoon. That's not a bad 
thing. But people already need to know a lot more than just XML in order to 
understand a sitemap. There seems to be a cutoff point in the development of 
a cocoon site. Up to the cutoff, the pipelines stay fairly straightforward: 
generator, a few transforms, and a serializer; after the cutoff it becomes 
necessary to start adding more complex behaviour: actions, nested matchers, 
etc. I suspect these latter sorts of pipeline could be expressed much more 
clearly using a scripting language.

You mention people generally have a background which includes JavaScript 
because it's hard to avoid learning it. If that's the case, perhaps those 
people wouldn't be so fazed by seeing a scripting language in the sitemap.

Really it's about using the most suitable representation for the task at 
hand. A scripting language feels like overkill for simple pipelines, but the 
XML syntax is very awkward for more complicated ones. The appropriate choice 
comes down to how soon you feel that cutoff occurs, for the kind of sites 
you develop.

Vil.
--
__
   o|   _. /  \|o._  _  _ ._  _  ._  _ _|_
\/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_
 / \__
http://website.lineone.net/~vilya

Re: [proposal] Private Branches

[Nicola Ken Barozzi]

Reinhard Poetz wrote:
Stefano Mazzocchi wrote:
 http://svn.apache.org/repos/asf/cocoon/(whiteboard|scratchpad|research)
I like research or playground best. Anyway, let's make it more concrete: 
These days I started to work on the Cocoon BlockDeployer and I plan to 
share my work within the next two or three weeks. I would put it into

http://svn.apache.org/repos/asf/cocoon/playground/block-deployer
(I don't think putting it into the branches directory is appropriate 
because it is definitly no branch.)

Any objections or other proposals?
No objections, just that 'playground' seems like kids playing... better 
would be 'whiteboard' IMHO. Not that I oppose to any name, you can even 
name it SGdfgDSGDSFG as long as it gets in there :-)

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

Re: extract Java continuations?

[Torsten Curdt]

Has there been any discussion of extracting Java continuations into a 
standalone project?
 
There are a lot of people (judging by web searches... and including me 
:-)  who would love to use this functionality, but not in the context of 
Cocoon.
There has been the discussion to move it over into
the jakarta commons sandbox. If the jakarta folks
are willing to accept the code ...and we can get
commit access over there - no objections.
But we are also aiming for something bigger [1]
cheers
--
Torsten
[1]http://vafer.org/blog/tcurdt/archives/000109.html

Re: JavaFlow class problem

[Torsten Curdt]

Hello,
I've found a problem with JavaFlow. I use OJB in my flow class. When I
try to execute the following code:
QueryByCriteria query = new QueryByCriteria(Account.class, new
Criteria());
I get a black page returned (the flow code is not executed). But the
following code is correctly executed:
QueryByCriteria query = new
QueryByCriteria(Class.forName("com.bizzdesign.persistence.risks.Account"
), new Criteria());
The difference is obviously Account.class and Class.forName(...). What
could be the problem?
Please file it to bugzilla and do
not forget to attach the stacktrace.
cheers
--
Torsten

DO NOT REPLY [Bug 30406] New: - JavaFlow throws VerifyError when using .class in code

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30406

JavaFlow throws VerifyError when using .class in code

   Summary: JavaFlow throws VerifyError when using .class in code
   Product: Cocoon 2
   Version: 2.1.5
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This code causes an error:
QueryByCriteria query = new QueryByCriteria(Account.class, new Criteria());
 
While this code works fine: 
QueryByCriteria query = new
QueryByCriteria(Class.forName("com.bizzdesign.persistence.risks.Account"), new
Criteria());

The stack trace:
13:10:26.216 WARN!! Error for /risks/editAccount.jfdo
java.lang.VerifyError: (class:
org/apache/cocoon/samples/flow/java/CalculatorFlow, method: doEditAccount
signature: ()V) Unable to pop operand off an empty stack
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:1647)
at java.lang.Class.privateGetPublicMethods(Class.java:1770)
at java.lang.Class.getMethods(Class.java:824)
at
org.apache.cocoon.components.flow.java.JavaInterpreter.initialize(JavaInterpreter.java:96)
at
org.apache.cocoon.components.flow.java.JavaInterpreter.callFunction(JavaInterpreter.java:130)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:277)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:103)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:277)
at org.apache.cocoon.Cocoon.process(Cocoon.java:639)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1098)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:354)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1808)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1758)
at org.mortbay.http.HttpServer.service(HttpServer.java:879)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:790)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:952)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:807)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:197)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool

RE: DO NOT REPLY [Bug 30406] New: -

[Bart Molenkamp]

Note: I use Eclipse for development. I can do a lot of changes to code
while running Cocoon in Tomcat, but with JavaFlow, I need to restart
everytime I change the code. This made me think: maybe the problem is
related to class loading somehow.

I don't know if it's useful to place this information in bugzilla too.

Bart.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 30, 2004 1:26 PM
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 30406] New: -

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30406

JavaFlow throws VerifyError when using .class in code

   Summary: JavaFlow throws VerifyError when using .class in
code
   Product: Cocoon 2
   Version: 2.1.5
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This code causes an error:
QueryByCriteria query = new QueryByCriteria(Account.class, new
Criteria());
 
While this code works fine: 
QueryByCriteria query = new
QueryByCriteria(Class.forName("com.bizzdesign.persistence.risks.Account"
), new
Criteria());

The stack trace:
13:10:26.216 WARN!! Error for /risks/editAccount.jfdo
java.lang.VerifyError: (class:
org/apache/cocoon/samples/flow/java/CalculatorFlow, method:
doEditAccount
signature: ()V) Unable to pop operand off an empty stack
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:1647)
at java.lang.Class.privateGetPublicMethods(Class.java:1770)
at java.lang.Class.getMethods(Class.java:824)
at
org.apache.cocoon.components.flow.java.JavaInterpreter.initialize(JavaIn
terpreter.java:96)
at
org.apache.cocoon.components.flow.java.JavaInterpreter.callFunction(Java
Interpreter.java:130)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invo
ke(CallFunctionNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i
nvoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P
ipelineNode.java:126)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(
PipelinesNode.java:101)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:336)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:277)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun
tNode.java:103)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i
nvoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P
ipelineNode.java:126)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(
PipelinesNode.java:101)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:336)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro
cessor.java:277)
at org.apache.cocoon.Cocoon.process(Cocoon.java:639)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1098)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:354)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationH
andler.java:294)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1808)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationCon
text.java:525)
at org.mortbay.http.HttpContext.handle(HttpContext.java:175

RE: Design of unmarshaling sitemap component

[Hunsberger, Peter]

DURDINA Michal <[EMAIL PROTECTED]> writes:
> > 
> > DURDINA Michal <[EMAIL PROTECTED]> writes:
> > 
> > > Hi,
> > > I would like to discuss the design problem of the sitemap
> > > component. My plan is to develop special let's call it 
> > > transformer for transforming sources for pages written or 
> > > generated by analysts (model) to dynamic pages generating 
> > > required results (implementation). The form of model is 
> > > custom XML according to given XMLSchema and the 
> > > implementation pages should be in form of jxtemplates (or xsp).
> > > 
> > > The transformation should go like this:
> > > 
> > > pipeline:
> > > additional data
> > >|
> > > modelXML -> populated modelXML -> computed model ->
> > jxtemplate source
> > > 
> > > The intent of the pipeline is to generate executable source
> > > from model that will generate required dynamic page. The 
> > > trick is that the computed modelXML is not trivial and should 
> > > be implemented as Java OM. 
> > 
> > Wow.  You're overall requirements sounds a lot like ours so I'm 
> > interested in how you reached this design?  Given your use of 
> > jxtemplate I can't see that it's performance driven? If 
> not, why not 
> > just keep everything in XML from end to end and use XSLT to 
> derive the 
> > computed model?
> > 
> > Castor/java implementation issues
> > 
> 
> Yes, keeping everything in XML and using XSLT would also 
> realize the transformation. Given that it would involve a XSL 
> stylesheet that will do all the computations. Such a 
> stylesheet would not be easy to write and it will be probably 
> too complex to maintain. Using Java for computation on input 
> XML should be more straightforward and using jxtemplate for 
> outputing the resulting XML gains from clear view how the 
> resulting XML will look like. Performance was not the main 
> requirement as the source generation occures only once and 
> then it is cached although this should perform better than XSLT.

Hmm, sounds to me like what you're really saying is that you've got good
Java skills around and not a lot of good XSLT skills?  Using a good
tools (like Stylus) I find XSLT in some ways a lot easier than Java. If
you're main goal is data transformation of any kind I believe the XSLT
will be easier to write and maintain than the Java, if you've got the
proper skill sets.

If you've got the kind of mind set that can be bent round XSLT then I'd
say it's worth learning for this kind of thing, you may be pleasantly
surprised.  However, it's certainly not everybody's cup of tea...

> I already started the implementation and have first version 
> of such a component implemented as a transformer (case A.). I 
> hope it will meet my requirements and we will profit form 
> this kind of concept.
 

RE: [RT] A Groovy Kind of Sitemap

[Hunsberger, Peter]

Nicola Ken Barozzi writes:
> 
> Ugo Cei wrote:
> 
> > Il giorno 30/lug/04, alle 00:24, Sylvain Wallez ha scritto:
> > 
> >> Don't take all this badly Ugo: I see much more dangers in 
> turning the
> >> sitemap into a scripting language than the advantages brought by 
> >> saving a few keystokes or the ease of implementation. But 
> I'm all for 
> >> a simplified implementation of the current syntax.
> ...
> 
> One thing I *hate* about flowscript is that it's in a different file 
> from the sitemap. Kinda like writing a java class with methods in one 
> file and fields in another.
> 
> Having both in the same file, even if with a different language but 
> still with a readable format (like python), would be really cool.

example, rational 

Interesting idea. I take it you don't consider XML a readable format?  

It seems to me 

Re: [proposal] Private Branches

[Pier Fumagalli]

On 29 Jul 2004, at 19:20, Stefano Mazzocchi wrote:
 http://svn.apache.org/repos/asf/cocoon/private/[id]
+1 i like this a lot! :-P
Pier


smime.p7s
Description: S/MIME cryptographic signature

Re: [RT] A Groovy Kind of Sitemap

[Pier Fumagalli]

On 28 Jul 2004, at 19:00, Stefano Mazzocchi wrote:
Personally, I like it as XML. :-)
Don't get me wrong, it's not that I don't like it... but many times it 
felt just too verbose for the task... so it would be kinda cool to 
have the ability to have two syntaxes.
As long as I don't have to rewrite my half-a-ton of sitemaps, I'm all 
right.

Pier


smime.p7s
Description: S/MIME cryptographic signature

RE: [RT] A Groovy Kind of Sitemap

[Hunsberger, Peter]

Stefano Mazzocchi <[EMAIL PROTECTED]> writes:
> 
> Geoff Howard wrote:
> 
> > Why insert this stream of consiousness into this 
> discussion?  I have a 
> > gut feeling that something in this discussion could lead to 
> a solution 
> > along these or totally new lines that cures this "uneasiness", or 
> > could make it even worse.
> 
> I feel the same way: sitemap and flowscript sometimes feel like 
> overseparating the concerns.
> 
> But like you, I don't know if a more scriptable syntax for 
> the pipelines 
> could allow us to solve this "uneasiness" or to make it worse... the 
> "sin" that comes to mind is dynamic pipelines... but isn't 
> this what we 
> are doing anyway with selectors and matchers?

I think this thread is sort of a critical issue for Cocoon.  It's
grappling with what is the general pattern behind request matching and
what is the simplest way to solve it.  

I'd also agree that I think the current separation of flow from page
production is somewhat clumsy. Just to bug you about this once more,
I'll note that by using XSLT you could keep everything in one file:
declare the sitemap as a variable and then write the flow production as
XSLT templates (heh, heh, hah)...

> [I've been learning a pipe of new programming languages lately.
> 
> I think you can tell ;-)]
> 
> The sitemap *is* a programming language. It's a pretty kickass one.
> 
> I was talking to Sam (Ruby), Ted (Leung) and Fitz (Brian Fitzpatrick) 
> comparing java and python (I'm sitting here at Guido's talk 
> about Python 
> 's state of the union) and they were waying that java is terrible for 
> xml programming while python is much better.
> 
> I said that the cocoon sitemap is a lot better than both 
> but it is 
> true that it's not a general purpose language.
> 
> cocoon has tons of reusable, first class, pipeline components... the 
> only other thing that has such a thing is the UNIX environment.
> 
> the sitemap has no parallel in UNIX. Is this good or bad? I 
> don't know.

How about the various shell processors?  Tons of procedural scripts
gluing pipelines together all over the place...

Other food for thought

Re: [proposal] Private Branches

[Dirk-Willem van Gulik]

On Thu, 29 Jul 2004, Stefano Mazzocchi wrote:

..snipped inspiring text about using SNV features and perhaps
  changing things so it fits our patterns better now that we 'can'.
...

> My proposal is to create a private branch for every committer that wants
> it and place it in
>
>   http://svn.apache.org/repos/asf/cocoon/private/[id]
>
>   1) allow people to experiment in their own place
>   2) allow stuff to happen without giving the impression that it is a
> "fork" or that the status quo is in danger
>   3) give the feeling of some privacy

This would worry me somewhat; within the ASF we try to help the community
develop software and value that a project survive an individuals slant on
it. It is the fact that the whole community follows all commits (by and
large), there is comprehensive peer review and that the whole community
stands behind a release which gives the ASF code that unique slant on
quality and liability.

Encouraging[*] this would in my opinion:

->  give rise to personal slants

->  allow certain takes of the code to be less of a group
product; but instead to be driven by 1 or 2 individuals

->  increase the risk that a wholesale chunk of code
which is developed without sufficient peer review is
subsequently introduced into the main brach without
enough appropriate oversight by the whole community.

which seems contrary to a certain spirit I personally hold dear when it
comes to the ASF.

A more neutral name; say 'note pad', 'scratrchpad' or 'skunk works' would
perhaps be more appropriate; as one stresses that it is people working
_together_ that counts.

Finally I personally would expect that -if- the ASF see a situation where
significant chunks of code are developed outside the normal main peer
reviewed track, and see such chunks suddenly imported in a main branch
-then- I do expect a discussion about exactly what peer review and
oversight is, and what the limits between 2.0 license, CLA and a Software
Grant really is.

Dw

*: Of course we would never disallow this. People can always
make their own private forks.

Re: [RT] A Groovy Kind of Sitemap

[Steven Noels]

On 30 Jul 2004, at 12:07, Vilya Harvey wrote:
A scripting language feels like overkill for simple pipelines, but the 
XML syntax is very awkward for more complicated ones. The appropriate 
choice comes down to how soon you feel that cutoff occurs, for the 
kind of sites you develop.
If the complexity of a sitemap becomes too troublesome to express using 
XML, I'm pretty sure adding yet another concern to the same artefact 
won't help - quite the contrary. I'm pretty sure some sitemaps "out 
there" are simply too complex because people use all sorts of twisted 
pipeline constructs and components, just to avoid writing some lines of 
flowscript or an Apple, or use Java proper. What some people feel like 
a disadvantage (splitting flow and pipelines into separate artefacts), 
I feel like a distinct advantage of Cocoon. With my peanut brains, I'm 
able to understand more advanced Cocoon apps when I see a  and some internal-only pipelines which are called by 
flow functions with a well described Map of input parameters. This is 
all highly personal, of course.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Re: [proposal] Private Branches

[Steven Noels]

On 30 Jul 2004, at 19:18, Dirk-Willem van Gulik wrote:
This would worry me somewhat;
Ditto here: +1.

--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

DO NOT REPLY [Bug 30417] New: - ImageReader needs "uniform scale-to-fit" option

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30417

ImageReader needs "uniform scale-to-fit" option

   Summary: ImageReader needs "uniform scale-to-fit" option
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


PROBLEM: I need to uniformly (i.e., preserving aspect ratio) scale an image for the 
best fit within a given 
box.

I've prepared a patch to support this.  It adds a  parameter to 
ImageReader.  This option 
honors the value of , so if  is "false",  
will reduce the 
image if necessary to fit it, but never enlarge.  The patch also updates the userdocs 
and includes 
corrections there (and in the javadoc annotations).

DO NOT REPLY [Bug 30417] - ImageReader needs "uniform scale-to-fit" option

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30417

ImageReader needs "uniform scale-to-fit" option





--- Additional Comments From [EMAIL PROTECTED]  2004-07-30 19:59 ---
Created an attachment (id=12281)
patch against SVN BRANCH_2_1_X implementing proposed enhancement

Re: [RT] A Groovy Kind of Sitemap

[Stefano Mazzocchi]

Pier Fumagalli wrote:
On 28 Jul 2004, at 19:00, Stefano Mazzocchi wrote:
Personally, I like it as XML. :-)

Don't get me wrong, it's not that I don't like it... but many times it 
felt just too verbose for the task... so it would be kinda cool to 
have the ability to have two syntaxes.

As long as I don't have to rewrite my half-a-ton of sitemaps, I'm all 
right.
it would be trivial to xslt-transform them anyway.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

[proposal - take 2] Whiteboard Branches

[Stefano Mazzocchi]

The private branches proposal didn't fly, so let's try again.
Same thing as the previous proposal but with the "whiteboard" name, 
"playground" kinda sucks and "research" would scare people way because 
it feels too serious.

comments?
--
Stefano.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [proposal - take 2] Whiteboard Branches

[David Crossley]

Stefano Mazzocchi wrote:
> The private branches proposal didn't fly, so let's try again.
> 
> Same thing as the previous proposal but with the "whiteboard" name, 
> "playground" kinda sucks and "research" would scare people way because 
> it feels too serious.
> 
> comments?

The term "whiteboard" is excellent. It has the connotation
of demonstrating to one's peers so that they can get a
clear picture.

We would need a "status" note in each whiteboard so that
people know when it is no longer in use. Or do whiteboards
get deleted when finished?

They are not necessarily only "branches". A whiteboard
can be anything.

-- 
David Crossley

DO NOT REPLY [Bug 28680] - HTML serialization has no space between publicId and systemId

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28680

HTML serialization has no space between publicId and systemId





--- Additional Comments From [EMAIL PROTECTED]  2004-07-31 04:01 ---
The Xalan bug:30142 has fixed this, thanks.

We still need to update Cocoon's Xalan.

DO NOT REPLY [Bug 30417] - [PATCH] ImageReader needs "uniform scale-to-fit" option

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30417

[PATCH] ImageReader needs "uniform scale-to-fit" option

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|ImageReader needs "uniform  |[PATCH] ImageReader needs
   |scale-to-fit" option|"uniform scale-to-fit"
   ||option