forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [RT] structurer location and resource types
Date Fri, 24 Mar 2006 13:00:38 GMT
El vie, 24-03-2006 a las 22:11 +1100, David Crossley escribió:
> 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?

No, we have a couple of issues though:

It is nearly finished, but help is *very* welcome.

> 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.

What are the general issues? Why do you think *we* are only focusing on
dispatcher ones?

> 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. 

The dispatcher can be used and since 2 month we could have released the
dispatcher from the whiteboard (but I reckon if I am not starting this,
the dispatcher will remain forever in the whiteboard - no offense).

> We have halted development on skins.
> Now it looks like endless delays on the dispatcher.

It is not because of the dispatcher, the dispatcher is not delaying
anything! Forrest core is delaying the release not the dispatcher.

BTW we did not even start talking about releasing 0.8.

> This is worrying.

Well, yes and there are more stuff that worries me.

> > 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.

good as gold


> > 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.

Yes and I wish that our who.html would reflect the reality of active
committer and not listing people as active that have not done a single
commit/mail since years.

Anyway, the reality in this project is that the dispatcher has become a
subproject of forrest. Further the dispatcher does not focus to support
forrest only, I reviewed the dispatcher code and testing ATM to use it
in the cocoon samples and it works quite nicely. 

Being a subproject does not mean that people will not help out here on
forrest, but gives more freedom in releasing/refactoring and extending
the dispatcher.

> > 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.

Well I did not suggest it but rather stated that I *understand* his
thoughts behind it. Let Forrest be firmly be based on cocoon but that
should not mean that *all* components (or subprojects) have to be based
on cocoon. 

See e.g. the forrestbar, that has nothing to do with cocoon at all. Even
the dispatcher can be refactored relative quickly to be used in any
application that can connect to java classes (like firefox 1.5.x).

> > 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.

Lots of talk about it, but the reality seems different. 

> Perhaps we need to revisit that. Maybe we really
> should provide two mechanims: skins and dispatcher.

If so, who will do this? Like you stated yourself:
"The number of truly active developers is very small."

The dispatcher originally started to overcome the downsides of skins and
actually it is (even in current development state) already better then
skins. Skins are *only* working in forrest, the dispatcher is a
standalone component.

Further if somebody has the itch to extract all skin related code [which
is deeply connected to the core, I tell from experience] into a skin
plugin, I am all for having the two mechanism (factor me out for doing
the skin plugins but I will help to remove all reference in the core to

Having said this many times, I think we should let the dispatcher now
grow independent from forrest.

> 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?

I think many committers/dev/user are more committed to skins then to the
dispatcher and this can be seen in the mail archives. That is perfectly
ok, if those committers are willing to support skins in the future.

The question is why would we want to keep skins as default and still not
allow the dispatcher to become a subproject for a bigger audience then
the forrest community?

Even if the dispatcher becomes a sub-project of forrest (like shale in
struts) we still can switch to the dispatcher as default any time. 

Thorsten Scherler
COO Spain
Wyona Inc.  -  Open Source Content Management  -  Apache Lenya               

View raw message