You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by David Crossley <cr...@indexgeo.com.au> on 2002/05/03 12:12:47 UTC
Docs: next steps scratchpad and new mailing list
To keep the documentation drive moving, there are a couple
of obvious next steps.
A) Establish a new area under scratchpad for the Draft
documentation, probably at src/scratchpad/documentation/
I will start to investigate that, though i will certainly need help
with Cocoon's Ant build.xml files ... wow, they are complex.
B) Set up the new mail list cocoon-docs (or is it cocoon-doc).
I do not know how to go about that. However, i can see a
couple of issues already ...
- The list needs a moderator. I recently read from "apmail"
that all apache lists need moderation for first-time postings,
so as to eliminate spam opportunities. Or the list be set up
to automatically reject postings from those not subscribed.
Or a combination of both. We need to minimise the work here.
- We should keep the list a little covert until we have set up
some procedures and guidelines, and we have the scratchpad
ready. Then we can use the announcement opportunity later
for more benefit.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Sitemap parameters failing...
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Per Kreipke [mailto:per@onclave.com]
>
> > sitemap.xsl was removed from CVS HEAD (Cocoon 2.1) that's why you
had
> > trouble locating it.
>
> Ok. Just as I've understood it :-) Is the sitemap still used but its
code
> generated some other way in 2.1?
Sitemap is interpreted in the 2.1.
Vadim
> > You can try latest Cocoon from cocoon_2_0_3_branch, which should
work ok
> > for you.
>
> Will do, thanks.
>
> Per
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Sitemap parameters failing...
Posted by Per Kreipke <pe...@onclave.com>.
> sitemap.xsl was removed from CVS HEAD (Cocoon 2.1) that's why you had
> trouble locating it.
Ok. Just as I've understood it :-) Is the sitemap still used but its code
generated some other way in 2.1?
> You can try latest Cocoon from cocoon_2_0_3_branch, which should work ok
> for you.
Will do, thanks.
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Sitemap parameters failing...
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Per Kreipke [mailto:per@onclave.com]
>
> Vadim,
>
> > > - I'm using C2 (RC1 I think) and this bug still exists in the
current
> > code
> > > when I look at the CVS code.
>
> > Can't reproduce. Are you sure that you are using latest (2.0.3
branch
> > CVS) sitemap.xsl?
>
> No, I'm definitely not. I meant by the line above that I compared the
> portion of the sitemap.xsl I'm using (2.0.2) with the version in CVS
to see
> if the ordering was similar and I thought it was. However, I must
admit that
> there was something strange about browsing CVS using the web interface
to
> that particular file (sitemap.xsl), I recall having to try through a
bunch
> of the targets to get any view of it at all.
>
> Clearly, it's my responsibility to see if I can prove that the bug
still
> exists under the latest code. I'll attempt somehow to do that without
> updating my install to the latest CVS version [not sure we're ready
for it
> :-)]
sitemap.xsl was removed from CVS HEAD (Cocoon 2.1) that's why you had
trouble locating it.
You can try latest Cocoon from cocoon_2_0_3_branch, which should work ok
for you.
Vadim
>
> Per
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Sitemap parameters failing...
Posted by Per Kreipke <pe...@onclave.com>.
Vadim,
> > - I'm using C2 (RC1 I think) and this bug still exists in the current
> code
> > when I look at the CVS code.
> Can't reproduce. Are you sure that you are using latest (2.0.3 branch
> CVS) sitemap.xsl?
No, I'm definitely not. I meant by the line above that I compared the
portion of the sitemap.xsl I'm using (2.0.2) with the version in CVS to see
if the ordering was similar and I thought it was. However, I must admit that
there was something strange about browsing CVS using the web interface to
that particular file (sitemap.xsl), I recall having to try through a bunch
of the targets to get any view of it at all.
Clearly, it's my responsibility to see if I can prove that the bug still
exists under the latest code. I'll attempt somehow to do that without
updating my install to the latest CVS version [not sure we're ready for it
:-)]
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Sitemap parameters failing...
Posted by Vadim Gritsenko <va...@verizon.net>.
Can't reproduce. Are you sure that you are using latest (2.0.3 branch
CVS) sitemap.xsl?
Vadim
--
Resistance is futile.
> -----Original Message-----
> From: Per Kreipke [mailto:per@onclave.com]
> Sent: Friday, May 31, 2002 12:08 PM
> To: cocoon-dev@xml.apache.org
> Subject: Sitemap parameters failing...
>
> In the following test sitemap fragment, I thought I was doing
something
> wrong because I couldn't get the sitemap to compile:
>
> <map:match patter="client.xml">
> <map:parameter name="client" value="magnet" />
>
> <map:generate src="config/{client}.xml" />
> <map:serialize type="xml" />
> </map:match>
>
>
> When I look at the sitemap.xsl code I think I see why: the generated
java
> fragment below is wrong, param is initialized outside the function
> definition for the matcher.
>
> param = new Parameters();
> param.setParameter("client", "magnet");
>
> private final boolean matchN10002D(.....) throws ...
> {
> ...
> Parameters param;
> ...
>
> }
>
> Notes:
>
> - this is not an issue for the other instances where map:parameter is
used
> (e.g. in map:act, map:select, etc) because those are called from
within the
> function generated by "map:match".
>
> - I think the same bug exists in both XSL templates for "map:match"
and
> "map:match//map:match".
>
> - I'm using C2 (RC1 I think) and this bug still exists in the current
code
> when I look at the CVS code.
>
>
> Per
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Nested map:parameter sets...
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Per Kreipke [mailto:per@onclave.com]
>
> I'm new at C2 but it seems to me from looking at sitemap.xsl that the
> following (valid) sitemap snippet would result in some unintended
code:
>
> <map:match patter="client.xml">
> <map:parameter name="client" value="magnet" />
>
> <map:generate src="config/{client}.xml">
> <map:parameter name="affiliate" value="onclave" />
> </map:generate>
> <map:transform src="config/output.xsl">
> <map:parameter name="title" value="foo" />
> </map:transform>
> <map:serialize type="xml" />
> </map:match>
>
> Every map:parameter generates a section of code that begins with:
>
> param = new Parameters();
>
> which would override outer parameter declarations.
This is intended behavior. Parameter declared in the element (match,
act, select, etc) is available only to this element, passed in the
setup() call, and not to nested elements.
> This would definitely happen in the specific XSL template
> "map:match//map:match" since there's no nested 'Parameters param'
> declaration.
>
> Here's where I show my ignorance: shouldn't in fact the parameters be
a
> stack? I know that the MapResolver gets involved so maybe the
implementation
> already is a stack.
That's why it should not be a stack.
Vadim
> Per Kreipke
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Nested map:parameter sets...
Posted by Per Kreipke <pe...@onclave.com>.
I'm new at C2 but it seems to me from looking at sitemap.xsl that the
following (valid) sitemap snippet would result in some unintended code:
<map:match patter="client.xml">
<map:parameter name="client" value="magnet" />
<map:generate src="config/{client}.xml">
<map:parameter name="affiliate" value="onclave" />
</map:generate>
<map:transform src="config/output.xsl">
<map:parameter name="title" value="foo" />
</map:transform>
<map:serialize type="xml" />
</map:match>
Every map:parameter generates a section of code that begins with:
param = new Parameters();
which would override outer parameter declarations.
This would definitely happen in the specific XSL template
"map:match//map:match" since there's no nested 'Parameters param'
declaration.
Here's where I show my ignorance: shouldn't in fact the parameters be a
stack? I know that the MapResolver gets involved so maybe the implementation
already is a stack.
Per Kreipke
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Sitemap parameters failing...
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Per Kreipke [mailto:per@onclave.com]
>
> Vadim,
>
> Did I get this wrong too? Just trying to correct my understanding.
No, looks like you are right and found an error... Will have to take a
look at it. Later. :)
Vadim
>
> Per
>
> > -----Original Message-----
> > From: Per Kreipke [mailto:per@onclave.com]
> > Sent: Friday, May 31, 2002 12:08 PM
> > To: cocoon-dev@xml.apache.org
> > Subject: Sitemap parameters failing...
> >
> >
> > In the following test sitemap fragment, I thought I was doing
something
> > wrong because I couldn't get the sitemap to compile:
> >
> > <map:match patter="client.xml">
> > <map:parameter name="client" value="magnet" />
> >
> > <map:generate src="config/{client}.xml" />
> > <map:serialize type="xml" />
> > </map:match>
> >
> >
> > When I look at the sitemap.xsl code I think I see why: the generated
java
> > fragment below is wrong, param is initialized outside the function
> > definition for the matcher.
> >
> > param = new Parameters();
> > param.setParameter("client", "magnet");
> >
> > private final boolean matchN10002D(.....) throws ...
> > {
> > ...
> > Parameters param;
> > ...
> >
> > }
> >
> > Notes:
> >
> > - this is not an issue for the other instances where map:parameter
is used
> > (e.g. in map:act, map:select, etc) because those are called from
> > within the
> > function generated by "map:match".
> >
> > - I think the same bug exists in both XSL templates for "map:match"
and
> > "map:match//map:match".
> >
> > - I'm using C2 (RC1 I think) and this bug still exists in the
current code
> > when I look at the CVS code.
> >
> >
> > Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Sitemap parameters failing...
Posted by Per Kreipke <pe...@onclave.com>.
Vadim,
Did I get this wrong too? Just trying to correct my understanding.
Per
> -----Original Message-----
> From: Per Kreipke [mailto:per@onclave.com]
> Sent: Friday, May 31, 2002 12:08 PM
> To: cocoon-dev@xml.apache.org
> Subject: Sitemap parameters failing...
>
>
> In the following test sitemap fragment, I thought I was doing something
> wrong because I couldn't get the sitemap to compile:
>
> <map:match patter="client.xml">
> <map:parameter name="client" value="magnet" />
>
> <map:generate src="config/{client}.xml" />
> <map:serialize type="xml" />
> </map:match>
>
>
> When I look at the sitemap.xsl code I think I see why: the generated java
> fragment below is wrong, param is initialized outside the function
> definition for the matcher.
>
> param = new Parameters();
> param.setParameter("client", "magnet");
>
> private final boolean matchN10002D(.....) throws ...
> {
> ...
> Parameters param;
> ...
>
> }
>
> Notes:
>
> - this is not an issue for the other instances where map:parameter is used
> (e.g. in map:act, map:select, etc) because those are called from
> within the
> function generated by "map:match".
>
> - I think the same bug exists in both XSL templates for "map:match" and
> "map:match//map:match".
>
> - I'm using C2 (RC1 I think) and this bug still exists in the current code
> when I look at the CVS code.
>
>
> Per
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Sitemap parameters failing...
Posted by Per Kreipke <pe...@onclave.com>.
In the following test sitemap fragment, I thought I was doing something
wrong because I couldn't get the sitemap to compile:
<map:match patter="client.xml">
<map:parameter name="client" value="magnet" />
<map:generate src="config/{client}.xml" />
<map:serialize type="xml" />
</map:match>
When I look at the sitemap.xsl code I think I see why: the generated java
fragment below is wrong, param is initialized outside the function
definition for the matcher.
param = new Parameters();
param.setParameter("client", "magnet");
private final boolean matchN10002D(.....) throws ...
{
...
Parameters param;
...
}
Notes:
- this is not an issue for the other instances where map:parameter is used
(e.g. in map:act, map:select, etc) because those are called from within the
function generated by "map:match".
- I think the same bug exists in both XSL templates for "map:match" and
"map:match//map:match".
- I'm using C2 (RC1 I think) and this bug still exists in the current code
when I look at the CVS code.
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Docs: next steps scratchpad and new mailing list
Posted by David Crossley <cr...@indexgeo.com.au>.
Diana Shannon wrote:
> David Crossley wrote:
> > To keep the documentation drive moving, there are a couple
> > of obvious next steps.
>
> It's moving ...
It sure is moving. Poor choice of words on my part. I meant to
say that there were a couple of fundamental things that needed
to be discussed and planned. When we are sure how we want
to do these things then we can call for a vote for implementation.
We use [VOTE] in the subject line, otherwise it is just discussion.
> ... I'm just sparing cocoon-dev the noisy details.
Looking forward to hearing your fine-tuned summaries.
> > A) Establish a new area under scratchpad for the Draft
> > documentation, probably at src/scratchpad/documentation/
> > I will start to investigate that, though i will certainly need help
> > with Cocoon's Ant build.xml files ... wow, they are complex.
>
> I've been thinking about it too. Perhaps we should talk off-list.
Actually, i think that on-list is the only way. Thousands of minds
in concert is better. Splinter groups do not work well, because
sooner or later someone forgets to Cc someone and it breaks.
They also unintentionally exclude some who could help.
Rather, well-chosen email subject lines with concise focus
does the trick ... others can choose to skim/skip whole threads.
> > B) Set up the new mail list cocoon-docs (or is it cocoon-doc).
> > I do not know how to go about that. However, i can see a
> > couple of issues already ...
>
> Can we wait just a second on this? How about deciding next week? I'm
> trying to contact people involved in existing document projects for
> hints about starting out. A lot of doc projects die, particularly
> list-based projects, and I just want to make *very sure* we're not
> jumping the gun by migrating this very nascent effort off cocoon-dev
> just yet.
Good idea Diana to wait and explore other projects. I am with you,
let us tread carefully. I was alerting so as to pre-empt some issues.
I have seen other lists start too quickly and not fully prepared.
They attract spam from day one, because of a simple mis-config
and are then doomed. I was trying to help build a list of issues.
> > - The list needs a moderator. I recently read from "apmail"
> > that all apache lists need moderation for first-time postings,
> > so as to eliminate spam opportunities. Or the list be set up
> > to automatically reject postings from those not subscribed.
> > Or a combination of both. We need to minimise the work here.
> >
> > - We should keep the list a little covert until we have set up
> > some procedures and guidelines, and we have the scratchpad
> > ready. Then we can use the announcement opportunity later
> > for more benefit.
>
> Yes, and it makes *no* sense to announce it until guidelines for
> contributors are in place. I should have these ready soon, but I'm just
> trying to be deliberate about it. Sorry. I have a *really* hard time
> throwing up drafts expecting someone else to finish it for me.
However, here is one opensource mantra ...
Do not try to finish it yourself. Make a start, any start, get it out
to the open air, let everyone help, keep going at your own pace
even if no-one helps, commit to cvs often, someone will build it
to fruition even if you go away.
We appreciate your deliberateness. It will provide a better base
for discussion. Another mantra: do it any way you want.
Anyway, i certainly do not want to rush you.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Docs: next steps scratchpad and new mailing list
Posted by Diana Shannon <te...@mac.com>.
On May 3, 2002, David Crossley wrote:
> To keep the documentation drive moving, there are a couple
> of obvious next steps.
It's moving. I'm just sparing cocoon-dev the noisy details.
> A) Establish a new area under scratchpad for the Draft
> documentation, probably at src/scratchpad/documentation/
> I will start to investigate that, though i will certainly need help
> with Cocoon's Ant build.xml files ... wow, they are complex.
I've been thinking about it too. Perhaps we should talk off-list.
> B) Set up the new mail list cocoon-docs (or is it cocoon-doc).
> I do not know how to go about that. However, i can see a
> couple of issues already ...
Can we wait just a second on this? How about deciding next week? I'm
trying to contact people involved in existing document projects for
hints about starting out. A lot of doc projects die, particularly
list-based projects, and I just want to make *very sure* we're not
jumping the gun by migrating this very nascent effort off cocoon-dev
just yet.
> - The list needs a moderator. I recently read from "apmail"
> that all apache lists need moderation for first-time postings,
> so as to eliminate spam opportunities. Or the list be set up
> to automatically reject postings from those not subscribed.
> Or a combination of both. We need to minimise the work here.
>
> - We should keep the list a little covert until we have set up
> some procedures and guidelines, and we have the scratchpad
> ready. Then we can use the announcement opportunity later
> for more benefit.
Yes, and it makes *no* sense to announce it until guidelines for
contributors are in place. I should have these ready soon, but I'm just
trying to be deliberate about it. Sorry. I have a *really* hard time
throwing up drafts expecting someone else to finish it for me.
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Docs: next steps scratchpad and new mailing list
Posted by Diana Shannon <te...@mac.com>.
On May 3, 2002, David Crossley wrote:
> A) Establish a new area under scratchpad for the Draft
> documentation, probably at src/scratchpad/documentation/
As per my earlier post on file naming conventions, I think we need a
similar setup:
src/scratchpad/documentation/xdocs/faqs/XXXXXX.xml
src/scratchpad/documentation/xdocs/howtos/XXXXXX.xml (or XXXXX
directories for multi-page docs)
src/scratchpad/documentation/xdocs/tutorials/XXXXXX.xml (or XXXXX
directories for multi-page docs)
src/scratchpad/documentation/xdocs/examples/XXXXXX.xml (or XXXXX
directories for multi-page docs)
src/scratchpad/documentation/xdocs/guides/XXXXXX.xml (or XXXXX
directories for multi-page docs)
The examples section is intended to include community contributions of
static and dynamic code snippets. I think Cocoon's current dynamic
examples need static overview pages with links as appropriate to the
dynamic pages which illustrate functionality. The page layout of the
example overview should be follow the documentation skin used by other
docs. I think any build should be able to distinguish static
documentation from dynamic (examples). In other words, dynamic example
pages shouldn't be integrated into the static build.
> I will start to investigate that, though i will certainly need help
> with Cocoon's Ant build.xml files ... wow, they are complex.
We need to make it easy for QA people, some of whom are probably going
to be somewhat conservative (and newbie) users. I'm not sure builds are
right for everyone, especially those who don't (yet) keep up with the
head branch. Do we have *any* meaningful statistics as to how many
people download binaries vs. source files? Do we know if users actually
build their versions or simply download the latest binaries?
Some preliminary thoughts:
- a downloadable minimal WAR just for scratchpad (and existing)
documentation work, based on release features, not head. This could be a
variation of the MyApp project Konstantin is developing.
- downloadable files containing scratchpad docs which users drop into a
documentation directory of sorts
- a separate cvs branch, just for docs
I'm not suggesting we don't need builds for this. I just think we need a
few more options to meet the future needs of all contributors.
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org