You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Thorsten Scherler <th...@apache.org> on 2007/01/17 23:41:28 UTC
url based structurer from plugins
The ultimate changes in the dispatcher have been mainly allowing plugins
to provide dispatcher based resources by ad.
We now support:
- contracts
- x (tiles)
- resources
I think we should allow url related structurer as well.
Meaning e.g. the solr plugin could provide via
resources/structurer/url/solr-search-adv.fv
an advanced search form.
One could then use it in the project like
http://localhost:8888/solr-search-adv.html and it would match the
default implementation if no project one can be found.
wdyt?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: url based structurer from plugins
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2007-01-17 at 23:41 +0100, Thorsten Scherler wrote:
> The ultimate changes in the dispatcher have been mainly allowing plugins
> to provide dispatcher based resources by ad.
>
> We now support:
> - contracts
> - x (tiles)
> - resources
>
> I think we should allow url related structurer as well.
>
> Meaning e.g. the solr plugin could provide via
> resources/structurer/url/solr-search-adv.fv
> an advanced search form.
>
> One could then use it in the project like
> http://localhost:8888/solr-search-adv.html and it would match the
> default implementation if no project one can be found.
Another use case is the css contract branding-theme-profiler.
Current linking to this contract is
<!-- You can request url specific css as defined above,
but beware that you need to use the *.dispatcher.css
extension!!!-->
<css prefix="" url="#{$getRequest}.dispatcher.css" media="screen"
theme="Pelt"/>
provoking:
screenshots.solr.add.do.dispatcher.css being generated which does not
makes sense at all.
<css prefix="" url="themes/profiler.dispatcher.css" media="screen"
theme="Pelt"/>
and adding
resources/structurer/url/themes/profiler.dispatcher.fv with
<forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"
xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
<forrest:view type="css" hooksXpath="/">
<jx:import uri="cocoon://prepare.tiles.pelt-css"/>
</forrest:view>
</forrest:views>
would be so much more elegant and efficient.
salu2
>
> wdyt?
>
> salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: url based structurer from plugins
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Thu, 2007-01-18 at 09:33 +0200, Sjur Moshagen wrote:
> Den 18. jan. 2007 kl. 00.41 skrev Thorsten Scherler:
>
> > I think we should allow url related structurer as well.
> > ...
> > wdyt?
>
> Agree, I think it is a good idea, AFAIU it. I mean: we do already
> support that in the project hierarchy, which means you suggest that
> we should support it as part of the default/forrest/fallback mechanism?
>
http://forrest.apache.org/docs_0_80/howto/howto-buildPlugin.html#Dispatcher
If you mean by default "...Once Dispatcher becomes stable we will add
this matches to the default locationmap which is generated when you seed
a new plugin, but for now it must be done manually." I agree. IMO
dispatcher is getting stable as soon we settle the tiles discussion.
Yes, in the project it is the preferred place to store the url related
structurer.
It would be a change like the last ones on
http://svn.apache.org/viewvc/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml?view=log
Just adding the plugin location to the dispatcher locationmap.
Allowing this makes the resulting pages not support skins since they
depend on the dispatcher lm. The url cannot be resolved in a skin based
project.
salu2
Re: url based structurer from plugins
Posted by Sjur Moshagen <sj...@mac.com>.
Den 18. jan. 2007 kl. 00.41 skrev Thorsten Scherler:
> I think we should allow url related structurer as well.
> ...
> wdyt?
Agree, I think it is a good idea, AFAIU it. I mean: we do already
support that in the project hierarchy, which means you suggest that
we should support it as part of the default/forrest/fallback mechanism?
Sjur
Re: url based structurer from plugins
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Thu, 2007-01-18 at 09:19 +0000, Ross Gardler wrote:
>> Thorsten Scherler wrote:
>>> The ultimate changes in the dispatcher have been mainly allowing plugins
>>> to provide dispatcher based resources by ad.
>>>
>>> We now support:
>>> - contracts
>>> - x (tiles)
>>> - resources
>>>
>>> I think we should allow url related structurer as well.
>>>
>>> Meaning e.g. the solr plugin could provide via
>>> resources/structurer/url/solr-search-adv.fv
>>> an advanced search form.
>>>
>>> One could then use it in the project like
>>> http://localhost:8888/solr-search-adv.html and it would match the
>>> default implementation if no project one can be found.
>>>
>>> wdyt?
>> There is precedent for this in various plugins (including projectInfo).
>>
>> If possible, I'd recommend making the URL configurable from the
>> locationmap just in case there is ever a clash with a users urlspace. i.e.
>>
>> <match pattern="{properties:solr-search-adv}">
>>
>> We can use {properties:*} in the pattern, right?
>>
>
> I tried but it does not seems to work.
Oh well, it would have been nice. Perhaps something for the future. I'm
not intending to make this a condition of your proposal for "url based
structurer".
>
> Further I do not really understand this solution.
>
> <property name="solr-search-adv" value="solr-search.html"/>
> or
> <property name="solr-search-adv"
> value="resolvePluginStructurer.solr-search-adv"/>
>
> I guess it should have been the last one, or?
The way I wrote the match yes. Of course, if we could use input modules
in the pattern it could have been:
<match pattern="resolvePluginStructurer.{properties:solr-search-adv}">
and
<property name="solr-search-adv" value="solr-search.html"/>
Thus, if "solr-search.html" were used as a document URL in a given site
the user would just need to add something like the following to
properties.xml:
<property name="solr-search-adv" value="solrSearch.html"/>
In your specific case the name is fairly specific so would probably not
be a problem, but remember that for a long time Forrest has "reserved"
paths such as "faq.*". Your post made me think of a possible way around
this reservation.
One for the memory banks and a rainy day I think.
Ross
Re: url based structurer from plugins
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2007-01-18 at 09:19 +0000, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > The ultimate changes in the dispatcher have been mainly allowing plugins
> > to provide dispatcher based resources by ad.
> >
> > We now support:
> > - contracts
> > - x (tiles)
> > - resources
> >
> > I think we should allow url related structurer as well.
> >
> > Meaning e.g. the solr plugin could provide via
> > resources/structurer/url/solr-search-adv.fv
> > an advanced search form.
> >
> > One could then use it in the project like
> > http://localhost:8888/solr-search-adv.html and it would match the
> > default implementation if no project one can be found.
> >
> > wdyt?
>
> There is precedent for this in various plugins (including projectInfo).
>
> If possible, I'd recommend making the URL configurable from the
> locationmap just in case there is ever a clash with a users urlspace. i.e.
>
> <match pattern="{properties:solr-search-adv}">
>
> We can use {properties:*} in the pattern, right?
>
I tried but it does not seems to work.
Further I do not really understand this solution.
<property name="solr-search-adv" value="solr-search.html"/>
or
<property name="solr-search-adv"
value="resolvePluginStructurer.solr-search-adv"/>
I guess it should have been the last one, or?
salu2
> Ross
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: url based structurer from plugins
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Thu, 2007-01-18 at 10:49 +0000, Ross Gardler wrote:
>> Thorsten Scherler wrote:
>>> On Thu, 2007-01-18 at 09:19 +0000, Ross Gardler wrote:
>>>> Thorsten Scherler wrote:
>>>>> The ultimate changes in the dispatcher have been mainly allowing plugins
>>>>> to provide dispatcher based resources by ad.
>>>>>
>>>>> We now support:
>>>>> - contracts
>>>>> - x (tiles)
>>>>> - resources
>>>>>
>>>>> I think we should allow url related structurer as well.
>>>>>
>>>>> Meaning e.g. the solr plugin could provide via
>>>>> resources/structurer/url/solr-search-adv.fv
>>>>> an advanced search form.
>>>>>
>>>>> One could then use it in the project like
>>>>> http://localhost:8888/solr-search-adv.html and it would match the
>>>>> default implementation if no project one can be found.
>>>>>
>>>>> wdyt?
>>>> There is precedent for this in various plugins (including projectInfo).
>>>>
>>>> If possible, I'd recommend making the URL configurable from the
>>>> locationmap just in case there is ever a clash with a users urlspace.
>>> Yeah, about the url space:
>>> What I recommend is:
>>> Index: org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
>>> ===================================================================
>>> --- org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
>>> (revision 497342)
>>> +++ org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
>>> (working copy)
>>> @@ -228,6 +228,8 @@
>>> project-based theme-based = directory-based /
>>> parent-directory based (recursively) -->
>>> <location src="{uri}" />
>>> </act>
>>> + <!-- plugin provided Structurer -->
>>> + <location src="{lm:resolvePluginStructurer.{1}}" />
>>> <!-- themes-dir: project-application-based
>>> theme-dir-based -->
>>> <location
>>> src="{lm:themer.project.dir}/{properties:dispatcher.theme}{properties:dispatcher.theme-ext}"
>> That's the ability to override the source url space, I was thinking of
>> the client urlspace. the above doesn't help if a site already has
>> "solr-search-adv.html" or a match for something like "solr*.html" in
>> their project sitemap.
>
> Well, if you have such a match in your project sitemap, it would have
> preference over the one from the dispatcher. If your project still would
> like to use the search form from the plugin you need to implement a url
> structurer (and place it in the desired route) like (not tested but
> should work if we allow subject line):
>
> <jx:template xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
> <jx:import uri="lm://resolvePluginStructurer.solr-search-adv"/>
> </jx:template>
>
> Makes sense?
Yep, but it seems counter intuitive to me. probably because I'm not
deeply into the dispatcher whilst I am deeply into the locationmap.
Anyway, it's all fine, like I said if my preferred route doesn't work
there are other workarounds (you just highlighted one I didn't think of).
Ross
Re: url based structurer from plugins
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Thu, 2007-01-18 at 10:49 +0000, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Thu, 2007-01-18 at 09:19 +0000, Ross Gardler wrote:
> >> Thorsten Scherler wrote:
> >>> The ultimate changes in the dispatcher have been mainly allowing plugins
> >>> to provide dispatcher based resources by ad.
> >>>
> >>> We now support:
> >>> - contracts
> >>> - x (tiles)
> >>> - resources
> >>>
> >>> I think we should allow url related structurer as well.
> >>>
> >>> Meaning e.g. the solr plugin could provide via
> >>> resources/structurer/url/solr-search-adv.fv
> >>> an advanced search form.
> >>>
> >>> One could then use it in the project like
> >>> http://localhost:8888/solr-search-adv.html and it would match the
> >>> default implementation if no project one can be found.
> >>>
> >>> wdyt?
> >> There is precedent for this in various plugins (including projectInfo).
> >>
> >> If possible, I'd recommend making the URL configurable from the
> >> locationmap just in case there is ever a clash with a users urlspace.
> >
> > Yeah, about the url space:
> > What I recommend is:
> > Index: org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> > ===================================================================
> > --- org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> > (revision 497342)
> > +++ org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> > (working copy)
> > @@ -228,6 +228,8 @@
> > project-based theme-based = directory-based /
> > parent-directory based (recursively) -->
> > <location src="{uri}" />
> > </act>
> > + <!-- plugin provided Structurer -->
> > + <location src="{lm:resolvePluginStructurer.{1}}" />
> > <!-- themes-dir: project-application-based
> > theme-dir-based -->
> > <location
> > src="{lm:themer.project.dir}/{properties:dispatcher.theme}{properties:dispatcher.theme-ext}"
>
> That's the ability to override the source url space, I was thinking of
> the client urlspace. the above doesn't help if a site already has
> "solr-search-adv.html" or a match for something like "solr*.html" in
> their project sitemap.
Well, if you have such a match in your project sitemap, it would have
preference over the one from the dispatcher. If your project still would
like to use the search form from the plugin you need to implement a url
structurer (and place it in the desired route) like (not tested but
should work if we allow subject line):
<jx:template xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
<jx:import uri="lm://resolvePluginStructurer.solr-search-adv"/>
</jx:template>
Makes sense?
salu2
Re: url based structurer from plugins
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Thu, 2007-01-18 at 09:19 +0000, Ross Gardler wrote:
>> Thorsten Scherler wrote:
>>> The ultimate changes in the dispatcher have been mainly allowing plugins
>>> to provide dispatcher based resources by ad.
>>>
>>> We now support:
>>> - contracts
>>> - x (tiles)
>>> - resources
>>>
>>> I think we should allow url related structurer as well.
>>>
>>> Meaning e.g. the solr plugin could provide via
>>> resources/structurer/url/solr-search-adv.fv
>>> an advanced search form.
>>>
>>> One could then use it in the project like
>>> http://localhost:8888/solr-search-adv.html and it would match the
>>> default implementation if no project one can be found.
>>>
>>> wdyt?
>> There is precedent for this in various plugins (including projectInfo).
>>
>> If possible, I'd recommend making the URL configurable from the
>> locationmap just in case there is ever a clash with a users urlspace.
>
> Yeah, about the url space:
> What I recommend is:
> Index: org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> ===================================================================
> --- org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> (revision 497342)
> +++ org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> (working copy)
> @@ -228,6 +228,8 @@
> project-based theme-based = directory-based /
> parent-directory based (recursively) -->
> <location src="{uri}" />
> </act>
> + <!-- plugin provided Structurer -->
> + <location src="{lm:resolvePluginStructurer.{1}}" />
> <!-- themes-dir: project-application-based
> theme-dir-based -->
> <location
> src="{lm:themer.project.dir}/{properties:dispatcher.theme}{properties:dispatcher.theme-ext}"
That's the ability to override the source url space, I was thinking of
the client urlspace. the above doesn't help if a site already has
"solr-search-adv.html" or a match for something like "solr*.html" in
their project sitemap.
>> i.e.
>>
>> <match pattern="{properties:solr-search-adv}">
>>
>> We can use {properties:*} in the pattern, right?
>>
>
> Not sure, whether one can use input modules in the pattern. Could be.
If we can it solves the problem. but I don't think i ever tried it. It's
a minor problem though, if it doesn't work there are other workarounds
so don't sweat it.
Ross
Re: url based structurer from plugins
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2007-01-18 at 11:39 +0100, Thorsten Scherler wrote:
> On Thu, 2007-01-18 at 09:19 +0000, Ross Gardler wrote:
> > Thorsten Scherler wrote:
> > > The ultimate changes in the dispatcher have been mainly allowing plugins
> > > to provide dispatcher based resources by ad.
> > >
> > > We now support:
> > > - contracts
> > > - x (tiles)
> > > - resources
> > >
> > > I think we should allow url related structurer as well.
> > >
> > > Meaning e.g. the solr plugin could provide via
> > > resources/structurer/url/solr-search-adv.fv
> > > an advanced search form.
> > >
> > > One could then use it in the project like
> > > http://localhost:8888/solr-search-adv.html and it would match the
> > > default implementation if no project one can be found.
> > >
> > > wdyt?
> >
> > There is precedent for this in various plugins (including projectInfo).
> >
> > If possible, I'd recommend making the URL configurable from the
> > locationmap just in case there is ever a clash with a users urlspace.
>
> Yeah, about the url space:
> What I recommend is:
> Index: org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> ===================================================================
> --- org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> (revision 497342)
> +++ org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> (working copy)
> @@ -228,6 +228,8 @@
> project-based theme-based = directory-based /
> parent-directory based (recursively) -->
> <location src="{uri}" />
> </act>
> + <!-- plugin provided Structurer -->
> + <location src="{lm:resolvePluginStructurer.{1}}" />
> <!-- themes-dir: project-application-based
> theme-dir-based -->
> <location
> src="{lm:themer.project.dir}/{properties:dispatcher.theme}{properties:dispatcher.theme-ext}"
>
> The downside is that an user would need to provide his own
> implementation on the used url structurer if he does not want to use the
> plugin structurer.
>
Actually the major concern to above patch is that it will match to late.
The downside statement above would not happen. Only if we add the match
directly after the url-based matches.
Let me explain. It is coming after the project-based theme-based =
directory-based / parent-directory based (recursively) action. Meaning
as soon you have a structurer in either the structurer url dir or
[depreciated] xdocs dir. The url provided by the plugin would not work
anymore since the locationmap will return a match before it checks the
plugin location.
Current default matching (if not overridden by project implementations)
will search:
1) url-based -
{properties:resources}/structurer/url/{1}{properties:dispatcher.theme-ext}
e.g. structurer/url/index.fv will match server/index.*.
Which leads me to a sharp corner of current implementation. The
structurer does not has to provide a definition for the requested
format. The natural thing would be to check whether this structurer can
handle the format and if not then the locationmap should keep on
checking.
Right now the consequence is that I needed to do
http://svn.apache.org/viewvc?view=rev&rev=496014 for the pelt.fv what
does not feel right.
2) project-based url-based (xdocs location) [depreciated]
{properties:content.xdocs}{1}{properties:dispatcher.theme-ext}
same as above but in the xdocs dir.
3) resourceType based - checks against a resource type structurer
implementation present. If you have a faq page and you want a different
design then you can implement a specific structurer for it.
4) RecursiveDirectory - inherit theme specific structurer.
5) as 4) in [depreciated] location
6) <location src="{uri}" />
7) themes-dir: project-application-based theme-dir-based
{lm:themer.project.dir}/{properties:dispatcher.theme}{properties:dispatcher.theme-ext}
Project based implementation of the core themes plugin
8) themes-dir: project-application-based default
{lm:themer.project.dir}/{properties:dispatcher.fallback.theme}{properties:dispatcher.fallback.theme-ext}
as in 7) but for the default theme
9) themer: forrest-application-based theme-based
{lm:dispatcher.themer}/themes/{properties:dispatcher.theme}{properties:dispatcher.theme-ext}
default themer plugin theme specific
10) themer: forrest-application-based default
{lm:dispatcher.themer}/themes/{properties:dispatcher.fallback.theme}{properties:dispatcher.fallback.theme-ext}
as in 9) but for the default theme
Writing this list, should we reduce it and add documentation how to
implement the rest in project specific settings?
With the suggested patch the count goes to 11. Way to much IMO.
WDYT?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: url based structurer from plugins
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Thu, 2007-01-18 at 09:19 +0000, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > The ultimate changes in the dispatcher have been mainly allowing plugins
> > to provide dispatcher based resources by ad.
> >
> > We now support:
> > - contracts
> > - x (tiles)
> > - resources
> >
> > I think we should allow url related structurer as well.
> >
> > Meaning e.g. the solr plugin could provide via
> > resources/structurer/url/solr-search-adv.fv
> > an advanced search form.
> >
> > One could then use it in the project like
> > http://localhost:8888/solr-search-adv.html and it would match the
> > default implementation if no project one can be found.
> >
> > wdyt?
>
> There is precedent for this in various plugins (including projectInfo).
>
> If possible, I'd recommend making the URL configurable from the
> locationmap just in case there is ever a clash with a users urlspace.
Yeah, about the url space:
What I recommend is:
Index: org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
===================================================================
--- org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
(revision 497342)
+++ org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
(working copy)
@@ -228,6 +228,8 @@
project-based theme-based = directory-based /
parent-directory based (recursively) -->
<location src="{uri}" />
</act>
+ <!-- plugin provided Structurer -->
+ <location src="{lm:resolvePluginStructurer.{1}}" />
<!-- themes-dir: project-application-based
theme-dir-based -->
<location
src="{lm:themer.project.dir}/{properties:dispatcher.theme}{properties:dispatcher.theme-ext}"
The downside is that an user would need to provide his own
implementation on the used url structurer if he does not want to use the
plugin structurer.
Meaning one would need to implement
<match pattern="resolvePluginStructurer.solr-search-adv" /> in the lm
and add a structurer
{properties:resources}/structurer/url/solr-search-adv.fv
The problem resulting is that a plugin would need to report that it
reserved an url space and explain how to override it.
> i.e.
>
> <match pattern="{properties:solr-search-adv}">
>
> We can use {properties:*} in the pattern, right?
>
Not sure, whether one can use input modules in the pattern. Could be.
salu2
> Ross
>
Re: url based structurer from plugins
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> The ultimate changes in the dispatcher have been mainly allowing plugins
> to provide dispatcher based resources by ad.
>
> We now support:
> - contracts
> - x (tiles)
> - resources
>
> I think we should allow url related structurer as well.
>
> Meaning e.g. the solr plugin could provide via
> resources/structurer/url/solr-search-adv.fv
> an advanced search form.
>
> One could then use it in the project like
> http://localhost:8888/solr-search-adv.html and it would match the
> default implementation if no project one can be found.
>
> wdyt?
There is precedent for this in various plugins (including projectInfo).
If possible, I'd recommend making the URL configurable from the
locationmap just in case there is ever a clash with a users urlspace. i.e.
<match pattern="{properties:solr-search-adv}">
We can use {properties:*} in the pattern, right?
Ross