forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Williams" <william...@gmail.com>
Subject Re: [RT] structurer location and resource types
Date Fri, 24 Mar 2006 12:36:00 GMT
On 3/24/06, David Crossley <crossley@apache.org> wrote:
> 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 forrest.properties.xml 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

He sent a strongly titled and provocative email for effective. 
There's a lot more to it than that and concluding that "Stefanos
opinion is that cocoon has become obsolete" is hasty and unfair all
the way around.

http://www.betaversion.org/~stefano/linotype/news/94/

--tim

Mime
View raw message