You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jorg Heymans <jh...@domek.be> on 2004/02/04 15:11:05 UTC
variable substitution in @type attributes
Carrying the discussion over from users@
Why is variable substituion not allowed in @type attributes ?
(or: is there a better way to translate below pseudo-syntax into real
syntax?)
>>
>> Imagine Tuomo's usecase a bit more extended
>>
>> <map:match pattern="*.*">
>> <map:generate src="{1}.{2}"/>
>> <map:transform type="{2}"/>
>> <map:serialize type="{2}"/>
>> </map:match>
>>
>> Using the old syntax this becomes
>>
>> <map:match pattern="*.*">
>> <map:select type="parameter">
>> <map:parameter name="parameter-selector-test" value="{2}"/>
>> <!-- for each possible file extension you need to have this block -->
>> <map:when test="svg">
>> <map:generate src="{1}.{2}"/>
>> <map:transform type="svg"/>
>> <map:serialize type="svg"/>
>> </map:when>
>> <map:when test="video">
>> <map:generate src="{1}.{2}"/>
>> <map:transform type="video"/>
>> <map:serialize type="video"/>
>> </map:when>
>> ......
>> </map:select>
>> </map:match>
>>
Re: variable substitution in @type attributes
Posted by Jorg Heymans <jh...@domek.be>.
>
> I'm curious to know how it could be useful compared to how it'll make the
> sitemap unreadable?
<map:match pattern="*.*">
<map:generate src="{1}.{2}"/>
<map:transform type="{2}"/>
<map:serialize type="{2}"/>
</map:match>
is less readable because you don't know which component is executed in
advance. From the sitemap you can't read how the pipeline is built, it
depends on what is passed in.
Ofcourse something like
<map:match pattern="*.[gif,jpeg,svg,video]">
could make us a bit more happy here. But i guess you couldn't enforce
this syntax only if dynamic type attributes are in play- it would have
to be on or off the whole time.
>
> Nicolas
> Le Mercredi 04 Février 2004 16:18, Jorg Heymans a écrit :
>
>>Carsten Ziegeler wrote:
>>
>>>I think one major point is security or more precise: to detect possible
>>>problems
>>>early on. If you now use a wrong type information, which means address a
>>>component that doesn't exist, you get an exception immediately on
>>>startup. So, you know very early that your application is not correct.
>>>
>>>With a dynamic type attribute you defer this to a much later point which
>>>might
>>>be dangerous as well and very hard to find.
>>
>>true. But how is this different from having a custom component that
>>throws an uncaught exception? It just gets passed to the errorhandler
>>and we deal with it there. Or what when your <map:generate
>>src="{1}.{2}"/> points to a non existing file? That's also a normal
>>error situation we are all familiar with.
>>
>>If pipeline setup happens after the pipeline match then searching
>>components and filling in the "blanks" could be part of this setup
>>(theoretically - i know). Ideally a component-not-found exception here
>>is also caught by the error handler.
>>
>>
>>Just thinking out loud, sorry if i'm oversimplifying.
>>Jorg
>
>
>
Re: variable substitution in @type attributes
Posted by Nicolas Toper <nt...@jouve.fr>.
Could you give a use case of this functionnality?
I'm curious to know how it could be useful compared to how it'll make the
sitemap unreadable?
Nicolas
Le Mercredi 04 Février 2004 16:18, Jorg Heymans a écrit :
> Carsten Ziegeler wrote:
> > I think one major point is security or more precise: to detect possible
> > problems
> > early on. If you now use a wrong type information, which means address a
> > component that doesn't exist, you get an exception immediately on
> > startup. So, you know very early that your application is not correct.
> >
> > With a dynamic type attribute you defer this to a much later point which
> > might
> > be dangerous as well and very hard to find.
>
> true. But how is this different from having a custom component that
> throws an uncaught exception? It just gets passed to the errorhandler
> and we deal with it there. Or what when your <map:generate
> src="{1}.{2}"/> points to a non existing file? That's also a normal
> error situation we are all familiar with.
>
> If pipeline setup happens after the pipeline match then searching
> components and filling in the "blanks" could be part of this setup
> (theoretically - i know). Ideally a component-not-found exception here
> is also caught by the error handler.
>
>
> Just thinking out loud, sorry if i'm oversimplifying.
> Jorg
Re: variable substitution in @type attributes
Posted by Jorg Heymans <jh...@domek.be>.
Carsten Ziegeler wrote:
> I think one major point is security or more precise: to detect possible
> problems
> early on. If you now use a wrong type information, which means address a
> component that doesn't exist, you get an exception immediately on startup.
> So, you know very early that your application is not correct.
>
> With a dynamic type attribute you defer this to a much later point which
> might
> be dangerous as well and very hard to find.
true. But how is this different from having a custom component that
throws an uncaught exception? It just gets passed to the errorhandler
and we deal with it there. Or what when your <map:generate
src="{1}.{2}"/> points to a non existing file? That's also a normal
error situation we are all familiar with.
If pipeline setup happens after the pipeline match then searching
components and filling in the "blanks" could be part of this setup
(theoretically - i know). Ideally a component-not-found exception here
is also caught by the error handler.
Just thinking out loud, sorry if i'm oversimplifying.
Jorg
Re: variable substitution in @type attributes
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jorg Heymans wrote:
> Vadim, that post is from 2001.
Well, it shows how solid our contracts are :-)
> The arguments are:
> - it affects the cache ->is this still relevant for the rewritten
> cache mechanism in 2.1+ ?
Not relevant, I'd think.
> - Flexibility syndrome ->point taken
> - It's a reactor pattern forcing distribution of control and
> increasing the number of contracts between the different contexts.
> ->not sure what is meant there. Does he mean that selecting a
> component during pipeline setup would not be the sole decision of the
> sitemap anymore? Which contexts are meant here?
You can educate on reactor pattern here:
http://cocoon.apache.org/1.x/guide.html
Vadim
RE: variable substitution in @type attributes
Posted by Reinhard Poetz <re...@apache.org>.
From: Nicolas Toper [mailto:ntoper@jouve.fr]
> True, this is a big security hole...
>
> Well, for the exception, where is the difference btw calling
> a non existant
> component and calling a non existant resource (like a file)??
>
> But it seems hard use... At the same time, this'd be cool for
> readers (like
> gif, jpeg,etc..)
Cool yes, but IMO too much magic. I would be -1 on changing this. With
explicit namings the sitemap remains easily readable.
--
Reinhard
>
> What do you think?
>
> Le Mercredi 04 Février 2004 15:58, Carsten Ziegeler a écrit :
> > I think one major point is security or more precise: to detect
> > possible problems early on. If you now use a wrong type
> information,
> > which means address a component that doesn't exist, you get an
> > exception immediately on startup. So, you know very early that your
> > application is not correct.
> >
> > With a dynamic type attribute you defer this to a much later point
> > which might be dangerous as well and very hard to find.
> >
> > Carsten
> >
> > > -----Original Message-----
> > > From: news [mailto:news@sea.gmane.org]On Behalf Of Jorg Heymans
> > > Sent: Wednesday, February 04, 2004 3:51 PM
> > > To: dev@cocoon.apache.org
> > > Subject: Re: variable substitution in @type attributes
> > >
> > >
> > > Vadim, that post is from 2001.
> > >
> > > The arguments are:
> > > - it affects the cache ->is this still relevant for the rewritten
> > > cache mechanism in 2.1+ ?
> > > - Flexibility syndrome ->point taken
> > > - It's a reactor pattern forcing distribution of control and
> > > increasing the number of contracts between the different
> contexts.
> > > ->not sure what is meant there. Does he mean that selecting a
> > > component during pipeline setup would not be the sole decision of
> > > the sitemap anymore? Which contexts are meant here?
> > >
> > > I can understand the pipeline overhead in looking through
> the list
> > > of all components everytime for one that matches the
> parameter, but
> > > this could be documented and left to the user to decide what he
> > > prefers most.
> > >
> > >
> > > Please note that I am not trying to advocate this change, just
> > > looking to up my knowledge on cocoon another nudge.
> > >
> > > thanks
> > > Jorg
> > >
> > > Vadim Gritsenko wrote:
> > > > Jorg Heymans wrote:
> > > >> Carrying the discussion over from users@
> > > >> Why is variable substituion not allowed in @type attributes ?
> > > >
> > > > Archives have it.
> > > >
> > > >
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=9886706782656
5&w=
> > > 2
> > >
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98867067826565&w=2
> > >
> > > Vadim
Re: variable substitution in @type attributes
Posted by Nicolas Toper <nt...@jouve.fr>.
True, this is a big security hole...
Well, for the exception, where is the difference btw calling a non existant
component and calling a non existant resource (like a file)??
But it seems hard use... At the same time, this'd be cool for readers (like
gif, jpeg,etc..)
What do you think?
Le Mercredi 04 Février 2004 15:58, Carsten Ziegeler a écrit :
> I think one major point is security or more precise: to detect possible
> problems
> early on. If you now use a wrong type information, which means address a
> component that doesn't exist, you get an exception immediately on startup.
> So, you know very early that your application is not correct.
>
> With a dynamic type attribute you defer this to a much later point which
> might
> be dangerous as well and very hard to find.
>
> Carsten
>
> > -----Original Message-----
> > From: news [mailto:news@sea.gmane.org]On Behalf Of Jorg Heymans
> > Sent: Wednesday, February 04, 2004 3:51 PM
> > To: dev@cocoon.apache.org
> > Subject: Re: variable substitution in @type attributes
> >
> >
> > Vadim, that post is from 2001.
> >
> > The arguments are:
> > - it affects the cache ->is this still relevant for the rewritten cache
> > mechanism in 2.1+ ?
> > - Flexibility syndrome ->point taken
> > - It's a reactor pattern forcing distribution of control and increasing
> > the number of contracts between the different contexts. ->not sure what
> > is meant there. Does he mean that selecting a component during pipeline
> > setup would not be the sole decision of the sitemap anymore? Which
> > contexts are meant here?
> >
> > I can understand the pipeline overhead in looking through the list of
> > all components everytime for one that matches the parameter, but this
> > could be documented and left to the user to decide what he prefers most.
> >
> >
> > Please note that I am not trying to advocate this change, just looking
> > to up my knowledge on cocoon another nudge.
> >
> > thanks
> > Jorg
> >
> > Vadim Gritsenko wrote:
> > > Jorg Heymans wrote:
> > >> Carrying the discussion over from users@
> > >> Why is variable substituion not allowed in @type attributes ?
> > >
> > > Archives have it.
> > >
> > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98867067826565&w=2
> > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98867067826565&w=2
> > >
> > > Vadim
[OT] Re: variable substitution in @type attributes
Posted by Nicolas Toper <nt...@jouve.fr>.
Well with PHP you could do a lot of awful things and since it's dynamically
typed it's easier to write BIG STUPID things...
for instance you could something like that:
for every parameter in the POST
do action with it
end for
That's something a framework like Cocoon is good at: diffuse good practices
and avoid usual mistakes :=)
Le Mercredi 04 Février 2004 17:30, Sylvain Wallez a écrit :
> Nicolas Toper wrote:
> >Yes that's how you can hack a lot of PHP servers (yes I was young ;=))
>
> Yep it's way easier in PHP (the infamous include injection in PHPNuke)!
>
> >Le Mercredi 04 Février 2004 17:11, Sylvain Wallez a écrit :
> >>Jorg Heymans wrote:
> >>>>Moreover, the use case shows a component type coming directly for the
> >>>>request URI, which is a giant door open to "component injection" by
> >>>>providing a value for the type that is not in the expected values and
> >>>>executes arbitrary code on the server.
> >>>
> >>>Wooo hold on here, what you just described sounds a bit like a buffer
> >>>overflow type of exploit, a bit of overkill i think.
> >>>
> >>>Granted, if i can
> >>>1) upload my component
> >>>2) reload/restart the servlet container
> >>>3) get my components initialize() to run
> >>>
> >>>then i'm in business. But how feasible is this? Worst case would be if
> >>>the user configured fileuploads to go to web-inf/lib or
> >>>web-inf/classes but then you're in trouble anyway because i'll upload
> >>>my custom servlet class that overwrites the cocoon servlet.
> >>>
> >>>Understanding your concerns, but needing a higher than extremely
> >>>unlikely and isolated usecase,
> >>
> >>That's not unlikely and doesn't require uploading classes. Consider the
> >>following:
> >><map:match pattern="*-*.html">
> >> <map:generate src="repository/{1}.xml" type="file"/>
> >> <map:transform type="{2}"/>
> >> <map:serialize type="html"/>
> >></map:match>
> >>
> >>Now suppose we're in a CMS and that the user can upload the initial xml
> >>file. What if {2}, which is expected to be "foo" or "bar" is set to
> >>"jxtemplate"? The uploaded file iss interpreted and can then execute
> >>arbitrary code on the server!
> >>
> >>Does this sound so unlikely?
> >>
> >>Sylvain
Re: variable substitution in @type attributes
Posted by Sylvain Wallez <sy...@apache.org>.
Nicolas Toper wrote:
>Yes that's how you can hack a lot of PHP servers (yes I was young ;=))
>
>
Yep it's way easier in PHP (the infamous include injection in PHPNuke)!
>Le Mercredi 04 Février 2004 17:11, Sylvain Wallez a écrit :
>
>
>>Jorg Heymans wrote:
>>
>>
>>>>Moreover, the use case shows a component type coming directly for the
>>>>request URI, which is a giant door open to "component injection" by
>>>>providing a value for the type that is not in the expected values and
>>>>executes arbitrary code on the server.
>>>>
>>>>
>>>Wooo hold on here, what you just described sounds a bit like a buffer
>>>overflow type of exploit, a bit of overkill i think.
>>>
>>>Granted, if i can
>>>1) upload my component
>>>2) reload/restart the servlet container
>>>3) get my components initialize() to run
>>>
>>>then i'm in business. But how feasible is this? Worst case would be if
>>>the user configured fileuploads to go to web-inf/lib or
>>>web-inf/classes but then you're in trouble anyway because i'll upload
>>>my custom servlet class that overwrites the cocoon servlet.
>>>
>>>Understanding your concerns, but needing a higher than extremely
>>>unlikely and isolated usecase,
>>>
>>>
>>That's not unlikely and doesn't require uploading classes. Consider the
>>following:
>><map:match pattern="*-*.html">
>> <map:generate src="repository/{1}.xml" type="file"/>
>> <map:transform type="{2}"/>
>> <map:serialize type="html"/>
>></map:match>
>>
>>Now suppose we're in a CMS and that the user can upload the initial xml
>>file. What if {2}, which is expected to be "foo" or "bar" is set to
>>"jxtemplate"? The uploaded file iss interpreted and can then execute
>>arbitrary code on the server!
>>
>>Does this sound so unlikely?
>>
>>Sylvain
>>
>>
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: variable substitution in @type attributes
Posted by Nicolas Toper <nt...@jouve.fr>.
Yes that's how you can hack a lot of PHP servers (yes I was young ;=))
Le Mercredi 04 Février 2004 17:11, Sylvain Wallez a écrit :
> Jorg Heymans wrote:
> >> Moreover, the use case shows a component type coming directly for the
> >> request URI, which is a giant door open to "component injection" by
> >> providing a value for the type that is not in the expected values and
> >> executes arbitrary code on the server.
> >
> > Wooo hold on here, what you just described sounds a bit like a buffer
> > overflow type of exploit, a bit of overkill i think.
> >
> > Granted, if i can
> > 1) upload my component
> > 2) reload/restart the servlet container
> > 3) get my components initialize() to run
> >
> > then i'm in business. But how feasible is this? Worst case would be if
> > the user configured fileuploads to go to web-inf/lib or
> > web-inf/classes but then you're in trouble anyway because i'll upload
> > my custom servlet class that overwrites the cocoon servlet.
> >
> > Understanding your concerns, but needing a higher than extremely
> > unlikely and isolated usecase,
>
> That's not unlikely and doesn't require uploading classes. Consider the
> following:
> <map:match pattern="*-*.html">
> <map:generate src="repository/{1}.xml" type="file"/>
> <map:transform type="{2}"/>
> <map:serialize type="html"/>
> </map:match>
>
> Now suppose we're in a CMS and that the user can upload the initial xml
> file. What if {2}, which is expected to be "foo" or "bar" is set to
> "jxtemplate"? The uploaded file iss interpreted and can then execute
> arbitrary code on the server!
>
> Does this sound so unlikely?
>
> Sylvain
Re: variable substitution in @type attributes
Posted by Jorg Heymans <jh...@domek.be>.
>
>
> That's not unlikely and doesn't require uploading classes. Consider the
> following:
> <map:match pattern="*-*.html">
> <map:generate src="repository/{1}.xml" type="file"/>
> <map:transform type="{2}"/>
> <map:serialize type="html"/>
> </map:match>
>
> Now suppose we're in a CMS and that the user can upload the initial xml
> file. What if {2}, which is expected to be "foo" or "bar" is set to
> "jxtemplate"? The uploaded file iss interpreted and can then execute
> arbitrary code on the server!
>
> Does this sound so unlikely?
>
Not at all, thanks for rubbing my nose in it :)
Your example would be unsafe anyway if the transformer is configured to
jxtemplate and the upload-directory to repository, but i guess then the
user is to blame and not the framework.
Tainting uploaded files or parameters like perl does could partially
prevent this but it would never be foolproof.
I'll rest my case.
> Sylvain
Jorg
Re: variable substitution in @type attributes
Posted by Sylvain Wallez <sy...@apache.org>.
Jorg Heymans wrote:
>>
>> Moreover, the use case shows a component type coming directly for the
>> request URI, which is a giant door open to "component injection" by
>> providing a value for the type that is not in the expected values and
>> executes arbitrary code on the server.
>
> Wooo hold on here, what you just described sounds a bit like a buffer
> overflow type of exploit, a bit of overkill i think.
>
> Granted, if i can
> 1) upload my component
> 2) reload/restart the servlet container
> 3) get my components initialize() to run
>
> then i'm in business. But how feasible is this? Worst case would be if
> the user configured fileuploads to go to web-inf/lib or
> web-inf/classes but then you're in trouble anyway because i'll upload
> my custom servlet class that overwrites the cocoon servlet.
>
> Understanding your concerns, but needing a higher than extremely
> unlikely and isolated usecase,
That's not unlikely and doesn't require uploading classes. Consider the
following:
<map:match pattern="*-*.html">
<map:generate src="repository/{1}.xml" type="file"/>
<map:transform type="{2}"/>
<map:serialize type="html"/>
</map:match>
Now suppose we're in a CMS and that the user can upload the initial xml
file. What if {2}, which is expected to be "foo" or "bar" is set to
"jxtemplate"? The uploaded file iss interpreted and can then execute
arbitrary code on the server!
Does this sound so unlikely?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: variable substitution in @type attributes
Posted by Jorg Heymans <jh...@domek.be>.
>
> Moreover, the use case shows a component type coming directly for the
> request URI, which is a giant door open to "component injection" by
> providing a value for the type that is not in the expected values and
> executes arbitrary code on the server.
Wooo hold on here, what you just described sounds a bit like a buffer
overflow type of exploit, a bit of overkill i think.
Granted, if i can
1) upload my component
2) reload/restart the servlet container
3) get my components initialize() to run
then i'm in business. But how feasible is this? Worst case would be if
the user configured fileuploads to go to web-inf/lib or web-inf/classes
but then you're in trouble anyway because i'll upload my custom servlet
class that overwrites the cocoon servlet.
Understanding your concerns, but needing a higher than extremely
unlikely and isolated usecase,
Jorg
Re: variable substitution in @type attributes
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>I think one major point is security or more precise: to detect possible problems early on. If you now use a wrong type information, which means address a component that doesn't exist, you get an exception immediately on startup. So, you know very early that your application is not correct.
>
>With a dynamic type attribute you defer this to a much later point which might be dangerous as well and very hard to find.
>
>
Moreover, the use case shows a component type coming directly for the
request URI, which is a giant door open to "component injection" by
providing a value for the type that is not in the expected values and
executes arbitrary code on the server.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: variable substitution in @type attributes
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
I think one major point is security or more precise: to detect possible
problems
early on. If you now use a wrong type information, which means address a
component that doesn't exist, you get an exception immediately on startup.
So, you know very early that your application is not correct.
With a dynamic type attribute you defer this to a much later point which
might
be dangerous as well and very hard to find.
Carsten
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org]On Behalf Of Jorg Heymans
> Sent: Wednesday, February 04, 2004 3:51 PM
> To: dev@cocoon.apache.org
> Subject: Re: variable substitution in @type attributes
>
>
> Vadim, that post is from 2001.
>
> The arguments are:
> - it affects the cache ->is this still relevant for the rewritten cache
> mechanism in 2.1+ ?
> - Flexibility syndrome ->point taken
> - It's a reactor pattern forcing distribution of control and increasing
> the number of contracts between the different contexts. ->not sure what
> is meant there. Does he mean that selecting a component during pipeline
> setup would not be the sole decision of the sitemap anymore? Which
> contexts are meant here?
>
> I can understand the pipeline overhead in looking through the list of
> all components everytime for one that matches the parameter, but this
> could be documented and left to the user to decide what he prefers most.
>
>
> Please note that I am not trying to advocate this change, just looking
> to up my knowledge on cocoon another nudge.
>
> thanks
> Jorg
>
> Vadim Gritsenko wrote:
>
> > Jorg Heymans wrote:
> >
> >> Carrying the discussion over from users@
> >> Why is variable substituion not allowed in @type attributes ?
> >
> >
> >
> > Archives have it.
> >
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98867067826565&w=2
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98867067826565&w=2
> >
> > Vadim
> >
> >
>
>
Re: variable substitution in @type attributes
Posted by Jorg Heymans <jh...@domek.be>.
Vadim, that post is from 2001.
The arguments are:
- it affects the cache ->is this still relevant for the rewritten cache
mechanism in 2.1+ ?
- Flexibility syndrome ->point taken
- It's a reactor pattern forcing distribution of control and increasing
the number of contracts between the different contexts. ->not sure what
is meant there. Does he mean that selecting a component during pipeline
setup would not be the sole decision of the sitemap anymore? Which
contexts are meant here?
I can understand the pipeline overhead in looking through the list of
all components everytime for one that matches the parameter, but this
could be documented and left to the user to decide what he prefers most.
Please note that I am not trying to advocate this change, just looking
to up my knowledge on cocoon another nudge.
thanks
Jorg
Vadim Gritsenko wrote:
> Jorg Heymans wrote:
>
>> Carrying the discussion over from users@
>> Why is variable substituion not allowed in @type attributes ?
>
>
>
> Archives have it.
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98867067826565&w=2
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98867067826565&w=2
>
> Vadim
>
>
Re: variable substitution in @type attributes
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jorg Heymans wrote:
> Carrying the discussion over from users@
> Why is variable substituion not allowed in @type attributes ?
Archives have it.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98867067826565&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98867067826565&w=2
Vadim
Re: variable substitution in @type attributes
Posted by Jorg Heymans <jh...@domek.be>.
that's what i feared - but somehow i couldn't come up with the right
keywords for my search. Care to give me a hint?
thanks
Jorg
Carsten Ziegeler wrote:
> This was discussed several times, please have a look in the archives.
>
> HTH
> Carsten
>
>
>>-----Original Message-----
>>From: news [mailto:news@sea.gmane.org]On Behalf Of Jorg Heymans
>>Sent: Wednesday, February 04, 2004 3:11 PM
>>To: dev@cocoon.apache.org
>>Subject: variable substitution in @type attributes
>>
>>
>>Carrying the discussion over from users@
>>Why is variable substituion not allowed in @type attributes ?
>>(or: is there a better way to translate below pseudo-syntax into real
>>syntax?)
>>
>> >>
>> >> Imagine Tuomo's usecase a bit more extended
>> >>
>> >> <map:match pattern="*.*">
>> >> <map:generate src="{1}.{2}"/>
>> >> <map:transform type="{2}"/>
>> >> <map:serialize type="{2}"/>
>> >> </map:match>
>> >>
>> >> Using the old syntax this becomes
>> >>
>> >> <map:match pattern="*.*">
>> >> <map:select type="parameter">
>> >> <map:parameter name="parameter-selector-test" value="{2}"/>
>> >> <!-- for each possible file extension you need to have this block -->
>> >> <map:when test="svg">
>> >> <map:generate src="{1}.{2}"/>
>> >> <map:transform type="svg"/>
>> >> <map:serialize type="svg"/>
>> >> </map:when>
>> >> <map:when test="video">
>> >> <map:generate src="{1}.{2}"/>
>> >> <map:transform type="video"/>
>> >> <map:serialize type="video"/>
>> >> </map:when>
>> >> ......
>> >> </map:select>
>> >> </map:match>
>> >>
>>
>>
>>
>>
>
RE: variable substitution in @type attributes
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
This was discussed several times, please have a look in the archives.
HTH
Carsten
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org]On Behalf Of Jorg Heymans
> Sent: Wednesday, February 04, 2004 3:11 PM
> To: dev@cocoon.apache.org
> Subject: variable substitution in @type attributes
>
>
> Carrying the discussion over from users@
> Why is variable substituion not allowed in @type attributes ?
> (or: is there a better way to translate below pseudo-syntax into real
> syntax?)
>
> >>
> >> Imagine Tuomo's usecase a bit more extended
> >>
> >> <map:match pattern="*.*">
> >> <map:generate src="{1}.{2}"/>
> >> <map:transform type="{2}"/>
> >> <map:serialize type="{2}"/>
> >> </map:match>
> >>
> >> Using the old syntax this becomes
> >>
> >> <map:match pattern="*.*">
> >> <map:select type="parameter">
> >> <map:parameter name="parameter-selector-test" value="{2}"/>
> >> <!-- for each possible file extension you need to have this block -->
> >> <map:when test="svg">
> >> <map:generate src="{1}.{2}"/>
> >> <map:transform type="svg"/>
> >> <map:serialize type="svg"/>
> >> </map:when>
> >> <map:when test="video">
> >> <map:generate src="{1}.{2}"/>
> >> <map:transform type="video"/>
> >> <map:serialize type="video"/>
> >> </map:when>
> >> ......
> >> </map:select>
> >> </map:match>
> >>
>
>
>
>