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