You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Rasik Pandey <rb...@gmail.com> on 2005/08/03 20:28:25 UTC
Re: Add support for Googles sitemap protocol?
Hi Ross,
> Agghhhh!!! There's that term "views" again.
>
> We have a real problem here in Forrest at the moment. Views are being
> used to refer to two different things (views in Eclipse and views, the
> replacement for skins). Now we seem to have a third use, I assume this
> is sitemap views (funnily enough I said this may become a conflict in
> another mail earlier today, never thought it would already have happened
> in my inbox).
So with an internal plugin (internal.xmap) will the views (cocoon map:views)
be propagated downard to the main Forrest sitemap? I am new to "plugins" so
if my question contains misconceptions, please let me know. Or are views
still orthogonal(bound) to specific sitemaps as in Cocoon?
> I'm going to delay responding to this because one of the things that
> happened at the Hackathon is that Ferdinand looked at an alternative
> method of identifying which pages were regenerated in a run. Perhaps we
> should wait to see if he thinks it can be applied here.
Any news on this front?
> Internal plugins are for this kind of thing. However, as they stand they
> don't make the code much more maintainable.
I think I have the most basic functionality (not tested) implemented in an
internal plugin. What is the simplest means of pulling values from a
plugin's forrest.properties and accessing them in the internal.xmap? Is
there an InputModule which reads .properties files?
> A possible solution is to use Cocoons new block sitemap loading
> features. This was demonstrated to me at the Hackathon (thanks Daniel),
> it provides a way for plugins to extend existing sitemaps (and other
> plugins). I need to do some experimentation with this so you should
> proceed with an internal plugin for now, we'll address the
> maintainability when experiments are complete.
Ok thanks.
--
Regards,
Rus
www.discountdracula
<http://www.discountdracula.com>.com<http://www.discountdracula.com>
"Your Bargain BloodSucka:
Suckin' the Best Deals Outta the Web"
Re: Add support for Googles sitemap protocol?
Posted by Rasik Pandey <rb...@gmail.com>.
Just put the first version, 0.1-dev, which works with Forrest 0.7 into JIRA.
Ignore the first attachment.
See:
http://issues.apache.org/jira/browse/FOR-597
--
Regards,
Rus
www.discountdracula
<http://www.discountdracula.com>.com<http://www.discountdracula.com>
"Your Bargain BloodSucka:
Suckin' the Best Deals Outta the Web"
Re: Add support for Googles sitemap protocol?
Posted by Ross Gardler <rg...@apache.org>.
Rasik Pandey wrote:
>
> > To answer you specific question. Anything defined in a plugin sitemap
> > (internal or otherwides) has the same access limitations that you will
> > find in any Cocoon sitemap. That means:
>
> Which means views are bound to the sitemap in which they are defined and
> leaves us two options, redeclare all pertinent pipelines in the
> internal.xmap
>
> OR add these two pieces to root Forrest sitemap.xmap:
>
> <map:serializers>
> <map:serializer name="links"
> src="org.apache.cocoon.serialization.LinkSerializer">
> <encoding>ISO-8859-1</encoding>
> </map:serializer>
> </map:serializers>
>
> <map:views>
> <map:view name="links" from-position="last">
> <map:serialize type="links"/>
> </map:view>
> </map:views>
>
> So the LinkStatusGenerator will be able to access the requisite
> information. I am NOT a fan of either approach :( as neither is a neat
> implementation.
I agree neither solution is neat. For version 0.1 of your plugin I would
redefine all pertinent pipelines in the internal.xmap. The longer term
solution will be to use the shiny new sitemap block mounting mechanism
once we can upgrade Cocoon in Forrest. As I think I mentioned before
this allows a level of inheritance in sitemaps, complete with the
ability to override items in the super sitemaps. It even allows for
multiple inheritance.
> > What properties do you want?
> >
> > As a hint you can access most of the properties with {project:foo} where
> > foo is defined within forrest.xconf
>
> You mean within the "forrest.properties" file and NOT the
> "forrest.xconf" file, right?
No, I meant forrest.xconf, but my response was certainly confusing. Let
me try and explain.
Within forrest.xconf there are a properties set that can be accessed
with {forrest:foo} and another set that are accessed with {project:bar}.
The values of these properties are (in some cases) set in
forrest.properties. In other words the user is not supposed to edit
forrest.xconf
See the element <component-instance name="defaults"
class="org.apache.forrest.conf.ForrestConfModule"> for the {forrest:foo}
properties and <component-instance name="project"
class="org.apache.forrest.conf.ForrestConfModule"> for the {project:foo}
properties.
The @foo.bar@ are tags that are replaced by Ant when Forrest is
launched, but in the main they have the same names as properties set in
forrest.properties.
Ross
Re: Add support for Googles sitemap protocol?
Posted by Rasik Pandey <rb...@gmail.com>.
> To answer you specific question. Anything defined in a plugin sitemap
> (internal or otherwides) has the same access limitations that you will
> find in any Cocoon sitemap. That means:
Which means views are bound to the sitemap in which they are defined and
leaves us two options, redeclare all pertinent pipelines in the
internal.xmap
OR add these two pieces to root Forrest sitemap.xmap:
<map:serializers>
<map:serializer name="links" src="
org.apache.cocoon.serialization.LinkSerializer">
<encoding>ISO-8859-1</encoding>
</map:serializer>
</map:serializers>
<map:views>
<map:view name="links" from-position="last">
<map:serialize type="links"/>
</map:view>
</map:views>
So the LinkStatusGenerator will be able to access the requisite information.
I am NOT a fan of either approach :( as neither is a neat implementation.
> What properties do you want?
>
> As a hint you can access most of the properties with {project:foo} where
> foo is defined within forrest.xconf
You mean within the "forrest.properties" file and NOT the "forrest.xconf"
file, right?
That is what I am currently using. I declared a
#project.siteBaseURI=http://www.discountdracula.com
and use it as you described in my internal.xmap.
> Looks like you are stuck with a standard internal plugin for th
> eforseeable future.
Tough luck...
--
Regards,
Rus
www.discountdracula.com <http://www.discountdracula.com>
"Your Bargain BloodSucka:
Suckin' the Best Deals Outta the Web"
Re: Add support for Googles sitemap protocol?
Posted by Ross Gardler <rg...@apache.org>.
Rasik Pandey wrote:
> Hi Ross,
>
> > Agghhhh!!! There's that term "views" again.
> >
> > We have a real problem here in Forrest at the moment. Views are being
> > used to refer to two different things (views in Eclipse and views, the
> > replacement for skins). Now we seem to have a third use, I assume this
> > is sitemap views (funnily enough I said this may become a conflict in
> > another mail earlier today, never thought it would already have happened
> > in my inbox).
>
> So with an internal plugin (internal.xmap) will the views (cocoon
> map:views) be propagated downard to the main Forrest sitemap? I am new
> to "plugins" so if my question contains misconceptions, please let me
> know. Or are views still orthogonal(bound) to specific sitemaps as in
> Cocoon?
Hehe, you see the confusion we are causing using views to refer to so
many different things (are you listening Thorsten?)
To answer you specific question. Anything defined in a plugin sitemap
(internal or otherwides) has the same access limitations that you will
find in any Cocoon sitemap. That means:
if you use cocon:/ it will only search within the root sitemap (i.e.
Forrests sitemap.xmap)
if you use cocoon:// it will search in all subsitemaps starting from the
root sitemap
> > I'm going to delay responding to this because one of the things that
> > happened at the Hackathon is that Ferdinand looked at an alternative
> > method of identifying which pages were regenerated in a run. Perhaps we
> > should wait to see if he thinks it can be applied here.
>
> Any news on this front?
Ferdinand is away for a week. We won't hear anything until he returns
sometime next week.
> > Internal plugins are for this kind of thing. However, as they stand they
> > don't make the code much more maintainable.
>
> I think I have the most basic functionality (not tested) implemented in
> an internal plugin. What is the simplest means of pulling values from a
> plugin's forrest.properties and accessing them in the internal.xmap? Is
> there an InputModule which reads .properties files?
What properties do you want?
As a hint you can access most of the properties with {project:foo} where
foo is defined within forrest.xconf
> > A possible solution is to use Cocoons new block sitemap loading
> > features. This was demonstrated to me at the Hackathon (thanks Daniel),
> > it provides a way for plugins to extend existing sitemaps (and other
> > plugins). I need to do some experimentation with this so you should
> > proceed with an internal plugin for now, we'll address the
> > maintainability when experiments are complete.
>
> Ok thanks.
Unfortunately there is a problem with the CLI in Cocoon Head,
consequently we cannot update Cocoon in Forrest just yet, therefore I
can't do the above experimentation yet. Cheche is woring with the Cocoon
folk to get the CLI sorted out.
Looks like you are stuck with a standard internal plugin for th
eforseeable future.
Ross