forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: locationmap mounting [was: Re: [jira] Commented: (FOR-573) Provide locationmap mounting capability
Date Tue, 30 Aug 2005 09:42:48 GMT
On Mon, 2005-08-29 at 20:47 -0400, Tim Williams wrote:
> On 8/29/05, Ross Gardler <> wrote:
> > Thorsten Scherler wrote:
> > > On Mon, 2005-08-29 at 22:39 +0100, Ross Gardler wrote:
> > >
> > >>Thorsten Scherler wrote:
> > >>
> > >>
> > >>>I wonder how the daisy plugin is working from a new seed.
> > >>
> > >>The daisy plugin does not provide a locationmap, it is up to the user to
> > >>do this in their project. This is Ok since the URL of the repository is
> > >>dependant on the project rather than the plugin.
> > >>
> > >
> > >
> > > Actually that is really bad for views and a showstopper to use the lm
> > > within views. Right now you have to do so much preparation that another
> > > step is just overkill. The activation of views already needs more time
> > > then building forrest.
> > 
> > I have suggested, many times, that views should go into core in order to
> > remove the multiple dependencies between your plugins. It is precisely
> > because of this kind of complication that plugins are not supposed to
> > have dependencies as argued by Nicola and myself in, for example,
> >
> I assume Ross mis-typed here "between *your* plugins" and really meant
> "between view-related plugins" ;)

jeje, yes I have read it like you stated Tim. ;-)

> > >>I'd like to make it a config value and provide a plugin locationmap, but
> > >>that is for the future.
> > >>
> > >
> > >
> > > Please, no offense,
> > 
> > [Hmmm...  I'm bracing myself... I've written a reply and come back to
> > remove the "reaction" parts... ]
> > 

Sorry, I do not understand this part. 

> > > but when you knew this, how could you suggest that I
> > > should refactor the view resolver code with the locationmap?
> > 
> > Please, do not get upset that someone does not have the foresight to
> > anticipate every potential hiccup in the development of the project. The
> > reality is that my not forseeing this particular hiccup is no worse than
> > you not foreseeing it - I don't know every detail of the project, just
> > as you do not.

Like I said, no offense, it is only what I said in the other mail.
Sometimes is better to be forced to write some code examples, because
you will properly see what will be the outcome and whether this is a
suitable solution.

No problem, the outcome of my refactoring is a more then suitable
solution, thanks to you and Tim. I just was a wee bit perplex when I
understood that I could not directly use it.

NO HARM DONE! ;-) ...

> Add me to the list of those without foresight -- I failed to think
> through that the selectors wouldn't work for views, leading you to
> have to implement locationmap actions.... wait a minute... now we have
> a more robust locationmap... shortsightedness ain't so bad sometimes;)

Exactly, no harm done just the opposite. I got into the locationmap and
now we have actions in the lm. Perfect outcome. ;-) The problem I am now
facing I had to face one day, start moving views to the core. ;-)

> > > If I check in my local version of views that means every project has to
> > > copy and paste the internal.view locationmap. Not really copyless.
> > 
> > I don't understand what the problem is. Forrest:views are going in core
> > (eventually), therefore the locationmap settings for views should end up
> > in the core Forrest locationmap not some plugin locationmap. What am I
> > missing?
> > 

Actually I did not tell the whole story. I did try to added the
locationmap matches into the core lm, but this got overridden by the
project lm. Well not anymore thx to Tim. ;-) 

> > In the meantime we have a number of potential solutions:
> > 
> > Start a branch and move internal-views into core. This will remove all
> > the dependencies between your plugins as we have always insisted must
> > happen.

I am -1 to open a branch for views. That will cause to much trouble to
afterwards merge it again. We will refactor heaps pipes in the meantime
in trunk and like said before they are the same like for views. We would
end up merging lots of file by hand because we would see "C ...".

As long we keep 2-3 pipes in the plugins we can move nearly everything
into the core without running the danger to hurt the core. The 2-3 are
mainly the *.html part of the plugins.

> > 
> > If you don't want to move it to core yet then we can rely on users
> > copying the locationmap into the project since the plugin is still in
> > the whiteboard and so is not in a finished state.
> > 

Hmm, I think I will move at least the view resolver part to the core
because it is nice code and will not have any influence of the rest of

> > If this is too much for views to be enabled and you still insist on
> > working with the internal plugin model then I'd recomend that we enhance
> > the plugin loading code and, if necessary, the locationmap to mount a lm
> > provided by a plugin.

I do not insist on it. I will start moving parts of views into the core.
Anyway, +1 to enhance the plugin loading code to allow plugins to
provide their own lm.

> I wonder if there's not another option.  It seems like your locations
> wouldn't collide with anything so would there be any harm in just
> putting them in the seed locationmap?  If so, you could at least put
> them in there with comments wrapping them.

I once added view support to the seed when we were in the lm-branch.
When we left the branch people thought it is better to get rid of this
direct support of views. Now we have commented out this part of code.

I reckon I will create a new seed: seed-views. That target will provide
view support out-of the box (still we need to deploy the plugins local).

> > Tell us what you need, we will help you achieve it.
>  +1

Cheers you already helped me.


"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message