forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: [RT] structurer location and resource types
Date Fri, 24 Mar 2006 11:11:33 GMT
Please don't take my comments below the wrong way.
I seek the best for the project.

I know that this is a Random Thought thread but
there seem to be some design and direction things
which should break out into separate discussions.

Thorsten Scherler wrote:
> Ross Gardler escribi??:
> > Thorsten Scherler wrote:
> > > Thorsten Scherler escribi??:
> > 
> > ...
> > 
> > > IMO this internal structurer definition do not belong into the {xdocs}
> > > dir. 
> > > 
> > > Resource types specific structurer have to be stored in a different
> > > folder then the xdocs dir as well. 
> > > 
> > > IMO it makes sense to move them out of the xdocs dir and have something
> > > like
> > > structurer/
> > > |-- internal 
> > > |-- resource-types
> > > `-- url
> > 
> > Can the location be defined in either a property or the locationmap? The 
> > user should be able to specify these locations.
> Well, yes, since this location are *additions* to the current locations
> of the lm the user can override it on a project base. I do not find time
> to implement the in the dispatcher ATM (and not
> in near future), so if somebody want to have this she needs to send a
> patch. 
> > Your suggestion is fine for the defaults though.
> > 
> > However, please, make this backward compatible. There are a number of 
> > sites using Views and it is becoming really difficult to keep track. 
> > Yes, I know it is in whiteboard, and that is the risk on takes, but 
> > deprecating rather than removing would be more appropriate in this stage 
> > of the dispatchers development I would think.
> Like said this new locations will be added to the lm and they do not
> replace current ones. Sadly a @deprecate does only work on java files
> AFAIK, but we should update the docs that say to place it into the xdocs
> dir.
> Regarding backward compatible in general for views/dispatcher/... we
> said that we do not care about it. 

Did we decide on a plan for removing those old 
plugins and docs before releasing 0.8?

At some stage soon we do need to worry about
backwards compatibility.

I would like us to get moving on solving the
general issues for the release, not just the
dispatcher ones. We are dragging on too long.

Anyway, this is an RT thread, so that is a topic
for another thread.

> More, I have reached the point in development (right now) where I see
> the dispatcher way too forrest specific and I want to remove all what is
> "forrest only". There should be no code in the dispatcher that forces
> the user to actually use forrest (forrest is one out of many excellent
> frameworks), the dispatcher is an independent component/framework (well
> heavily incooperating the lm) and should be seen as it.

I know that this is an RT, but would it be better
to get something that people can use and then we can
refactor later. We have halted development on skins.
Now it looks like endless delays on the dispatcher.
This is worrying.

> That leads to the need to extract as well the lm from forrest core and
> to make it to a component on its own (maybe to store the lm in a plugin
> makes the most sense).

Or perhaps a Cocoon block that we maintain.

> Actually I am thinking it would make sense to make the dispatcher a
> project on its own and support different frameworks, like e.g. Struts.
> Maybe starting as the first forrest subproject which offers different
> contracts/structurer for e.g. Lenya, forrest, cocoon, struts, ... as
> plugins, modules, ....

I don't think that this project is big enough
to support sub-projects. We are barely a functioning
community at the moment. The number of truly active
developers is very small.

> Further I am dreaming of a no-cocoon based
> implementation of the dispatcher, like as an extension for mozilla
> (written in POJ - I more and more understand Stefanos opinion "that
> cocoon has become obsolete").

Well that is Stefano's opinion. Also he hasn't
been involved in Cocoon development for a long time.
Being a researcher it is not surprising that he
keeps moving on to new things.

Forrest is still firmly based on Cocoon. We say so
in our project description. We need to be careful
not to destroy confidence by suggesting that it
is obsolete.

> That has as well the big advantage that forrest user do not have to use
> the dispatcher but can rather keep on using skins, which will stay the
> default rendering mechanism for forrest.

Huh? I thought that we were deprecating skins.
Perhaps we need to revisit that. Maybe we really
should provide two mechanims: skins and dispatcher.

I know we said that for the upcoming 0.8 release
that skins will still be the default. Is that what
you are referring to?


View raw message