RE: Status of SVN Conversion!!!

[Carsten Ziegeler]

Really great work, thanks Vadim!!!

I think the next steps should be:
a) merge things back from 2.2 to the 2.1.x branch

   We should backport all bug fixes, especially the fix
   for the sitemap reloading problem.
   What do you think about tracing the status of the
   merge (which block has already, which needs to etc.)
   on the wiki?

b) clean up the directory for the new kernel proposal
   I think the new kernel should only contain the kernel
   but not the whole cocoon stuff; it's outdated anyway.
   Most of the stuff we have added to our cocoon-2.2 CVS
   repo is now in the cocoon/trunk (apart from the Fortress
   migration).

Carsten
> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, July 29, 2004 5:27 PM
> To: [EMAIL PROTECTED]
> Subject: Status of SVN Conversion!!!
> 
> Carsten Ziegeler wrote:
> 
> > Ok, it seems that it works (=compiles), but I think it's 
> not ready to go.
> 
> Sorry, guys - forgot to post status :-)
> 
> Cocoon 2.2-dev is here:
> http://svn.apache.org/repos/asf/cocoon/trunk/
> 
> Cocoon 2.1.6-dev is here:
> http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/
> 
> Cocoon Site is here:
> http://svn.apache.org/repos/asf/cocoon/site/
> 
> Cocoon released versions are all listed here:
> http://svn.apache.org/repos/asf/cocoon/tags/
> 
> Butterfly is here:
> http://svn.apache.org/repos/asf/cocoon/branches/butterfly/
> 
> 
> Committers have to use https:// protocol, users can use 
> http:// protocol. Committers have to create a password for 
> using Subversion by logging in to minotaur and running 
> "svnpasswd" command.
> 
> 
> For users of Cygwin, use cygwin's setup.exe to get cygwin 
> version of the subversion :-)
> 
> Vadim
> 

Re: [RT] A Groovy Kind of Sitemap

[Ugo Cei]

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. Something that once 
came to my mind as a possible way to implement the sitemap engine (and 
also JXTG) is Jelly, provided by the same James Strachan that made 
Groovy after he came to dislike pointy brackets.
I'm not taking this badly at all, Sylvain :-) I am perfectly aware of 
the risks involved in such an attempt. Indeed I  wrote (and you 
quoted): "I have to admit I'm ashamed at how bad and simpleminded the 
implementation of this is (you can find it in Butterfly's CVS). And 
propbably using a full-fledged scripting language isn't such a good 
idea (I already see people putting database access code in the 
sitemap)".

One of the reasons I came up with this "design" is that I'm trying to 
adopt a "tracer bullet" type of approach (if you haven't read Hunt and 
Thomas' "The Pragmatic Programmer" I suggest that you grab a copy and 
read it, it's highly recommended, or else you can find a description 
here [1]). 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.

I'm cutting short on this since I'm writing from the hall of my hotel 
(thanks to WiFi) and I should actually be already at my customers', but 
I think I got great feedback from you and from all the other people who 
participated in this thread. Starting tomorrow, I'll be on vacation for 
one week, but fully connected, so I hope to find the time and the 
clarity of mind to come up with something less dumb and simpleminded. 
Stay tuned!

Ugo
[1] http://www.artima.com/intv/tracer.html
--
Ugo Cei - http://beblogging.com/


smime.p7s
Description: S/MIME cryptographic signature

Re: [proposal] Private Branches

[Ugo Cei]

Il giorno 29/lug/04, alle 20:20, Stefano Mazzocchi ha scritto:
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
For example, I have a new version of linotype I'm working on that I 
would like to host there instead of my own CVS server.
Why can't you just upgrade the current linotype block?
Ugo
--
Ugo Cei - http://beblogging.com/


smime.p7s
Description: S/MIME cryptographic signature

Re: [RT] A Groovy Kind of Sitemap

[Antonio Gallardo]

Stefano Mazzocchi dijo:
> And let's keep in mind that groovy is not even release final (I talked
> to James Strachan yesterday about this.. and he's obviously very excited
> and told me a way to implement continuations in groovy once "macros" are
> built into the language... which is due in the near future).

This is a good notice! If Groovy comes with built-in continuations that
would be great for us! I mean in the flowEngine arena and perhaps else
where!

Best Regards,

Antonio Gallardo

Re: [RT] A Groovy Kind of Sitemap

[Antonio Gallardo]

Tony Collen dijo:
> Steven Noels wrote:
>
>> On 29 Jul 2004, at 20:40, Tony Collen wrote:
>
>>> Scripting languages (and programming languages in general) are easy to
>>> create, all you need to do is define the grammar and tokens, and feed
>>> it all to something like JFlex/BYacc to create a parser.  Perhaps it's
>>> easier said than done.  Granted, I've done nothing with parser
>>> generators, but in the end I think it's the same.
>>
>>
>> Agree, but I'm not convinced that we are just aiming for a simpler
>> syntax. I feel we're moving away from declarative, and I'm convinced
>> that this might reduce the predictability of Cocoon's behaviour and
>> usage model.
>
> For that matter, you can describe lots of things with a grammar that
> isn't necessarily a programming language, so perhaps I mis-spoke.  I
> simply thought that being able to define the sitemap with a grammar
> would allow us to create a parser that would parse the tree of the
> sitemap.

But with XML we already have the parser done (xerces). We don't need to
create a new one. The tokens comes automatically. I think this is part of
the XML idea or not? Going back to any grammar java-style I saw it as a
step back.

And for the action that add complexity to the overall sitemaps there is
the flowengine to save it.

I am not against testing and implement a new sitemap syntax, but I think
we need ideas why is good the change. As Stefano said, pehaps later we can
saw the real value of that. I am +1 for a test drive of the new grammar
and help in that where I can give a hand. I believe in Groovy and I think
is good to implement it in Groovy.

Best Regards,

Antonio Gallardo

RE: [proposal] Private Branches

[Corin Moss]

What about "playground"? Works for us over here, and give people
somewhere to throw their toys ;)

-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Friday, 30 July 2004 1:58 p.m.
To: [EMAIL PROTECTED]
Subject: Re: [proposal] Private Branches


Stefano Mazzocchi wrote:

>
> fine, what about
>
> 
> http://svn.apache.org/repos/asf/cocoon/(whiteboard|scratchpad|research
> )
>
> ?


No objections. But we should not use "scratchpad" - we already have one.

Vadim



CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.


For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

Re: [proposal] Private Branches

[Vadim Gritsenko]

Stefano Mazzocchi wrote:
fine, what about
 http://svn.apache.org/repos/asf/cocoon/(whiteboard|scratchpad|research)
?

No objections. But we should not use "scratchpad" - we already have one.
Vadim

Re: [RT] A Groovy Kind of Sitemap

[Tony Collen]

Steven Noels wrote:
On 29 Jul 2004, at 20:40, Tony Collen wrote:

Scripting languages (and programming languages in general) are easy to 
create, all you need to do is define the grammar and tokens, and feed 
it all to something like JFlex/BYacc to create a parser.  Perhaps it's 
easier said than done.  Granted, I've done nothing with parser 
generators, but in the end I think it's the same.

Agree, but I'm not convinced that we are just aiming for a simpler 
syntax. I feel we're moving away from declarative, and I'm convinced 
that this might reduce the predictability of Cocoon's behaviour and 
usage model.
For that matter, you can describe lots of things with a grammar that 
isn't necessarily a programming language, so perhaps I mis-spoke.  I 
simply thought that being able to define the sitemap with a grammar 
would allow us to create a parser that would parse the tree of the 
sitemap.

I've been jotting down sitemaps in shorthand notation myself ...
match *.html
  generate {1}.xml
  transform 2html.xsl
  serialize html
... a bit like the humiliated XML used in httpd.conf, but IIUC, what is 
being suggested ATM is the introduction of the usual programming 
language constructs in Cocoon's request handling configuration 
syntax 
I disagree. I think the only thing that is being suggested is a 
simpler syntax.  The fact that you can describe a programming language 
with a grammar and a document like this with a grammar shouldn't imply 
that we consider the sitemap a programming language.  It's far from 
Turing-complete, and I think we're smart enough to keep it that way by 
separating the Flowscript from the Sitemap.


isn't its quest for Turing-completeness one of the reasons 
why XSLT has been shunned by real developers: being too much and too 
little of a programming language at the same time? With a programming 
language-like sitemap language, we might end with the same result.
It may be true about XSLT, but with regards to the sitemap, we'll 
never know unless we try it.

I read mod_rewrite as an example, and I remember without looking up that 
the documentation of that module is the only one with a special foreword 
explaining/warning how wildly exotic it is.
Ugh, and even *with* the references there, it's almost impossible to 
get right :)

Regards,
Tony

Re: [RT] A Groovy Kind of Sitemap

[Stefano Mazzocchi]

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'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.
If we had "first class pipeline objects" as operators in a syntax would 
be good or bad?

Say we had a syntax like
[*]
  
would it be so hard to understand? would be so useful? I don't know.
it is true that no matter what, a new syntax for the sitemap is a lot of 
work.

And let's keep in mind that groovy is not even release final (I talked 
to James Strachan yesterday about this.. and he's obviously very excited 
and told me a way to implement continuations in groovy once "macros" are 
built into the language... which is due in the near future).

Anyway, food for thought.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] A Groovy Kind of Sitemap

[Geoff Howard]

I'm still in skimming mode, but I'll lob a nearly incoherent thought
in from the sidelines...

On Thu, 29 Jul 2004 10:34:29 -0700, Stefano Mazzocchi
<[EMAIL PROTECTED]> wrote:

...

> A little bit of history is needed:
> 
> - at the beginning there was no sitemap. all the pipeline machinery was
> "embedded" into documents using processing instructions. when it was
> proposed to move on, nobody ever objected.
> 
> - cocoon was still a publishing framework. this means it was meant to
> respond to "GET" requests. Pier and I sat down in his office in Erba
> (CO) in Italy and created the first draft of the sitemap. This was 4
> years ago. Given the high declarativity of the sitemap and given the
> impressive mind-bending nature of declarative languages that we had
> experienced for the first time a few years earlier with XSLT, the use of
> XSLT as a guiding path (and Pier's previous experience at IBM with
> StyleBook) was a no brainer. We *never* thought about a different syntax.
> 
> - the sitemap has not changed since then, if only a few things, mostly
> actions, and I was against them, but I saw the need and had no better
> idea (and no time at that time to spend more on it).
> 
> - actions soon showed weaknesses because the degree of reusability of
> actions is *much* lower than that of any other kind of sitemap
> component, showing that they are misplaced.
> 
> - the need to separate "resource production" from "flow control" can be
> seen as an extension of MVC where the view is a pipeline, the controller
> is a mix of flow control, business logic and glue between the two and
> the model is whatever you use to pass data from the two.
> 
> At this point, I went to Giacomo's in Zurich to talk about the
> "flowmap", as we called it at that time. We were so much ingrained into
> finite state machines that we didn't even think about the ability to
> "freeze the execution state" (which is what continuations are all about).
> 
> The flowmap, written in XML, was written on a few whiteboards, but it
> was so ugly that it was never even written into an RT.
> 
> It was Ovidiu that came with that idea and radically changed my way of
> thinking about this "flowmap", which soon became "flowscript".

I'm going to try to express a nagging feeling I don't like about the
current system of flow+sitemap:  It feels weird jumping from place to
place.  Requests come into the sitemap, have the matching/sitemap
rules applied, then possibly go out to flowscript, then back into the
sitemap - matched again, then processed.  So we have,
1) request matching (sitemap)
-
2) backend business logic (flowscript, flowscript-calling-java)
3) complex pipeline selection (flowscript, sendPage)
4) page flow control (flowscript, continuations)
-
5) pipeline construction/composition (sitemap)

At a gut level, something feels awkward about all that - not in any of
the individual pieces but more in how they stitch together/work
together.  I feel like I'd rather have the top section (item 1) and
the last one (item 5) not be the "same" (this is not a "symetry
argument by the way).  Obviously I'm implying some mixing of concerns
is happening, but I'm not sure I see where they are.

Maybe it's just that I'd rather that the uris used to go back to the
sitemap be simple named pipeline definitions with no new
matching/selection functions or no ability to go back into flow. 
Clearly delineated somehow as an endpoint, not room for further
decision branching.

Or maybe the problem is between the first two sections: I have to go
into the sitemap to get into flow, then go back to the sitemap
(somewhere else).  Maybe if some/all uris began being evaluated by
flow, which selected the pipeline, which then couldn't send back into
flow.

Maybe it's only that there is no distinction between the different
"pipeline" definitions in the sitemap, some are end-points, some are
entry-points and some are both.  Sort of a "map:receive" section, and
a "map:process" section, with slightly different rules betweent them.

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.

...

>  - o -
> 
> Instead of arguing about the status quo, let's give Ugo the space he
> needs to show us where we can innovate.

Of course.

> If Cocoon is what it is today, it's not because we remained where we
> were, but because we allowed people to innovate internally and with an
> open and friendly attitude and we "guided" our user base in new
> directions and never failed to provide them a better environment then
> before.
> 
> Let's NOT forget that.

Sounds good.
Geoff

Re: [proposal] Private Branches

[Sylvain Wallez]

Stefano Mazzocchi wrote:
I've been a strong believer in 'internal innovation', which means to 
give room for people to experiment.

We have now migrated onto SVN, which unlike CVS, has a great deal of 
support for moving things around and merging different parts of the 
tree together.

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]
The reason for this is:
 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

For example, I have a new version of linotype I'm working on that I 
would like to host there instead of my own CVS server.

And Ugo is playing with Butterfly, which should be there instead on 
"branches" alongside the "cocoon 2.1.6" branch!!

Thoughts?

-1 for people-private places. They will refrain "non-owners" to dig in 
and eventually work with the owner, and can lead to code ownership 
islands and one man shows.

What we need is a "cocoon/experiments/[name]" branch where name is 
"schecoon", "linotype", "butterfly", etc.

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

Re: [RT] A Groovy Kind of Sitemap

[Sylvain Wallez]

Reinhard Poetz wrote:
David Crossley wrote:
Miles Elam wrote:

Thanks Miles, you eloquently said everything that i wanted to say.
Miles, thank you too! I couldn't say it better!
+1 !
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [RT] A Groovy Kind of Sitemap

[Sylvain Wallez]

Ugo Cei wrote:
Dear Cocooners,
while working on Butterfly, I started looking at the TreeProcessor and 
I was astonished at the number of classes I have to port, if I want to 
reimplement it:

o.a.c.components.treeprocessor: 26 classes
o.a.c.components.treeprocessor.sitemap: 44 classes
o.a.c.components.treeprocessor.variables: 4 classes
Total: 74 classes.
Some of these classes have a rather complex inheritance hierarchy. 
Just to pick one at random: PreparableMatchNode inherits (directly and 
indirectly) from 6 classes and 10 interfaces!

Now this is a lot of code. Kudos to Sylvain for coming up with it and 
I'm sure the design is the best possible, given the constraints.

Mmmh... Thanks, but I easily admit that the TreeProcessor is 
over-designed, and I simplified it a bit recently. But a lot more can be 
done.

This has to be put back in perspective with where Cocoon was at that 
time (in late 2001): there were lots of talks at that time about 
flowmaps, i.e. another way to write pipelines in a flow-oriented way. 
Therefore, I architected the TreeProcessor as an evaluation tree that 
provided some abstractions meant to ease the implementation of alternate 
*map languages.

A goal was also to achieve maximum performance, and therefore to 
strongly separate build-time classes (can be slow) from runtime classes 
(must be fast). Hence the separation between ProcessingNode and 
ProcessingNodeBuilder which doubles the number of classes. That goal was 
achieved, as the new interpreted engine was even a bit faster than the 
previous compiled one.

But since, in doing Butterfly, I determined that we should not be too 
constrained by backward compatibility, I started thinking about a 
possible alternative, which should be, first of all, much simpler.

One thing that we would probably like to do without is the 
pointy-brackets kind of sitemap syntax. We could define a friendlier 
syntax of our own devising or we could reuse something. Since I'm a 
lazy butt and I like to reuse others' code whenever possible, I 
decided to reuse an existing grammar and parser. And I wanted it to be 
an executable grammar, that is a scripting language, since I wanted to 
avoid writing the code to execute a data structure. Last, I wanted to 
use something trendy ;-) so I came up with "A Groovy Kind of Sitemap" 
(sorry, Phil):

if (match ".*\.html") {
generate "input.xml"
transform "xslt", "stylesheet1.xsl"
transform "xslt", "stylesheet2.xsl"
serialize "xml"
}

At first, it looks clean and simple. How would it look like with 
component parameters?

But thinking further, this turns the sitemap in a full-blown programming 
language (see the "if" you've written?). Where's SoC then? It took us 
months with flowscript to allow removing procedural-like code with 
actions from the sitemaps, and I have high fears that a Groovy sitemap 
(or any other scripting language) will lead to a big mixing of 
everything, far worse than actions.

I don't really understand the current trend against pointy-brackets. Is 
it that people come to hate what they used to love so much? One of the 
goals in the design of XML was to provide a syntax that would be both 
easily human-readable and easliy machine-processable. IMO, the goal was 
well achieved, otherwise we would not see XML everywhere today.

Human-readable also includes learning. With XML, you just have to 
concentrate on the semantics of the elements and attributes, and not on 
the syntactic details (braces, semi-colons, commas, etc). This is also 
an important point in making a tool or technology acceptable by people: 
there are so many XML dialects around that learning a new one is not 
considered a problem (although the sitemap brings much more than just a 
dialect). Using a different programming language however, is much more 
difficult and will often hit the "management wall", that won't accept a 
babelization of languages used on a project. I know this by experience 
with the JS used in flowscript.

And machine-processable not only means parsers, but also tools and IDEs. 
Building an auto-completion engine for a completely new syntax is way 
more difficult than feeding an XML editor with a schema. There are also 
more and more editors like Eclipse's plugin.xml editor (e.g. EasyStruts 
or Spindle), which can simply be described by mapping form fields to 
XPath expressions (could it be that I have something like this for the 
sitemap on my Mac? ;-)

I have to admit I'm ashamed at how bad and simpleminded the 
implementation of this is (you can find it in Butterfly's CVS). And 
propbably using a full-fledged scripting language isn't such a good 
idea (I already see people putting database access code in the 
sitemap), but it took no more than two hours to implement (one and 
half spent trying to make sense of Groovy's scattered docs), so it's 
definitely simple.

Implementation details aside, I think this is something that we can 
experi

extract Java continuations?

[Mark Chrisman]

Title: Message



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.
 
 
 
 

Re: [proposal] Private Branches

[Stefano Mazzocchi]

Steven Noels wrote:
On 29 Jul 2004, at 20:20, 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]

Thoughts?

I know I'm at the verge of becoming a traditionalist, but IMHO we should 
never create personal freewheeling areas for reasons of false ownership 
feelings and oversight. Who has still some sort of semi-complete 
knowledge coverage over the Cocoon source trees? Wouldn't that become 
even harder with these private directories?

We should be able to contain such stuff into a clearly marked, but 
not-tied-to-a-person area. 
fine, what about
 http://svn.apache.org/repos/asf/cocoon/(whiteboard|scratchpad|research)
?
The ASF infrastructure shouldn't serve as a 
personal backup solution, no?
that's uncalled for.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Gump Issue

[Stefano Mazzocchi]

Adam R. B. Jack wrote:

BTW: It seems to have worked:
http://brutus.apache.org/gump/public/cocoon-2.1/gump_work/update_cocoon-2.1.html
Although it seems there may still be something to fix:
http://brutus.apache.org/gump/public/cocoon-2.1/cocoon/gump_work/build_cocoon-2.1_cocoon.html
http://brutus.apache.org/gump/public/cocoon-2.1/cocoon/gump_work/build_cocoon-2.1_cocoon.txt
  [javac]
/usr/local/gump/public/workspace/cocoon-2.1/src/java/org/apache/cocoon/compo
nents/store/impl/JCSDefaultStore.java:361: dispose() in
org.apache.cocoon.components.store.impl.JCSDefaultStore.JCSCacheAccess
cannot override dispose() in org.apache.jcs.access.CacheAccess; attempting
to assign weaker access privileges; was public
[javac] protected void dispose() {
[javac]^
[javac] 1 error
hmmm, seems like JCS changed their contract from protected to public.
BTW: I noticed some .cvsignore files. I suspect you ought  convert those to
.svnignore files.
there is no such thing as .svnignore files ;-)
but yeah, we should get rid of those .cvsignore files and move them into 
"svn propedit svn:ignore ."

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [proposal] Private Branches

[Steven Noels]

On 29 Jul 2004, at 20:20, 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]

Thoughts?
I know I'm at the verge of becoming a traditionalist, but IMHO we 
should never create personal freewheeling areas for reasons of false 
ownership feelings and oversight. Who has still some sort of 
semi-complete knowledge coverage over the Cocoon source trees? Wouldn't 
that become even harder with these private directories?

We should be able to contain such stuff into a clearly marked, but 
not-tied-to-a-person area. The ASF infrastructure shouldn't serve as a 
personal backup solution, no?


--
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: [GUMP][PATCH] cocoon seems to require log4j

[Adam R. B. Jack]

> > I'll change that. And, I see that the cocoon repository (as metadata has
it
> > in Gump) is still marked as CVS, not SVN. I'll change that also..

BTW: It seems to have worked:


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

Although it seems there may still be something to fix:


http://brutus.apache.org/gump/public/cocoon-2.1/cocoon/gump_work/build_cocoon-2.1_cocoon.html

http://brutus.apache.org/gump/public/cocoon-2.1/cocoon/gump_work/build_cocoon-2.1_cocoon.txt

  [javac]
/usr/local/gump/public/workspace/cocoon-2.1/src/java/org/apache/cocoon/compo
nents/store/impl/JCSDefaultStore.java:361: dispose() in
org.apache.cocoon.components.store.impl.JCSDefaultStore.JCSCacheAccess
cannot override dispose() in org.apache.jcs.access.CacheAccess; attempting
to assign weaker access privileges; was public
[javac] protected void dispose() {
[javac]^
[javac] 1 error
BTW: I noticed some .cvsignore files. I suspect you ought  convert those to
.svnignore files.

> thanks adam!

You are welcome.

regards

Adam

Re: [RT] A Groovy Kind of Sitemap

[Steven Noels]

On 29 Jul 2004, at 20:40, Tony Collen wrote:
Steven Noels wrote:
&snip;
IMHO, simplicity has to do with predictability. XML grammars have 
this, scripting languages don't. While the use of a non-XML 
(scripting?) grammar for the site/flowmap might be clever, it might 
reduce the predictability. Too much magic for my poor brains. And 
even XML happens to be abused at times.
Scripting languages (and programming languages in general) are easy to 
create, all you need to do is define the grammar and tokens, and feed 
it all to something like JFlex/BYacc to create a parser.  Perhaps it's 
easier said than done.  Granted, I've done nothing with parser 
generators, but in the end I think it's the same.
Agree, but I'm not convinced that we are just aiming for a simpler 
syntax. I feel we're moving away from declarative, and I'm convinced 
that this might reduce the predictability of Cocoon's behaviour and 
usage model.

I've been jotting down sitemaps in shorthand notation myself ...
match *.html
  generate {1}.xml
  transform 2html.xsl
  serialize html
... a bit like the humiliated XML used in httpd.conf, but IIUC, what is 
being suggested ATM is the introduction of the usual programming 
language constructs in Cocoon's request handling configuration 
syntax isn't its quest for Turing-completeness one of the reasons 
why XSLT has been shunned by real developers: being too much and too 
little of a programming language at the same time? With a programming 
language-like sitemap language, we might end with the same result.

I read mod_rewrite as an example, and I remember without looking up 
that the documentation of that module is the only one with a special 
foreword explaining/warning how wildly exotic it is.


--
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: [RT] A Groovy Kind of Sitemap

[Tony Collen]

Steven Noels wrote:
&snip;
IMHO, simplicity has to do with predictability. XML grammars have this, 
scripting languages don't. While the use of a non-XML (scripting?) 
grammar for the site/flowmap might be clever, it might reduce the 
predictability. Too much magic for my poor brains. And even XML happens 
to be abused at times.
Scripting languages (and programming languages in general) are easy to 
create, all you need to do is define the grammar and tokens, and feed 
it all to something like JFlex/BYacc to create a parser.  Perhaps it's 
easier said than done.  Granted, I've done nothing with parser 
generators, but in the end I think it's the same.

Although you need to be careful about creating an ambiguous grammar, 
and I'm not sure how many parser/compiler people we have lurking on 
the lists.

Torsten mentioned his ideas about the sitemap as an abstract syntax 
tree, and I think there's quite a bit of merit there. I'm also on the 
context-free language kick since we're looking at them in my Automata 
and Theory of Computation class.

I'm going to gather my thoughts about the sitemap and CFL's and see 
what I come up with.

Tony

[proposal] Private Branches

[Stefano Mazzocchi]

I've been a strong believer in 'internal innovation', which means to 
give room for people to experiment.

We have now migrated onto SVN, which unlike CVS, has a great deal of 
support for moving things around and merging different parts of the tree 
together.

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]
The reason for this is:
 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

For example, I have a new version of linotype I'm working on that I 
would like to host there instead of my own CVS server.

And Ugo is playing with Butterfly, which should be there instead on 
"branches" alongside the "cocoon 2.1.6" branch!!

Thoughts?
--
Stefano.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] A Groovy Kind of Sitemap

[Steven Noels]

On 29 Jul 2004, at 19:34, Stefano Mazzocchi wrote:
A little bit of history is needed:
Thanks for your recount of my lurking years. :-)
Now, for those who were not there at that time: Ovidiu's proposal was 
*NOT* accepted happily. For the most part, it was not understood until 
several months later. Any mind-bending change of direction is, at 
first, perceived as creating instability.
I happen to like Ugo's idea to start from scratch with a new 
implementation of Cocoon.

Ugo (like many others, myself included) is sick of being scared with 
the complexity of cocoon's code, which strongly reduced his ability to 
improve on it. His "extreme programming" approach is rather evident: 
do the simplest thing that can possibly work.
Isn't that also what a user would expect from a framework: a simple 
thing which just works?

If Cocoon is what it is today, it's not because we remained where we 
were, but because we allowed people to innovate internally and with an 
open and friendly attitude and we "guided" our user base in new 
directions and never failed to provide them a better environment then 
before.
IMHO, simplicity has to do with predictability. XML grammars have this, 
scripting languages don't. While the use of a non-XML (scripting?) 
grammar for the site/flowmap might be clever, it might reduce the 
predictability. Too much magic for my poor brains. And even XML happens 
to be abused at times.

I figure Ugo picked Groovy because it is cool. (I'm not a language 
expert, but JavaScript seems cool enough already, and a tad less 
immature and trendy than Groovy.) My main concern however is that the 
separation between pipeline definitions and processing flow is what 
differentiates Cocoon from many other frameworks, yet this is still 
something that our users are only beginning to pick up. Many people are 
still stuck with monstrous sitemaps using all kinds of 
action/inputmodule/transformer chains - and I don't know whether they 
will be helped with an even more flexible configuration mechanism.

WDYT?

--
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: [GUMP][PATCH] cocoon seems to require log4j

[Stefano Mazzocchi]

Adam R. B. Jack wrote:
Sorry, we were in the middle of switching to use SVN.
Patches applied now to depend logging-log4j and to
enable Gump to use our new SVN trunk.

I knew that was occurring, I wasn't thinking, sorry. Thanks for working on
it, and getting this done.
Now you are using SVN with it's built in 'simple viewcvs' it probably makes
sense to reference the cocoon descriptor (in profile/gump.xml) using:
http://svn.apache.org/repos/asf/cocoon/trunk/gump.xml
I'll change that. And, I see that the cocoon repository (as metadata has it
in Gump) is still marked as CVS, not SVN. I'll change that also..
Also, one thing Gump does not do automatically yet, is follow a migration
from CVS to SVN (when it has a copy of a module's directory from an SCM it
does an update not a checkout). As such, I'll manually remove the
./workspace/cvs/cocoon-2.1 directory on Brutus [from the public and jdk15
flavours], to allow it to checkout from SVN.
thanks adam!
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] A Groovy Kind of Sitemap

[Stefano Mazzocchi]

Steven Noels wrote:
On 29 Jul 2004, at 09:19, Marc Portier wrote:
Rest assured I'm equally concerned with a number of other voices here 
about (using Ugo's wording) 'giving just more rope to hang yourself in'
However, when I see people 'removing and merging' then I can only see 
less rope :-)

IMHO we need to be honest/modest about how far any cocoon-user 
actually wants to be 'guided' and 'helped'.

Collating both points into one concern: with the current Cocoon, we 
already provide quite some rope, in the sense that I've seen a 
separation between what developers *intend* to be used, and what users 
*want* to use of Cocoon's broad set of features.

Contrarily to httpd.conf/mod_rewrite-land, where there's "just the HTTP 
spec" to implement, we are at liberty to put any kind of behaviour in 
any component or block of Cocoon. That leads us to the situation where a 
developer can create a block of functionality just to get a feel of 
whether it makes any sense, but suddenly users pick it up and start 
exploiting the thing as if it is production-ready code, expecting or 
hoping for some form of support, even when they exploit it beyond what 
it has been intended for.

I believe the Cocoon users expect guidance and help beyond what they get 
now, and we shouldn't provide more scriptable rope to hang themselves 
with. This of course depends on what we believe Joe Average Cocoon user 
is - and if we expect Joe to subscribe to the developers list to 
understand what our intentions were. :-)
A little bit of history is needed:
- at the beginning there was no sitemap. all the pipeline machinery was 
"embedded" into documents using processing instructions. when it was 
proposed to move on, nobody ever objected.

- cocoon was still a publishing framework. this means it was meant to 
respond to "GET" requests. Pier and I sat down in his office in Erba 
(CO) in Italy and created the first draft of the sitemap. This was 4 
years ago. Given the high declarativity of the sitemap and given the 
impressive mind-bending nature of declarative languages that we had 
experienced for the first time a few years earlier with XSLT, the use of 
XSLT as a guiding path (and Pier's previous experience at IBM with 
StyleBook) was a no brainer. We *never* thought about a different syntax.

- the sitemap has not changed since then, if only a few things, mostly 
actions, and I was against them, but I saw the need and had no better 
idea (and no time at that time to spend more on it).

- actions soon showed weaknesses because the degree of reusability of 
actions is *much* lower than that of any other kind of sitemap 
component, showing that they are misplaced.

- the need to separate "resource production" from "flow control" can be 
seen as an extension of MVC where the view is a pipeline, the controller 
is a mix of flow control, business logic and glue between the two and 
the model is whatever you use to pass data from the two.

At this point, I went to Giacomo's in Zurich to talk about the 
"flowmap", as we called it at that time. We were so much ingrained into 
finite state machines that we didn't even think about the ability to 
"freeze the execution state" (which is what continuations are all about).

The flowmap, written in XML, was written on a few whiteboards, but it 
was so ugly that it was never even written into an RT.

It was Ovidiu that came with that idea and radically changed my way of 
thinking about this "flowmap", which soon became "flowscript".

  - o -
Now, for those who were not there at that time: Ovidiu's proposal was 
*NOT* accepted happily. For the most part, it was not understood until 
several months later. Any mind-bending change of direction is, at first, 
perceived as creating instability.

Add the fact that Ovidiu's examples were in Scheme (not exactly a 
friendly language for {}-oriented people like java programmers), but the 
real problem, IMO, was that it was "sinful" for many reasons:

 1) weak-typing
 2) interpreted scripting (perceived as too slow)
 3) esoteric concepts (continuations)
 4) weird syntax (scheme)
it was too much change to percieve anything useful from it.
There was *a lot* of resistance to his proposal, but I personally saw a 
great deal of value in what he was doing (the ability to get rid of FSM 
once and for all!), showing us a path where we could finally get rid of 
action pollution in the sitemap.

Ovidiu was allowed to create a private branch inside the cocoon CVS 
(codename "schecoon" out of "scheme-cocoon") and we let him play.

Later, upon our suggestions that Scheme's syntax was too hard for our 
audience to understand, he found Chris' version of Rhino with 
continuations and the rest is history.

  - o -
Now.
Ugo (like many others, myself included) is sick of being scared with the 
complexity of cocoon's code, which strongly reduced his ability to 
improve on it. His "extreme programming" approach is rather eviden

RE: Design of unmarshaling sitemap component

[Hunsberger, Peter]

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

RE: [RT] A Groovy Kind of Sitemap

[Hunsberger, Peter]

Conal Tuohy <[EMAIL PROTECTED]> writes:

> Peter Hunsberger wrote:
> 
> > As others have said, one needs to step back and look at the overall
> > objective: what do you want Cocoon to do when you feed it a request 
> > (either via http or CLI or whatever)?  Figure out all the 
> high level 
> > use cases and their interactions, step back, generalize and repeat.
> > Personally, I end up with something more like RDF and 
> > ontology traversal
> > than I do with scripting...  I don't think many people could 
> > afford the
> > hardware to do that in real-time for large scale web sites, 
> so I come
> > back to XML technologies as a reasonable compromise for the 
> near term.
> 
> I don't know if this is exactly what you're thinking of, but 
> at my work we are developing something which sounds similar - 
> using XML Topic Maps rather than RDF - and I think (hope) it 
> will be a powerful technique for knowledge-intensive sites. 
> 
> There are 3 parts to it: 
> 1) harvesting or mining the knowledge from the various 
> sources (we use XSLT in Cocoon pipelines to extract knowledge 
> and encode it as XTM).
> 2) using the semantic network to structure the website itself.

Sounds sort of similar.  We're not really trying to manage generalized
semantic navigation (though just today I questioned whether we should be
over on xml-dev).  We're sort of doing both less and more: less in that
we depend very much on a specific representational format, and more in
that we recognize and optimize for specific types of relationship
traversal.

> For this second part we have a sitemap which handles all 
> requests with a simple flowscript, passing it the request 
> information. This flowscript looks up the requested topic (a 
> concept) in the topic map database (we use TM4J with 
> Hibernate). Then it finds an appropriate jxtemplate for 
> rendering that topic, and calls sendPage(jxtemplate, topic) 
> to render it. The jxtemplate is responsible for rendering 
> topics and inserting xinclude statements to aggregate topic 
> occurrences (resources). So 90% of the sitemap consists of 
> pipelines for rendering various occurrences, but totally 
> decoupled from the website's external URI space. These 
> pipelines are consumed by the rendering templates. The 
> logical structure of the site is entirely in the topic map, 
> the choice of page layout for each type of topic is also in 
> the topic map, but the page layouts themselves are just jxtemplates.
> 

Hmm, in our case the page layouts are XML templates store in a database;
we have many variations on a given layout.  Sounds like different
general use cases, but a somewhat similar approach.

 

Re: [RT] A Groovy Kind of Sitemap

[Reinhard Poetz]

David Crossley wrote:
Miles Elam wrote:

Thanks Miles, you eloquently said everything
that i wanted to say.
 

Miles, thank you too! I couldn't say it better!
--
Reinhard

Status of SVN Conversion!!!

[Vadim Gritsenko]

Carsten Ziegeler wrote:
Ok, it seems that it works (=compiles), but I think it's not ready to go.
Sorry, guys - forgot to post status :-)
Cocoon 2.2-dev is here:
   http://svn.apache.org/repos/asf/cocoon/trunk/
Cocoon 2.1.6-dev is here:
   http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/
Cocoon Site is here:
   http://svn.apache.org/repos/asf/cocoon/site/
Cocoon released versions are all listed here:
   http://svn.apache.org/repos/asf/cocoon/tags/
Butterfly is here:
   http://svn.apache.org/repos/asf/cocoon/branches/butterfly/
Committers have to use https:// protocol, users can use http:// 
protocol. Committers have to create a password for using Subversion by 
logging in to minotaur and running "svnpasswd" command.

For users of Cygwin, use cygwin's setup.exe to get cygwin version of the 
subversion :-)

Vadim

Re: [GUMP][PATCH] cocoon seems to require log4j

[Adam R. B. Jack]

> Sorry, we were in the middle of switching to use SVN.
> Patches applied now to depend logging-log4j and to
> enable Gump to use our new SVN trunk.

I knew that was occurring, I wasn't thinking, sorry. Thanks for working on
it, and getting this done.

Now you are using SVN with it's built in 'simple viewcvs' it probably makes
sense to reference the cocoon descriptor (in profile/gump.xml) using:

http://svn.apache.org/repos/asf/cocoon/trunk/gump.xml

I'll change that. And, I see that the cocoon repository (as metadata has it
in Gump) is still marked as CVS, not SVN. I'll change that also..

Also, one thing Gump does not do automatically yet, is follow a migration
from CVS to SVN (when it has a copy of a module's directory from an SCM it
does an update not a checkout). As such, I'll manually remove the
./workspace/cvs/cocoon-2.1 directory on Brutus [from the public and jdk15
flavours], to allow it to checkout from SVN.

regards,

Adam

RE: Cocoon latest version

[Halgurt Mustafa-Ali]

Hi,

Thank you very much, I will try that and tell you if it works.

Best regards,
Halgurt
>X-Sieve: CMU Sieve 2.2
>Delivered-To: [EMAIL PROTECTED]
>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
>list-help: 
>list-unsubscribe: 
>list-post: 
>Delivered-To: mailing list [EMAIL PROTECTED]
>X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=
>X-Spam-Check-By: apache.org
>From: "Carsten Ziegeler" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Subject: RE: Cocoon latest version
>Date: Thu, 29 Jul 2004 12:41:24 +0200
>MIME-Version: 1.0
>X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>Thread-Index: AcR1VH7nirHNL9oPR5WtN+gLdcNWGwAAislw
>X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release 
6.5|September 26, 2003) at 29.07.2004 12:33:33, Serialize by Router on 
PBSN1/Systeme und Netzwerke(Release 6.5|September 26, 2003) at 29.07.2004 
12:33:34, Serialize complete at 29.07.2004 12:33:34
>Content-Transfer-Encoding: 7bit
>X-Virus-Checked: Checked
>X-Spam-Checker-Version: SpamAssassin 2.63-tuminfo (2004-01-11) on  
mailin2.informatik.tu-muenchen.de
>X-Spam-Status: No, hits=-4.9 required=6.0 tests=BAYES_00 autolearn=ham  
version=2.63-tuminfo
>X-Spam-Level: 
>X-Virus-Scanned: by amavisd-new at informatik.tu-muenchen.de
>
>> -Original Message-
>> From: Halgurt Mustafa-Ali [mailto:[EMAIL PROTECTED] 
>> Hi,
>> 
>> Thanks for replying. Please see the Attachment for the code 
>> and the error message.
>> 
>Ok, I guess the problem lies in this line:
>
>>   super.startElement ("", "result", "result", null); 
>
>You have to pass an Attributes object with this method. If you don't 
>have attributes, use an empty one. It is not allowed to pass "null".
>
>It might be that the version of Xalan we used in 2.1.4 wasn't that picky
>and the one in 2.1.5 is.
>
>So check for all startElement calls and change them.
>
>> Best regards,
>> Halgurt
>> PS: Sind sie deutsche Herr Ziegeler? Ich kann ihnen auf 
>> deutsch mehr erklaeren.
>> 
>Yes, I am :) Let's keep this discussion here in english so others can
>follow what's going on.
>
>HTH
>
>Carsten 
>
>Carsten Ziegeler 
>Open Source Group, S&N AG
>http://www.s-und-n.de
>http://www.osoco.net/weblogs/rael/
>

RE: Cocoon latest version

[Carsten Ziegeler]

> -Original Message-
> From: Halgurt Mustafa-Ali [mailto:[EMAIL PROTECTED] 
> Hi,
> 
> Thanks for replying. Please see the Attachment for the code 
> and the error message.
> 
Ok, I guess the problem lies in this line:

>   super.startElement ("", "result", "result", null); 

You have to pass an Attributes object with this method. If you don't 
have attributes, use an empty one. It is not allowed to pass "null".

It might be that the version of Xalan we used in 2.1.4 wasn't that picky
and the one in 2.1.5 is.

So check for all startElement calls and change them.

> Best regards,
> Halgurt
> PS: Sind sie deutsche Herr Ziegeler? Ich kann ihnen auf 
> deutsch mehr erklaeren.
> 
Yes, I am :) Let's keep this discussion here in english so others can
follow what's going on.

HTH

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.net/weblogs/rael/

RE: Cocoon latest version

[Halgurt Mustafa-Ali]

>X-Sieve: CMU Sieve 2.2
>Delivered-To: [EMAIL PROTECTED]
>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
>list-help: 
>list-unsubscribe: 
>list-post: 
>Delivered-To: mailing list [EMAIL PROTECTED]
>X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=
>X-Spam-Check-By: apache.org
>From: "Carsten Ziegeler" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Subject: RE: Cocoon latest version
>Date: Thu, 29 Jul 2004 11:42:47 +0200
>MIME-Version: 1.0
>X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>Thread-Index: AcR1TthMiEcM4ZKNStyrlt79qieNfQAAVBuA
>X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release 
6.5|September 26, 2003) at 29.07.2004 11:34:56, Serialize by Router on 
PBSN1/Systeme und Netzwerke(Release 6.5|September 26, 2003) at 29.07.2004 
11:34:57, Serialize complete at 29.07.2004 11:34:57
>Content-Transfer-Encoding: 7bit
>X-Virus-Checked: Checked
>X-Spam-Checker-Version: SpamAssassin 2.63-tuminfo (2004-01-11) on  
mailin1.informatik.tu-muenchen.de
>X-Spam-Status: No, hits=-4.9 required=6.0 tests=BAYES_00 autolearn=ham  
version=2.63-tuminfo
>X-Spam-Level: 
>X-Virus-Scanned: by amavisd-new at informatik.tu-muenchen.de
>
Hi,

Thanks for replying. Please see the Attachment for the code and the error 
message.

Best regards,
Halgurt
PS: Sind sie deutsche Herr Ziegeler? Ich kann ihnen auf deutsch mehr erklaeren.

>Hi,
>
>a transformer for 2.1.4 should work under 2.1.5 - I'm not
>aware of any incompatible changes/problems in this area.
>
>Can you show us your source code, this might give us a clue.
>
>Carsten
>
>> -Original Message-
>> From: Halgurt Mustafa-Ali [mailto:[EMAIL PROTECTED] 
>> Sent: Thursday, July 29, 2004 11:38 AM
>> To: [EMAIL PROTECTED]
>> Subject: Cocoon latest version
>> 
>> Hi,
>> 
>> I wrote a customer transformer, it works quite ok with 
>> cocoon2.1.4. Now I updated cocoon to the latest version and I 
>> get these errors below, have you changes anything? always 
>> when I want to create a new element calling the method
>> (startElement()) I get the error, can anybody help me please:
>> 


RDQLTransformer.java
Description: RDQLTransformer.java
Original Exception: java.lang.NullPointerException
at 
org.apache.cocoon.serialization.AbstractTextSerializer$NamespaceAsAttributes.startElement(AbstractTextSerializer.java:424)
at org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:95)
at org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:95)
at RDQLTransformer.endElement(RDQLTransformer.java:414)
at org.apache.cocoon.components.sax.XMLTeePipe.endElement(XMLTeePipe.java:89)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:296)
at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315)
at org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:211)
at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:117)
at 
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:247)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:478)
at 
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:134)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:54)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:112)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:76)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:76)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:95)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:298)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:241)
at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:238)
at 
org.apache.cocoon.components

[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 4 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-20040729/test]
 -INFO- Enable "verbose" output, due to 4 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-20040729/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-20040729/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: 12 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-20040729.jar
 
-Dlogkit.jar=/usr/local/gump/public/workspace/avalon-logkit/target/avalon-logkit-20040729.jar
 -Dversion=20040729 gump-core 
[Working Directory: /usr/local/gump/public/workspace/cocoon-2.

RE: Cocoon latest version

[Carsten Ziegeler]

Hi,

a transformer for 2.1.4 should work under 2.1.5 - I'm not
aware of any incompatible changes/problems in this area.

Can you show us your source code, this might give us a clue.

Carsten

> -Original Message-
> From: Halgurt Mustafa-Ali [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, July 29, 2004 11:38 AM
> To: [EMAIL PROTECTED]
> Subject: Cocoon latest version
> 
> Hi,
> 
> I wrote a customer transformer, it works quite ok with 
> cocoon2.1.4. Now I updated cocoon to the latest version and I 
> get these errors below, have you changes anything? always 
> when I want to create a new element calling the method
> (startElement()) I get the error, can anybody help me please:
> 
> Original Exception: java.lang.NullPointerException at 
> org.apache.cocoon.serialization.AbstractTextSerializer$Namespa
ceAsAttributes.sta
> rtElement(AbstractTextSerializer.java:424)
> at 
> org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXML
> Pipe.java:95)
> at 
> org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXML
> Pipe.java:95)
> at RDQLTransformer.endElement(RDQLTransformer.java:414)
> at 
> org.apache.cocoon.components.sax.XMLTeePipe.endElement(XMLTeeP
> ipe.java:89)
> at 
> org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
>  Source) at 
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$Fragment
ContentDispatcher.
> dispatch(Unknown Source)
> at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocu
> ment(Unknown
> Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown 
> Source) at 
> org.apache.xerces.parsers.XML11Configuration.parse(Unknown 
> Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown 
> Source) at 
> org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown 
> Source) at 
> org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:296)
> at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315)
> at 
> org.apache.cocoon.components.source.SourceUtil.parse(SourceUti
> l.java:211)
> at 
> org.apache.cocoon.generation.FileGenerator.generate(FileGenera
> tor.java:117)
> at
> org.apache.cocoon.components.pipeline.impl.AbstractCachingProc
> essingPipeline.pro
> cessXMLPipeline(AbstractCachingProcessingPipeline.java:247)
> at
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeli
> ne.process(Abstrac
> tProcessingPipeline.java:478)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.SerializeNo
> de.invoke(Serializ
> eNode.java:134)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProce
> ssingNode.invokeNo
> des(AbstractParentProcessingNode.java:54)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableM
> atchNode.invoke(Pr
> eparableMatchNode.java:112)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProce
> ssingNode.invokeNo
> des(AbstractParentProcessingNode.java:76)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNod
> e.invoke(PipelineN
> ode.java:126)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProce
> ssingNode.invokeNo
> des(AbstractParentProcessingNode.java:76)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNo
> de.invoke(Pipeline
> sNode.java:95)
> at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcess
> or.process(Concret
> eTreeProcessor.java:298)
> at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcess
> or.process(Concret
> eTreeProcessor.java:241)
> at
> org.apache.cocoon.components.treeprocessor.TreeProcessor.proce
> ss(TreeProcessor.j
> ava:238)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.MountNode.i
> nvoke(MountNode.ja
> va:100)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProce
> ssingNode.invokeNo
> des(AbstractParentProcessingNode.java:54)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableM
> atchNode.invoke(Pr
> eparableMatchNode.java:112)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProce
> ssingNode.invokeNo
> des(AbstractParentProcessingNode.java:76)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNod
> e.invoke(PipelineN
> ode.java:126)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProce
> ssingNode.invokeNo
> des(AbstractParentProcessingNode.java:76)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNo
> de.invoke(Pipeline
> sNode.java:95)
> at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcess
> or.process(Concret
> eTreeProcessor.java:298)
> at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcess
> or.process(Concret
> eTreeProcessor.java:241)
> at
> org.apache.cocoon.components.treeprocessor.TreeProcessor.proce
> ss(TreeProcessor.j
> ava:238)
> at org.apache.cocoon.Cocoon.process(Cocoon.java:643)
> at 
> org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.
> java:1123)
> at javax.servlet.http.Http

Re: [RT] A Groovy Kind of Sitemap

[Steven Noels]

On 29 Jul 2004, at 09:19, Marc Portier wrote:
Rest assured I'm equally concerned with a number of other voices here 
about (using Ugo's wording) 'giving just more rope to hang yourself 
in'
However, when I see people 'removing and merging' then I can only see 
less rope :-)

IMHO we need to be honest/modest about how far any cocoon-user 
actually wants to be 'guided' and 'helped'.
Collating both points into one concern: with the current Cocoon, we 
already provide quite some rope, in the sense that I've seen a 
separation between what developers *intend* to be used, and what users 
*want* to use of Cocoon's broad set of features.

Contrarily to httpd.conf/mod_rewrite-land, where there's "just the HTTP 
spec" to implement, we are at liberty to put any kind of behaviour in 
any component or block of Cocoon. That leads us to the situation where 
a developer can create a block of functionality just to get a feel of 
whether it makes any sense, but suddenly users pick it up and start 
exploiting the thing as if it is production-ready code, expecting or 
hoping for some form of support, even when they exploit it beyond what 
it has been intended for.

I believe the Cocoon users expect guidance and help beyond what they 
get now, and we shouldn't provide more scriptable rope to hang 
themselves with. This of course depends on what we believe Joe Average 
Cocoon user is - and if we expect Joe to subscribe to the developers 
list to understand what our intentions were. :-)


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

Cocoon latest version

[Halgurt Mustafa-Ali]

Hi,

I wrote a customer transformer, it works quite ok with cocoon2.1.4. Now I 
updated cocoon to the latest version and I get these errors below, have you 
changes anything? always when I want to create a new element calling the method 
(startElement()) I get the error, can anybody help me please:

Original Exception: java.lang.NullPointerException
at 
org.apache.cocoon.serialization.AbstractTextSerializer$NamespaceAsAttributes.sta
rtElement(AbstractTextSerializer.java:424)
at org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:95)
at org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:95)
at RDQLTransformer.endElement(RDQLTransformer.java:414)
at org.apache.cocoon.components.sax.XMLTeePipe.endElement(XMLTeePipe.java:89)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown 
Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.
dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:296)
at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315)
at org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:211)
at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:117)
at 
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.pro
cessXMLPipeline(AbstractCachingProcessingPipeline.java:247)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(Abstrac
tProcessingPipeline.java:478)
at 
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(Serializ
eNode.java:134)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo
des(AbstractParentProcessingNode.java:54)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(Pr
eparableMatchNode.java:112)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo
des(AbstractParentProcessingNode.java:76)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineN
ode.java:126)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo
des(AbstractParentProcessingNode.java:76)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipeline
sNode.java:95)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(Concret
eTreeProcessor.java:298)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(Concret
eTreeProcessor.java:241)
at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.j
ava:238)
at 
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.ja
va:100)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo
des(AbstractParentProcessingNode.java:54)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(Pr
eparableMatchNode.java:112)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo
des(AbstractParentProcessingNode.java:76)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineN
ode.java:126)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo
des(AbstractParentProcessingNode.java:76)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipeline
sNode.java:95)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(Concret
eTreeProcessor.java:298)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(Concret
eTreeProcessor.java:241)
at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.j
ava:238)
at org.apache.cocoon.Cocoon.process(Cocoon.java:643)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1123)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt
erChain.java:237)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.
java:157)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:2
14)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.ja
va:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at 
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValv
e.java:198)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:1
52)

RE: Status of SVN Conversion?

[Carsten Ziegeler]

Ok, it seems that it works (=compiles), but I think it's not ready to go.

The svn:ignore properties are missing!

Carsten

> -Original Message-
> From: David Crossley [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, July 29, 2004 8:47 AM
> To: Cocoon-Dev
> Subject: Re: Status of SVN Conversion?
> 
> Carsten Ziegeler wrote:
> > Just curious: what's the status of the SVN conversion?
> 
> That is something that we are all wondering.
> 
> I just presumed that is was ready to go and got it like this:
> svn co https://svn.apache.org/repos/asf/cocoon/trunk cocoon
> 
> --
> David Crossley
> 

Design of unmarshaling sitemap component

[ĎURDINA Michal]

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. What I need to involve is conversion from XML to 
Java Object, make the computation in Java and go back with the results to XML in form 
of jxtemplate source.

I have two alternatives of implementation. Both are involving castor for converting 
XML to Java object.

A.) make the XML2Java conversion in transformer
pipeline:

file(modelXML) -> cinclude(aditionaldata) -> castortransformer(modelClass, template) ->

-> jxtemplatetransformer -> jxtemplate (or xsp) source
   |
  modelInstance

This starts with reading modelXML from file, including additional data (i.e. in form 
of another xml document). Populated XML is then the source for Castor unmarshaling, 
the intermediate result is the instance of modelClass placed on request attribute. The 
transformer then emits the template given in second parameter. The modelInstance is 
used in template and jxtemplatetransformer is used to generate required page source 
(jxtemplate again or xsp).

B.) make the XML2Java conversion in action:

pipeline1:
action(cocoon:/pipeline2, modelClass) {
jxtemplategenerator(template) -> jxtemplate (or xsp) source 
 |
   modelInstance
}

pipeline2:
file(modelXML) -> cinclude(aditionaldata) -> XML

This is simmilar to A.) but with the exception that this does not break the SAX stream 
in castortransformer and XML2Java conversion is done between two pipelines. On the 
other hand there is useless serialization and deserialization between both pipelines.

There is question about which approach is better from the design point of view.

Additional questions include:
- in case of A.) is it better to have modelXML on the start of the pipeline and 
template as the parameter or to have template at the start of the pipeline and 
modelXML as the parameter? 
- are there any other viable and simple alternatives?

Thank you for your comments.
Michal

Re: [RT] A Groovy Kind of Sitemap

[Marc Portier]

Marcus Crafter wrote:
On Wed, 2004-07-28 at 14:15, Carsten Ziegeler wrote:
But let not implementation details (or technics) drive the syntax.
It is more important to have a good sitemap language than to have 
a clean and small implementation.

I agree too mate.
Something that I'm wondering about is what the relationship would be
between flowscript and sitemap-script if we allowed the sitemap to be
scriptable.
as it is today: a function-call
what else could we call  ?
My first impression would be that the 2 would merge - the temptation
would be there for our users to write their flowscript around their
sitemap definition (good thing or bad thing?)
the engineer's answer: it depends (as from a famous dilbert cartoon)
or the perl vision: make simple things simple and hard things possible
So if you choose to inline your function-call then in our current view 
we would see that as blasphemy, but for application X it might just be 
the correct thing to do.

The XML syntax prevents keeps flow and sitemaps separate - perhaps its
worth working out the relationship between both concepts?
Very true, but subject to the existential question:
(paraphrazing Stefano in [1])
Is there a real (universally applicable) separation here?
If there is a need to separate (in your situation): you apply it by 
modularizing this new 'site-script' in modules and functions.  If it is 
not, then who are we to impose any way of working?

Rest assured I'm equally concerned with a number of other voices here 
about (using Ugo's wording) 'giving just more rope to hang yourself in'
However, when I see people 'removing and merging' then I can only see 
less rope :-)

IMHO we need to be honest/modest about how far any cocoon-user actually 
wants to be 'guided' and 'helped'.  One of the main explanations I've 
seen in the proclaimed 'tuff learning curve surrounding cocoon' is the 
'atomicity' of it's set of features: catch all or none of it, and thus 
truggle through quite a long period of frutration getting there...

Purely from a didactical POV I would love to be able to
- make a shortcut now and get this lesson over with
- rehash, modularize and add complexity in the next lesson
- and replace one lesson to learn that extra syntax by having more time 
for exercises

I honestly think Ugo is on the right track with his drive for 'simpler'
-marc=
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109103885629692&w=2
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]