You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@media.demon.co.uk> on 2003/01/28 13:58:52 UTC
input module question
Hi All,
I am interested in seeing whether Input Modules in the Sitemap can use
Sitemap params as their own params.
I am looking at all the different ways to solve a problem .... before
we choose a solution
Say I have a set of urls:
/archive/people/ABC
<snip/>
/archive/people/WXYZ
Which result in modifications to an SQL Query:
WHERE surname LIKE 'A%' OR 'B%' OR 'C%'
<snip/>
WHERE surname LIKE 'W%' OR 'X%' OR 'Y%' OR 'Z%'
Say I had an XML file, used by the XMLFileModule (mapped to
'alphabet'), that mapped each (allowed) letter group to the query
modification it needed, then this could be passed by the sitemap to the
SQLTransformer via a map:parameter into a <substitute-value
sql:name="alphabet"/>.
But is this possible?
<map:match pattern="archive/(.*)/([A-Z]*)$" type="regexp">
<map:generate src="{our:content}/archive/{1}.xml"/>
<snip/>
<map:transform type="sql">
<map:parameter name="alphabet" value="{alphabet:{2}}"/>
</map:transform> ^^^ ????????
<snip/>
</map:match>
Is this possible to do?
This is just one solution I am looking at ..... but thanks for any help
anyway ....
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: input module question
Posted by Vadim Gritsenko <va...@verizon.net>.
Konstantin Piroumian wrote:
>From: "Nicola Ken Barozzi" <ni...@apache.org>
>
>
>>Konstantin Piroumian wrote:
>>
>>
>>>From: "Jeremy Quinn" <je...@media.demon.co.uk>
>>>
>>>
>>>> <map:parameter name="alphabet" value="{alphabet:{2}}"/>
>>>> </map:transform> ^^^ ????????
>>>> <snip/>
>>>></map:match>
>>>>
>>>>Is this possible to do?
>>>>
>>>>
>>>Unfortunately no. I've raised this issue on dev list, but no one had a
>>>solution to it (I hope we'd invent something for that).
>>>
>>>
>>In xpath one uses $ for variables.
>>I would assume this could be a possible notation {alphabet:$2}
>>
>>
>
>I had the same idea.
>Also, we could use the same notation for input modules, e.g.: $request,
>$session, $xml-file and then we could combine them in any XPath expressions
>like:
>src="$session/attribute($request/paramValue[@name='style'])"... Seems a
>little complex... just a quick idea.
>
>
Is it a good idea to change the syntax so late in the game? Why not
simply implement recursive {a{b}} substitution? In 2.0.4 series, this
code lives in AbstractSitemap.java, substitute() method. I believe in
2.1 this is in PreparedVariableResolver.java, <init> method.
Vadim
>--
> Konstantin
>
>
>
>>--
>>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: input module question
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Konstantin Piroumian wrote:
>
> From: "Nicola Ken Barozzi" <ni...@apache.org>
> > Konstantin Piroumian wrote:
> > > From: "Jeremy Quinn" <je...@media.demon.co.uk>
> >
> > >> <map:parameter name="alphabet" value="{alphabet:{2}}"/>
> > >> </map:transform> ^^^ ????????
> > >> <snip/>
> > >></map:match>
> > >>
> > >>Is this possible to do?
> > >
> > > Unfortunately no. I've raised this issue on dev list, but no one had a
> > > solution to it (I hope we'd invent something for that).
> >
> > In xpath one uses $ for variables.
> > I would assume this could be a possible notation {alphabet:$2}
>
> I had the same idea.
> Also, we could use the same notation for input modules, e.g.: $request,
> $session, $xml-file and then we could combine them in any XPath
> expressions
> like:
> src="$session/attribute($request/paramValue[@name='style'])"... Seems a
> little complex... just a quick idea.
>
Please, don't forget that the current syntax
{INPUT_MODULE:VALUE|PATH|WHATEVER}
is release with 2.0.4 (and I think 2.0.3), so whatever you come up with the
old syntax should still work.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: input module question
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Nicola Ken Barozzi" <ni...@apache.org>
> Konstantin Piroumian wrote:
> > From: "Jeremy Quinn" <je...@media.demon.co.uk>
>
> >> <map:parameter name="alphabet" value="{alphabet:{2}}"/>
> >> </map:transform> ^^^ ????????
> >> <snip/>
> >></map:match>
> >>
> >>Is this possible to do?
> >
> > Unfortunately no. I've raised this issue on dev list, but no one had a
> > solution to it (I hope we'd invent something for that).
>
> In xpath one uses $ for variables.
> I would assume this could be a possible notation {alphabet:$2}
I had the same idea.
Also, we could use the same notation for input modules, e.g.: $request,
$session, $xml-file and then we could combine them in any XPath expressions
like:
src="$session/attribute($request/paramValue[@name='style'])"... Seems a
little complex... just a quick idea.
--
Konstantin
>
> --
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: input module question
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Konstantin Piroumian wrote:
> From: "Jeremy Quinn" <je...@media.demon.co.uk>
>> <map:parameter name="alphabet" value="{alphabet:{2}}"/>
>> </map:transform> ^^^ ????????
>> <snip/>
>></map:match>
>>
>>Is this possible to do?
>
> Unfortunately no. I've raised this issue on dev list, but no one had a
> solution to it (I hope we'd invent something for that).
In xpath one uses $ for variables.
I would assume this could be a possible notation {alphabet:$2}
--
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: input module question
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 29.Jan.2003 -- 03:12 PM, Jeremy Quinn wrote:
> >The snippet above would (currently) be located in cocoon.xconf and the
> >lookup process would be hidden from a sitemap designer's point of
> >view. To the designer, it would be just {foo:bar}.
>
> So (forgive me if I have misunderstood this again) .... the setup that
> says "the value of sitemap-param-1 is used to map to a node's name in
> XMLFileModule" resides globally in Cocoon.xconf, not in the sitemap?
>
> Would this not mean that this module setup could not be re-used in a
> different but similar matcher/pipelines where the key-word comes
> through in a different sitemap=param-#?
Indeed, this would be the case. We are not able to pass more than the
attribute name to the module (from sitemap, that is). Thus it would be
hardwired to a sitemap parameter :-| IOW different instances would be
necessary if different sitemap parameter names are needed.
Of course we could aim at passing more than one parameter to it using
a HTTP GET like syntax.
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
Re: input module question
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Wednesday, Jan 29, 2003, at 13:56 Europe/London, Christian Haul
wrote:
> On 29.Jan.2003 -- 01:42 PM, Jeremy Quinn wrote:
>>
>> On Wednesday, Jan 29, 2003, at 13:21 Europe/London, Christian Haul
>> wrote:
>>
>>> On 29.Jan.2003 -- 11:48 AM, Jeremy Quinn wrote:
>>>>
>>>> On Tuesday, Jan 28, 2003, at 13:40 Europe/London, Christian Haul
>>>> wrote:
>>>>> Like
>>>>>
>>>>> <...... name="phonebook" src="o.a.c.c.m.i.ReplaceAttributeModule">
>>>>> <attribute-module name="sitemap"/>
>>>>> <value-module name="xmlfile"/>
>>>>> </.........>
>>>>>
>>>>> Thoughts?
>>>>
>>>> that snippet was a little too abstract for me, sorry ;)
>>>>
>>>> could you explain that again?
>>>
>>> I see two possible roads ahead: Either to restrict the space of
>>> possible attribute names e.g. by forbidding "{","}" characters and
>>> evaluate the {} expressions recursively from inner most to outer
>>> most.
>>>
>>> The second approach would be to have something similar to the "chain"
>>> module, which glues together different sources. Here, we would need a
>>> source for the attribute name and a source for the actual value. This
>>> way the attribute space would be unrestricted.
>>>
>>> The snippet above intended to show such a glue:
>>>
>>> (1)a (2)a
>>> caller <======> replace <======> sitemap
>>> (6)c ^ (3)b
>>> #
>>> (5)c # (4)b
>>> #
>>> V
>>> xmlfile
>>>
>>> Where (1)...(6) denotes the order in which messages are send and
>>> a,b,c
>>> denotes values.
>>>
>>> "caller" asks "replace" for a value for "a", "replace" asks "sitemap"
>>> for a value for "a" and receives "b". "replace" now uses "b" to ask
>>> "xmlfile" for a value. "xmlfile" returns "c" which is then delivered
>>> back to "caller".
>>
>> Many thanks, Chris, that is a bit clearer.
>>
>> Which solution do people prefer?
>> Is this something we ought to add or is it FS?
>>
>> Do both solutions require changing the SiteMap code to expose runtime
>> sitemap params {0}, {1}, {2} etc.?
>
> The second requires that sitemap variables are exposed. The first
> requires changes to the substitution mechanism, though.
yup
>> What would the syntax in the 2nd example look like in the sitemap?
>
> The snippet above would (currently) be located in cocoon.xconf and the
> lookup process would be hidden from a sitemap designer's point of
> view. To the designer, it would be just {foo:bar}.
So (forgive me if I have misunderstood this again) .... the setup that
says "the value of sitemap-param-1 is used to map to a node's name in
XMLFileModule" resides globally in Cocoon.xconf, not in the sitemap?
Would this not mean that this module setup could not be re-used in a
different but similar matcher/pipelines where the key-word comes
through in a different sitemap=param-#?
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: input module question
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 29.Jan.2003 -- 01:42 PM, Jeremy Quinn wrote:
>
> On Wednesday, Jan 29, 2003, at 13:21 Europe/London, Christian Haul
> wrote:
>
> >On 29.Jan.2003 -- 11:48 AM, Jeremy Quinn wrote:
> >>
> >>On Tuesday, Jan 28, 2003, at 13:40 Europe/London, Christian Haul
> >>wrote:
> >>>Like
> >>>
> >>> <...... name="phonebook" src="o.a.c.c.m.i.ReplaceAttributeModule">
> >>> <attribute-module name="sitemap"/>
> >>> <value-module name="xmlfile"/>
> >>> </.........>
> >>>
> >>>Thoughts?
> >>
> >>that snippet was a little too abstract for me, sorry ;)
> >>
> >>could you explain that again?
> >
> >I see two possible roads ahead: Either to restrict the space of
> >possible attribute names e.g. by forbidding "{","}" characters and
> >evaluate the {} expressions recursively from inner most to outer
> >most.
> >
> >The second approach would be to have something similar to the "chain"
> >module, which glues together different sources. Here, we would need a
> >source for the attribute name and a source for the actual value. This
> >way the attribute space would be unrestricted.
> >
> >The snippet above intended to show such a glue:
> >
> > (1)a (2)a
> > caller <======> replace <======> sitemap
> > (6)c ^ (3)b
> > #
> > (5)c # (4)b
> > #
> > V
> > xmlfile
> >
> >Where (1)...(6) denotes the order in which messages are send and a,b,c
> >denotes values.
> >
> >"caller" asks "replace" for a value for "a", "replace" asks "sitemap"
> >for a value for "a" and receives "b". "replace" now uses "b" to ask
> >"xmlfile" for a value. "xmlfile" returns "c" which is then delivered
> >back to "caller".
>
> Many thanks, Chris, that is a bit clearer.
>
> Which solution do people prefer?
> Is this something we ought to add or is it FS?
>
> Do both solutions require changing the SiteMap code to expose runtime
> sitemap params {0}, {1}, {2} etc.?
The second requires that sitemap variables are exposed. The first
requires changes to the substitution mechanism, though.
> What would the syntax in the 2nd example look like in the sitemap?
The snippet above would (currently) be located in cocoon.xconf and the
lookup process would be hidden from a sitemap designer's point of
view. To the designer, it would be just {foo:bar}.
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
Re: input module question
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeremy Quinn wrote:
>
> On Wednesday, Jan 29, 2003, at 13:21 Europe/London, Christian Haul wrote:
>
>> On 29.Jan.2003 -- 11:48 AM, Jeremy Quinn wrote:
>>
>>>
>>> On Tuesday, Jan 28, 2003, at 13:40 Europe/London, Christian Haul wrote:
>>>
>>>> Like
>>>>
>>>> <...... name="phonebook" src="o.a.c.c.m.i.ReplaceAttributeModule">
>>>> <attribute-module name="sitemap"/>
>>>> <value-module name="xmlfile"/>
>>>> </.........>
>>>>
>>>> Thoughts?
>>>
>>>
>>> that snippet was a little too abstract for me, sorry ;)
>>>
>>> could you explain that again?
>>
>>
>> I see two possible roads ahead: Either to restrict the space of
>> possible attribute names e.g. by forbidding "{","}" characters and
>> evaluate the {} expressions recursively from inner most to outer
>> most.
Just to be mud the waters still, it seems we are ceating our expression
language here with this option.
There are plenty o expression languages available, like jxpath, jexl,
jext, etc. These can be used as inputmodules, and if we create our own
language, we might complicate things.
Example:
Let's say we are using a jxpath inputmodule. It uses $ notation for
variables. If we add the {} recursive system, we are creating an
expression language on top of another... would the user use jxpath $ or
the inputmodule {}?
This seems IMHO to reinforce the following solution:
>> The second approach would be to have something similar to the "chain"
>> module, which glues together different sources. Here, we would need a
>> source for the attribute name and a source for the actual value. This
>> way the attribute space would be unrestricted.
>>
>> The snippet above intended to show such a glue:
>>
>> (1)a (2)a
>> caller <======> replace <======> sitemap
>> (6)c ^ (3)b
>> #
>> (5)c # (4)b
>> #
>> V
>> xmlfile
>>
>> Where (1)...(6) denotes the order in which messages are send and a,b,c
>> denotes values.
>>
>> "caller" asks "replace" for a value for "a", "replace" asks "sitemap"
>> for a value for "a" and receives "b". "replace" now uses "b" to ask
>> "xmlfile" for a value. "xmlfile" returns "c" which is then delivered
>> back to "caller".
>
>
> Many thanks, Chris, that is a bit clearer.
>
> Which solution do people prefer?
Given the above, the second.
> Is this something we ought to add or is it FS?
Something to add IMHO. In practice I've seen that it's needed, like
variables in xpaths.
> Do both solutions require changing the SiteMap code to expose runtime
> sitemap params {0}, {1}, {2} etc.?
>
> What would the syntax in the 2nd example look like in the sitemap?
--
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: input module question
Posted by Stephan Michels <st...@apache.org>.
On Wed, 29 Jan 2003, Jeremy Quinn wrote:
>
> On Wednesday, Jan 29, 2003, at 13:21 Europe/London, Christian Haul
> wrote:
>
> > On 29.Jan.2003 -- 11:48 AM, Jeremy Quinn wrote:
> >>
> >> On Tuesday, Jan 28, 2003, at 13:40 Europe/London, Christian Haul
> >> wrote:
> >>> Like
> >>>
> >>> <...... name="phonebook" src="o.a.c.c.m.i.ReplaceAttributeModule">
> >>> <attribute-module name="sitemap"/>
> >>> <value-module name="xmlfile"/>
> >>> </.........>
> >>>
> >>> Thoughts?
> >>
> >> that snippet was a little too abstract for me, sorry ;)
> >>
> >> could you explain that again?
> >
> > I see two possible roads ahead: Either to restrict the space of
> > possible attribute names e.g. by forbidding "{","}" characters and
> > evaluate the {} expressions recursively from inner most to outer
> > most.
> >
> > The second approach would be to have something similar to the "chain"
> > module, which glues together different sources. Here, we would need a
> > source for the attribute name and a source for the actual value. This
> > way the attribute space would be unrestricted.
> >
> > The snippet above intended to show such a glue:
> >
> > (1)a (2)a
> > caller <======> replace <======> sitemap
> > (6)c ^ (3)b
> > #
> > (5)c # (4)b
> > #
> > V
> > xmlfile
> >
> > Where (1)...(6) denotes the order in which messages are send and a,b,c
> > denotes values.
> >
> > "caller" asks "replace" for a value for "a", "replace" asks "sitemap"
> > for a value for "a" and receives "b". "replace" now uses "b" to ask
> > "xmlfile" for a value. "xmlfile" returns "c" which is then delivered
> > back to "caller".
>
> Many thanks, Chris, that is a bit clearer.
>
> Which solution do people prefer?
> Is this something we ought to add or is it FS?
>
> Do both solutions require changing the SiteMap code to expose runtime
> sitemap params {0}, {1}, {2} etc.?
>
> What would the syntax in the 2nd example look like in the sitemap?
I think solution 1 will be preferred. To allow a syntax like
<map:parameter name="bla" value="{replace:{1}}"/>
is more intuitive.
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: input module question
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Wednesday, Jan 29, 2003, at 13:21 Europe/London, Christian Haul
wrote:
> On 29.Jan.2003 -- 11:48 AM, Jeremy Quinn wrote:
>>
>> On Tuesday, Jan 28, 2003, at 13:40 Europe/London, Christian Haul
>> wrote:
>>> Like
>>>
>>> <...... name="phonebook" src="o.a.c.c.m.i.ReplaceAttributeModule">
>>> <attribute-module name="sitemap"/>
>>> <value-module name="xmlfile"/>
>>> </.........>
>>>
>>> Thoughts?
>>
>> that snippet was a little too abstract for me, sorry ;)
>>
>> could you explain that again?
>
> I see two possible roads ahead: Either to restrict the space of
> possible attribute names e.g. by forbidding "{","}" characters and
> evaluate the {} expressions recursively from inner most to outer
> most.
>
> The second approach would be to have something similar to the "chain"
> module, which glues together different sources. Here, we would need a
> source for the attribute name and a source for the actual value. This
> way the attribute space would be unrestricted.
>
> The snippet above intended to show such a glue:
>
> (1)a (2)a
> caller <======> replace <======> sitemap
> (6)c ^ (3)b
> #
> (5)c # (4)b
> #
> V
> xmlfile
>
> Where (1)...(6) denotes the order in which messages are send and a,b,c
> denotes values.
>
> "caller" asks "replace" for a value for "a", "replace" asks "sitemap"
> for a value for "a" and receives "b". "replace" now uses "b" to ask
> "xmlfile" for a value. "xmlfile" returns "c" which is then delivered
> back to "caller".
Many thanks, Chris, that is a bit clearer.
Which solution do people prefer?
Is this something we ought to add or is it FS?
Do both solutions require changing the SiteMap code to expose runtime
sitemap params {0}, {1}, {2} etc.?
What would the syntax in the 2nd example look like in the sitemap?
Thanks for your suggestions.
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: input module question
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 29.Jan.2003 -- 11:48 AM, Jeremy Quinn wrote:
>
> On Tuesday, Jan 28, 2003, at 13:40 Europe/London, Christian Haul wrote:
> >Like
> >
> > <...... name="phonebook" src="o.a.c.c.m.i.ReplaceAttributeModule">
> > <attribute-module name="sitemap"/>
> > <value-module name="xmlfile"/>
> > </.........>
> >
> >Thoughts?
>
> that snippet was a little too abstract for me, sorry ;)
>
> could you explain that again?
I see two possible roads ahead: Either to restrict the space of
possible attribute names e.g. by forbidding "{","}" characters and
evaluate the {} expressions recursively from inner most to outer
most.
The second approach would be to have something similar to the "chain"
module, which glues together different sources. Here, we would need a
source for the attribute name and a source for the actual value. This
way the attribute space would be unrestricted.
The snippet above intended to show such a glue:
(1)a (2)a
caller <======> replace <======> sitemap
(6)c ^ (3)b
#
(5)c # (4)b
#
V
xmlfile
Where (1)...(6) denotes the order in which messages are send and a,b,c
denotes values.
"caller" asks "replace" for a value for "a", "replace" asks "sitemap"
for a value for "a" and receives "b". "replace" now uses "b" to ask
"xmlfile" for a value. "xmlfile" returns "c" which is then delivered
back to "caller".
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
Re: input module question
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Tuesday, Jan 28, 2003, at 13:40 Europe/London, Christian Haul wrote:
> On 28.Jan.2003 -- 04:12 PM, Konstantin Piroumian wrote:
>> From: "Jeremy Quinn" <je...@media.demon.co.uk>
>>
>>> Hi All,
>>>
>>> I am interested in seeing whether Input Modules in the Sitemap can
>>> use
>>> Sitemap params as their own params.
>>>
>>> I am looking at all the different ways to solve a problem .... before
>>> we choose a solution
>>>
>>> Say I have a set of urls:
>>>
>>> /archive/people/ABC
>>> <snip/>
>>> /archive/people/WXYZ
>>>
>>> Which result in modifications to an SQL Query:
>>>
>>> WHERE surname LIKE 'A%' OR 'B%' OR 'C%'
>>> <snip/>
>>> WHERE surname LIKE 'W%' OR 'X%' OR 'Y%' OR 'Z%'
>>>
>>> Say I had an XML file, used by the XMLFileModule (mapped to
>>> 'alphabet'), that mapped each (allowed) letter group to the query
>>> modification it needed, then this could be passed by the sitemap to
>>> the
>>> SQLTransformer via a map:parameter into a <substitute-value
>>> sql:name="alphabet"/>.
>>>
>>> But is this possible?
>>>
>>> <map:match pattern="archive/(.*)/([A-Z]*)$" type="regexp">
>>> <map:generate src="{our:content}/archive/{1}.xml"/>
>>> <snip/>
>>> <map:transform type="sql">
>>> <map:parameter name="alphabet" value="{alphabet:{2}}"/>
>>> </map:transform> ^^^
>>> ????????
>>> <snip/>
>>> </map:match>
>>>
>>> Is this possible to do?
>>
>> Unfortunately no. I've raised this issue on dev list, but no one had a
>> solution to it (I hope we'd invent something for that).
>
> If we do that, we restrict the space of possible attributes so that
> they may not contain curly brackets. Or we would need an escape
> character. Not sure if this would be too restrictive.
>
> Another solution would be to hold sitemap variables in a place where
> they would be accessible to other components (e.g. objectModel?) and
> have an module for this substitution.
yeah
>
> Like
>
> <...... name="phonebook" src="o.a.c.c.m.i.ReplaceAttributeModule">
> <attribute-module name="sitemap"/>
> <value-module name="xmlfile"/>
> </.........>
>
> Thoughts?
that snippet was a little too abstract for me, sorry ;)
could you explain that again?
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: input module question
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 28.Jan.2003 -- 04:12 PM, Konstantin Piroumian wrote:
> From: "Jeremy Quinn" <je...@media.demon.co.uk>
>
> > Hi All,
> >
> > I am interested in seeing whether Input Modules in the Sitemap can use
> > Sitemap params as their own params.
> >
> > I am looking at all the different ways to solve a problem .... before
> > we choose a solution
> >
> > Say I have a set of urls:
> >
> > /archive/people/ABC
> > <snip/>
> > /archive/people/WXYZ
> >
> > Which result in modifications to an SQL Query:
> >
> > WHERE surname LIKE 'A%' OR 'B%' OR 'C%'
> > <snip/>
> > WHERE surname LIKE 'W%' OR 'X%' OR 'Y%' OR 'Z%'
> >
> > Say I had an XML file, used by the XMLFileModule (mapped to
> > 'alphabet'), that mapped each (allowed) letter group to the query
> > modification it needed, then this could be passed by the sitemap to the
> > SQLTransformer via a map:parameter into a <substitute-value
> > sql:name="alphabet"/>.
> >
> > But is this possible?
> >
> > <map:match pattern="archive/(.*)/([A-Z]*)$" type="regexp">
> > <map:generate src="{our:content}/archive/{1}.xml"/>
> > <snip/>
> > <map:transform type="sql">
> > <map:parameter name="alphabet" value="{alphabet:{2}}"/>
> > </map:transform> ^^^ ????????
> > <snip/>
> > </map:match>
> >
> > Is this possible to do?
>
> Unfortunately no. I've raised this issue on dev list, but no one had a
> solution to it (I hope we'd invent something for that).
If we do that, we restrict the space of possible attributes so that
they may not contain curly brackets. Or we would need an escape
character. Not sure if this would be too restrictive.
Another solution would be to hold sitemap variables in a place where
they would be accessible to other components (e.g. objectModel?) and
have an module for this substitution.
Like
<...... name="phonebook" src="o.a.c.c.m.i.ReplaceAttributeModule">
<attribute-module name="sitemap"/>
<value-module name="xmlfile"/>
</.........>
Thoughts?
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
Re: input module question
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Jeremy Quinn" <je...@media.demon.co.uk>
> Hi All,
>
> I am interested in seeing whether Input Modules in the Sitemap can use
> Sitemap params as their own params.
>
> I am looking at all the different ways to solve a problem .... before
> we choose a solution
>
> Say I have a set of urls:
>
> /archive/people/ABC
> <snip/>
> /archive/people/WXYZ
>
> Which result in modifications to an SQL Query:
>
> WHERE surname LIKE 'A%' OR 'B%' OR 'C%'
> <snip/>
> WHERE surname LIKE 'W%' OR 'X%' OR 'Y%' OR 'Z%'
>
> Say I had an XML file, used by the XMLFileModule (mapped to
> 'alphabet'), that mapped each (allowed) letter group to the query
> modification it needed, then this could be passed by the sitemap to the
> SQLTransformer via a map:parameter into a <substitute-value
> sql:name="alphabet"/>.
>
> But is this possible?
>
> <map:match pattern="archive/(.*)/([A-Z]*)$" type="regexp">
> <map:generate src="{our:content}/archive/{1}.xml"/>
> <snip/>
> <map:transform type="sql">
> <map:parameter name="alphabet" value="{alphabet:{2}}"/>
> </map:transform> ^^^ ????????
> <snip/>
> </map:match>
>
> Is this possible to do?
Unfortunately no. I've raised this issue on dev list, but no one had a
solution to it (I hope we'd invent something for that).
--
Konstantin
>
> This is just one solution I am looking at ..... but thanks for any help
> anyway ....
>
> regards Jeremy
>
>
>
>
> ---------------------------------------------------------------------
> 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