You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Upayavira <uv...@upaya.co.uk> on 2004/03/26 13:02:47 UTC
Nested input module support in sitemap
Guys,
Is anyone interested in nested input module support in the sitemap? I
want to be able to say:
{i18n:{1}.{locale}.xml} and have my i18n input module go and look to see
if the related file exists. [NB. There's subtleties I haven't thought
through yet in this example - but I'm not worrying about those for now -
just working on the nested functionality first]
The current parser in the PreparedVariableResolver doesn't handle
nesting, but I've got a design that has worked on paper, which I'm now
coding up to handle everything that the existing
PreparedVariableResolver does.
What should I do with this new code? Swap out the
PreparedVariableResolver, replacing it with my code? Add a new version
to run alongside for a while???
Ideas welcome.
Regards, Upayavira
Re: Nested input module support in sitemap
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Tony Collen wrote:
> Upayavira wrote:
>
>> Ideas welcome.
>
> Here's an Idea (or maybe more of a thought):
>
> Wouldn't this make the AbstractMetaModule obsolete?
>
> When would someone want to build a MetaModule instead of just using the
> nesting?
Simple. Nesting is to be written every time, while using a meta module
you make the "nesting" available to all in one go.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Nested input module support in sitemap
Posted by Tony Collen <co...@umn.edu>.
Upayavira wrote:
>
> Ideas welcome.
Here's an Idea (or maybe more of a thought):
Wouldn't this make the AbstractMetaModule obsolete?
When would someone want to build a MetaModule instead of just using the nesting?
Regards,
Tony
Re: Nested input module support in sitemap
Posted by Upayavira <uv...@upaya.co.uk>.
Geoff Howard wrote:
> Nicola Ken Barozzi wrote:
>
>> Upayavira wrote:
>>
>>> Guys,
>>>
>>> Is anyone interested in nested input module support in the sitemap?
>>
>>
>>
>> I am (as a user :-)
>
>
> Me too (though I didn't understand the example below).
Try a rather hacky example of {request-parameter:{1}}. But I didn't use
that one because that's exactly the sort of thing that'll get this
functionality banned!
>>> I want to be able to say:
>>>
>>> {i18n:{1}.{locale}.xml} and have my i18n input module go and look to
>>> see if the related file exists. [NB. There's subtleties I haven't
>>> thought through yet in this example - but I'm not worrying about
>>> those for now - just working on the nested functionality first]
>>>
>>> The current parser in the PreparedVariableResolver doesn't handle
>>> nesting, but I've got a design that has worked on paper, which I'm
>>> now coding up to handle everything that the existing
>>> PreparedVariableResolver does.
>>>
>>> What should I do with this new code? Swap out the
>>> PreparedVariableResolver, replacing it with my code? Add a new
>>> version to run alongside for a while???
>>
>>
>> I'd put the new code in, as it should be backward compatible. MHO
>
>
> I agree.
Okay. Mildly frightened that I'll horribly break something though.
Upayavira
>
> Geoff
>
Re: Nested input module support in sitemap
Posted by Geoff Howard <co...@leverageweb.com>.
Nicola Ken Barozzi wrote:
> Upayavira wrote:
>
>> Guys,
>>
>> Is anyone interested in nested input module support in the sitemap?
>
>
> I am (as a user :-)
Me too (though I didn't understand the example below).
>> I want to be able to say:
>>
>> {i18n:{1}.{locale}.xml} and have my i18n input module go and look to
>> see if the related file exists. [NB. There's subtleties I haven't
>> thought through yet in this example - but I'm not worrying about those
>> for now - just working on the nested functionality first]
>>
>> The current parser in the PreparedVariableResolver doesn't handle
>> nesting, but I've got a design that has worked on paper, which I'm now
>> coding up to handle everything that the existing
>> PreparedVariableResolver does.
>>
>> What should I do with this new code? Swap out the
>> PreparedVariableResolver, replacing it with my code? Add a new version
>> to run alongside for a while???
>
> I'd put the new code in, as it should be backward compatible. MHO
I agree.
Geoff
Re: Nested input module support in sitemap
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Upayavira wrote:
> Guys,
>
> Is anyone interested in nested input module support in the sitemap?
I am (as a user :-)
> I want to be able to say:
>
> {i18n:{1}.{locale}.xml} and have my i18n input module go and look to see
> if the related file exists. [NB. There's subtleties I haven't thought
> through yet in this example - but I'm not worrying about those for now -
> just working on the nested functionality first]
>
> The current parser in the PreparedVariableResolver doesn't handle
> nesting, but I've got a design that has worked on paper, which I'm now
> coding up to handle everything that the existing
> PreparedVariableResolver does.
>
> What should I do with this new code? Swap out the
> PreparedVariableResolver, replacing it with my code? Add a new version
> to run alongside for a while???
I'd put the new code in, as it should be backward compatible. MHO
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Nested input module support in sitemap
Posted by Tim Larson <ti...@keow.org>.
On Fri, Mar 26, 2004 at 11:52:41AM -0500, Geoff Howard wrote:
> Tony Collen wrote:
> >Hmm, it's been too long since I've been diving into internals... would
> >it be possible to have to configure the PreparedVariableResolver in
> >cocoon.xconf, which would allow us to choose between nestable and
> >un-nestable resolvers? Or is this too much configurability? :)
>
> Unless there is an imaginable time where a user who does not want to have
> neted behavior happen has to use such a form in their sitemap (which I
> can't imagine currently) then I see no need for the configuration.
You mean like to prevent injection attacks like SQL handles via prepared
statements and parameters?
--Tim Larson
Re: Nested input module support in sitemap
Posted by Geoff Howard <co...@leverageweb.com>.
Tony Collen wrote:
> Upayavira wrote:
>
>> Guys,
>>
>> Is anyone interested in nested input module support in the sitemap? I
>> want to be able to say:
>
> Of course, this would allow something like this:
>
> {urlencode:{request-param:foo}}
>
> Which I think people have been clamoring for for a while ;)
Yup. Very good.
>> What should I do with this new code? Swap out the
>> PreparedVariableResolver, replacing it with my code? Add a new version
>> to run alongside for a while???
>
> Hmm, it's been too long since I've been diving into internals... would
> it be possible to have to configure the PreparedVariableResolver in
> cocoon.xconf, which would allow us to choose between nestable and
> un-nestable resolvers? Or is this too much configurability? :)
Unless there is an imaginable time where a user who does not want to have neted
behavior happen has to use such a form in their sitemap (which I can't imagine
currently) then I see no need for the configuration.
Geoff
Re: Nested input module support in sitemap
Posted by Tony Collen <co...@umn.edu>.
Upayavira wrote:
>
> I tend to think that this one will be about as efficient as the last, so
> long as I don't introduce too many new bugs, it would be good to just
> switch them. The new will still do everything the old one did.
In that case, commit it!! :)
>
> Regards, Upayavira
>
Tony
Re: Nested input module support in sitemap
Posted by Sylvain Wallez <sy...@apache.org>.
Upayavira wrote:
> Tony Collen wrote:
>
>> Upayavira wrote:
>>
>>> Guys,
>>>
>>> Is anyone interested in nested input module support in the sitemap?
>>> I want to be able to say:
>>
+1 !!
>> Of course, this would allow something like this:
>>
>> {urlencode:{request-param:foo}}
>>
>> Which I think people have been clamoring for for a while ;)
>>
>>> What should I do with this new code? Swap out the
>>> PreparedVariableResolver, replacing it with my code? Add a new
>>> version to run alongside for a while???
>>
>>
>>
>> Hmm, it's been too long since I've been diving into internals...
>> would it be possible to have to configure the
>> PreparedVariableResolver in cocoon.xconf, which would allow us to
>> choose between nestable and un-nestable resolvers? Or is this too
>> much configurability? :)
>
>
> I tend to think that this one will be about as efficient as the last,
> so long as I don't introduce too many new bugs, it would be good to
> just switch them. The new will still do everything the old one did.
What about some JUnit tests to ensure it works properly? ;-)
A detail, also: does brace escaping also works with nested braces?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Nested input module support in sitemap
Posted by Upayavira <uv...@upaya.co.uk>.
Tony Collen wrote:
> Upayavira wrote:
>
>> Guys,
>>
>> Is anyone interested in nested input module support in the sitemap? I
>> want to be able to say:
>
>
> Of course, this would allow something like this:
>
> {urlencode:{request-param:foo}}
>
> Which I think people have been clamoring for for a while ;)
>
>> What should I do with this new code? Swap out the
>> PreparedVariableResolver, replacing it with my code? Add a new
>> version to run alongside for a while???
>
>
> Hmm, it's been too long since I've been diving into internals... would
> it be possible to have to configure the PreparedVariableResolver in
> cocoon.xconf, which would allow us to choose between nestable and
> un-nestable resolvers? Or is this too much configurability? :)
I tend to think that this one will be about as efficient as the last, so
long as I don't introduce too many new bugs, it would be good to just
switch them. The new will still do everything the old one did.
Regards, Upayavira
Re: Nested input module support in sitemap
Posted by Tony Collen <co...@umn.edu>.
Upayavira wrote:
> Guys,
>
> Is anyone interested in nested input module support in the sitemap? I
> want to be able to say:
Of course, this would allow something like this:
{urlencode:{request-param:foo}}
Which I think people have been clamoring for for a while ;)
> What should I do with this new code? Swap out the
> PreparedVariableResolver, replacing it with my code? Add a new version
> to run alongside for a while???
Hmm, it's been too long since I've been diving into internals... would it be possible to have to
configure the PreparedVariableResolver in cocoon.xconf, which would allow us to choose between
nestable and un-nestable resolvers? Or is this too much configurability? :)
Regards,
Tony