You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jason Foster <ja...@uwaterloo.ca> on 2002/06/04 19:57:46 UTC
Sitemap Transformations
What is the feeling on the list regarding having a special pipeline that is
use to transform the sitemap before it is interpreted?
My goal is to allow for customizations to the sitemap without having to
create new components. Here's my use case:
Consider a situation where an image file could exist in one or more of:
- /site/images/
- /site/user/images/
- /site/user/subsite/images/
I'd like to be able to set up a single pipeline that will check these 3
locations in turn, looking for the file. Assuming that a new action called
"FileNotExistsAction" exists, the appropriate way would be:
<map:act type="file-not-exists">
<map:parameter name="filename" value="{0}"/>
<map:parameter name="prefix" value="/site/images/"/>
<map:act type="file-not-exists">
<map:parameter name="filename" value="{../0}"/>
<map:parameter name="prefix" value="/site/user/images/"/>
<map:act type="file-not-exists">
<map:parameter name="filename" value="{../0}"/>
<map:parameter name="prefix" value="/site/user/subsite/images/"/>
<map:read src="missing-image.png"/>
</map:act>
<map:read src="/site/user/subsite/images/{0}"/>
</map:act>
<map:read src="/site/user/images/{0}"/>
</map:act>
<map:read src="/site/images/{0}"/>
Actually, this won't even work. But you get the idea. Anyways, it would
be nice if I could say:
<extension:fallback-reader>
<map:parameter name="filename" value="{0}"/>
<map:parameter name="1" value="/site/user/subsite/images/"/>
<map:parameter name="2" value="/site/user/images/"/>
<map:parameter name="999" value="/site/images/"/>
</extension:fallback-reader>
And then create a stylesheet that would transform my extension into the
nested set of actions, parameters, and readers.
Comments? I could be completely off the mark here, and instead should get
off my duff and write a new reader, but that strikes me as being a
developer-oriented solution where it isn't necessarily appropriate.
Jason Foster
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Sitemap Transformations
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 05.Jun.2002 -- 03:54 PM, daniel robinson wrote:
> I've posted to users but nothing yet.
>
> I want to pass a parameter from the sitemap file to an XSP. In the Sitemap I
> have:
>
> <map:match pattern="index">
> <map:generate type="serverpages" src="xsp/w3/index2.xsp">
> <map:parameter name="SourcePage" value="Index"/> <--- set
> variable here
> </map:generate>
> <map:transform src="stylesheets/w3/index2.xsl"/>
> <map:serialize/>
> </map:match>
>
> and then use it in index2.xsp. I tried this, and lots of other things:
>
> ...snip...
> <esql:execute-query>
> <esql:query>
> select * from "Story"
> where
> "ProjectName" = 'MyProj'
> and
> "PageName" = '"$SourcePage"' <----- use it here
IIRC it should be
"PageName"= <esql:parameter><xsp:expr>parameters.get("SourcePage")</xsp:expr></esql:parameter>
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Sitemap Transformations
Posted by daniel robinson <dr...@dnai.com>.
I've posted to users but nothing yet.
I want to pass a parameter from the sitemap file to an XSP. In the Sitemap I
have:
<map:match pattern="index">
<map:generate type="serverpages" src="xsp/w3/index2.xsp">
<map:parameter name="SourcePage" value="Index"/> <--- set
variable here
</map:generate>
<map:transform src="stylesheets/w3/index2.xsl"/>
<map:serialize/>
</map:match>
and then use it in index2.xsp. I tried this, and lots of other things:
...snip...
<esql:execute-query>
<esql:query>
select * from "Story"
where
"ProjectName" = 'MyProj'
and
"PageName" = '"$SourcePage"' <----- use it here
...snip...
Please help. I've been looking all through the doco - examples etc. When I
try the above I get an exception when Cocoon attempts to recompile the
sitemap.
Thanks,
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Sitemap Transformations
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Jason Foster" <ja...@uwaterloo.ca>
> > I would *strongly* suggest you to write a new reader.
> >
> > I totally understand that tweaking the sitemap sounds 'easier' because
> > the try/fail cycle is *much* faster now, but I tend to believe that
> > until we have the flowmap in place, we should avoid to add anymore
> > dynamism to the sitemap, or people will start to use it and come up with
> > even more things to deprecate or keep to maintain forever.
> >
> > Hope you get my point.
>
> I'll accept the point, but think that soon we're going to have a huge,
> messy, undocumented, proliferation of customized generators, actions, etc.
> For example:
>
> - FileExistsAction
> - FileNotExistsAction
> - PerlStyleFileTestAction
> - GrepAction
> - UnzipAction
> - GetUploadedFilenameAction
> - UploadedFileGenerator
> - UnzipUploadedFileGenerator
> - FallbackFileGenerator
> - FallbackTraxTransformer
> Maybe with Cocoon Blocks, and something like CPAN, this would be
manageable.
> As is stands though, everyone will have to be a Java developer (OK,
> technically you could be an ECMAScript or Python developer) if they want
to
> do things like this. Does this unduly restrict our userbase? I agree
with
> the flexibility syndrome concerns, but there needs to be a happy medium
> between "everyone write a custom generator" and "everyone type volumes
into
> the sitemap manually".
What you proposed to do is not for the faint of the heart, and IMHO won't
get non-programmers to program anyway.
Please share with us all the cases in which something seems to be too clumsy
to do without sitemap generation, so we can understand better what might be
needed.
For example, the first thing that comes to mind for the above Actions, is to
write an AntAction, since Ant already has loads of tasks that do that stuff.
> Sorry to trip your alarm so strongly.
AAAAAAAAAARRRRRRRRRRRRGGGGGGGGHHHHHHHHHHH!!!!!
I have one too ;-P
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Sitemap Transformations
Posted by Stefano Mazzocchi <st...@apache.org>.
Jason Foster wrote:
>
> > I would *strongly* suggest you to write a new reader.
> >
> > I totally understand that tweaking the sitemap sounds 'easier' because
> > the try/fail cycle is *much* faster now, but I tend to believe that
> > until we have the flowmap in place, we should avoid to add anymore
> > dynamism to the sitemap, or people will start to use it and come up with
> > even more things to deprecate or keep to maintain forever.
> >
> > Hope you get my point.
>
> I'll accept the point, but think that soon we're going to have a huge,
> messy, undocumented, proliferation of customized generators, actions, etc.
> For example:
>
> - FileExistsAction
> - FileNotExistsAction
> - PerlStyleFileTestAction
> - GrepAction
> - UnzipAction
> - GetUploadedFilenameAction
> - UploadedFileGenerator
> - UnzipUploadedFileGenerator
> - FallbackFileGenerator
> - FallbackTraxTransformer
>
> Maybe with Cocoon Blocks, and something like CPAN, this would be manageable.
> As is stands though, everyone will have to be a Java developer (OK,
> technically you could be an ECMAScript or Python developer) if they want to
> do things like this. Does this unduly restrict our userbase? I agree with
> the flexibility syndrome concerns, but there needs to be a happy medium
> between "everyone write a custom generator" and "everyone type volumes into
> the sitemap manually".
Jason, believe me I entirely share your concerns. In fact, it's a while
I'm worried about this and one of the reasons why I proposed the flowmap
was that people *love* the sitemap, but it's too declarative by nature.
Just consider one thing: which sitemap component is intrinsically the
least reusable AS-IS?
Actions, no question about it.
I'm pretty sure that if everybody submits their Cocoon-based webapps,
we'll have a tons of actions, some generators, a few transformers and
readers and no serializers.
This rings a bell: people need a better way to describe their precedural
flow and the Cocoon component approach is too heavy for this.
> Sorry to trip your alarm so strongly.
Absolutely no need to apologize, I'm very sensible because this *is* the
biggest design problem that Cocoon faces. You've touched a nerve and a
nerve that is going to be touched more and more in the future as soon as
users get sick and tired of having to write 10 lines of java code into
their actions and fragment thier contracts all over the place.
Recently, I came up with a sitemap what had three custom actions and
reached 12 levels of nesting, 6 matches and 48Kbs in size.
While at the same time I was writing thousands of lines of client-side
javascript with one/third of the effort.
I could smell something burning in the back of my neck.
Degree of reusability of those 'actions': null, zarro, forget it.
There is no problem in lack of intrinsic reusability of parts of
programs, but this is where 'scripting languages' come in and rock the
party.
In fact, both XSLT and the Cocoon Sitemap are markup-based declarative
scripting language. What we need to balance things out from a user
perspective is the abiliy to describe the application flow with the same
ease of use and the same fast try/fail cycle.
We might later decide to compile everything for performance and size
purposes, but for development or for normally-loaded sites, this won't
be necessary with a good internal caching system and a transparent proxy
up front.
So, what's the best solution?
Writing web applications is hard for a simple reason: they are half-way
declarative and half-way procedural. And it's very hard to find a
framework that has a nice balance between these two mindsets.
I would love Cocoon to become one and this is the reason why I proposed
the concept of a "flowmap".
Then Ovidiu came up with the wonderful idea of using continuations to
store the application state transparently, but the key usability issue
is not state control (even if admittedly a great plus) but the ability
to 'script' the flow of your application, making it act as a
programmatic and procedural 'glue' between cocoon components (those with
a high degree of reusability).
NOTE: I'm not stating that flowmaps deprecate actions, no way, but with
a scripted flowmap we have a new design pattern for components:
if you can make your logic reusable write a component
if not, write your logic in the flowmap
I'm going to investigate more on this subject which I consider very
important now and report back.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Sitemap Transformations
Posted by Jason Foster <ja...@uwaterloo.ca>.
> I would *strongly* suggest you to write a new reader.
>
> I totally understand that tweaking the sitemap sounds 'easier' because
> the try/fail cycle is *much* faster now, but I tend to believe that
> until we have the flowmap in place, we should avoid to add anymore
> dynamism to the sitemap, or people will start to use it and come up with
> even more things to deprecate or keep to maintain forever.
>
> Hope you get my point.
I'll accept the point, but think that soon we're going to have a huge,
messy, undocumented, proliferation of customized generators, actions, etc.
For example:
- FileExistsAction
- FileNotExistsAction
- PerlStyleFileTestAction
- GrepAction
- UnzipAction
- GetUploadedFilenameAction
- UploadedFileGenerator
- UnzipUploadedFileGenerator
- FallbackFileGenerator
- FallbackTraxTransformer
Maybe with Cocoon Blocks, and something like CPAN, this would be manageable.
As is stands though, everyone will have to be a Java developer (OK,
technically you could be an ECMAScript or Python developer) if they want to
do things like this. Does this unduly restrict our userbase? I agree with
the flexibility syndrome concerns, but there needs to be a happy medium
between "everyone write a custom generator" and "everyone type volumes into
the sitemap manually".
Sorry to trip your alarm so strongly.
Jason Foster
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Sitemap Transformations
Posted by Stefano Mazzocchi <st...@apache.org>.
Jason Foster wrote:
>
> What is the feeling on the list regarding having a special pipeline that is
> use to transform the sitemap before it is interpreted?
AAHHHHHHHHHHHHHHHHHHAAAAAAHHGGGGGGGGGGGGG!
Sorry, I have a special alarm tuned exactly for that and it went on :)
> My goal is to allow for customizations to the sitemap without having to
> create new components. Here's my use case:
>
> Consider a situation where an image file could exist in one or more of:
> - /site/images/
> - /site/user/images/
> - /site/user/subsite/images/
>
> I'd like to be able to set up a single pipeline that will check these 3
> locations in turn, looking for the file. Assuming that a new action called
> "FileNotExistsAction" exists, the appropriate way would be:
>
> <map:act type="file-not-exists">
> <map:parameter name="filename" value="{0}"/>
> <map:parameter name="prefix" value="/site/images/"/>
> <map:act type="file-not-exists">
> <map:parameter name="filename" value="{../0}"/>
> <map:parameter name="prefix" value="/site/user/images/"/>
> <map:act type="file-not-exists">
> <map:parameter name="filename" value="{../0}"/>
> <map:parameter name="prefix" value="/site/user/subsite/images/"/>
> <map:read src="missing-image.png"/>
> </map:act>
> <map:read src="/site/user/subsite/images/{0}"/>
> </map:act>
> <map:read src="/site/user/images/{0}"/>
> </map:act>
> <map:read src="/site/images/{0}"/>
>
> Actually, this won't even work. But you get the idea. Anyways, it would
> be nice if I could say:
>
> <extension:fallback-reader>
> <map:parameter name="filename" value="{0}"/>
> <map:parameter name="1" value="/site/user/subsite/images/"/>
> <map:parameter name="2" value="/site/user/images/"/>
> <map:parameter name="999" value="/site/images/"/>
> </extension:fallback-reader>
>
> And then create a stylesheet that would transform my extension into the
> nested set of actions, parameters, and readers.
>
> Comments? I could be completely off the mark here, and instead should get
> off my duff and write a new reader, but that strikes me as being a
> developer-oriented solution where it isn't necessarily appropriate.
I would *strongly* suggest you to write a new reader.
I totally understand that tweaking the sitemap sounds 'easier' because
the try/fail cycle is *much* faster now, but I tend to believe that
until we have the flowmap in place, we should avoid to add anymore
dynamism to the sitemap, or people will start to use it and come up with
even more things to deprecate or keep to maintain forever.
Hope you get my point.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Sitemap Transformations
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Jason Foster [mailto:jafoster@uwaterloo.ca]
>
> What is the feeling on the list regarding having a special pipeline
that is
> use to transform the sitemap before it is interpreted?
>
> My goal is to allow for customizations to the sitemap without having
to
> create new components. Here's my use case:
>
> Consider a situation where an image file could exist in one or more
of:
> - /site/images/
> - /site/user/images/
> - /site/user/subsite/images/
>
> I'd like to be able to set up a single pipeline that will check these
3
> locations in turn, looking for the file. Assuming that a new action
called
> "FileNotExistsAction" exists, the appropriate way would be:
>
> <map:act type="file-not-exists">
> <map:parameter name="filename" value="{0}"/>
> <map:parameter name="prefix" value="/site/images/"/>
> <map:act type="file-not-exists">
> <map:parameter name="filename" value="{../0}"/>
> <map:parameter name="prefix" value="/site/user/images/"/>
> <map:act type="file-not-exists">
> <map:parameter name="filename" value="{../0}"/>
> <map:parameter name="prefix"
value="/site/user/subsite/images/"/>
> <map:read src="missing-image.png"/>
> </map:act>
> <map:read src="/site/user/subsite/images/{0}"/>
> </map:act>
> <map:read src="/site/user/images/{0}"/>
> </map:act>
> <map:read src="/site/images/{0}"/>
>
> Actually, this won't even work. But you get the idea. Anyways, it
would
> be nice if I could say:
>
> <extension:fallback-reader>
> <map:parameter name="filename" value="{0}"/>
> <map:parameter name="1" value="/site/user/subsite/images/"/>
> <map:parameter name="2" value="/site/user/images/"/>
> <map:parameter name="999" value="/site/images/"/>
> </extension:fallback-reader>
>
> And then create a stylesheet that would transform my extension into
the
> nested set of actions, parameters, and readers.
>
> Comments? I could be completely off the mark here, and instead should
get
> off my duff and write a new reader, but that strikes me as being a
> developer-oriented solution where it isn't necessarily appropriate.
I won't comment on how it should be done... But here is good or bad news
for you: sitemap-sheets (like logicsheet for XSP) are possible in 2.0.3;
and won't be supported in 2.1 anymore.
Vadim
> Jason Foster
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org