forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gav...." <>
Subject Re: [RT] structurer location and resource types
Date Fri, 24 Mar 2006 14:08:28 GMT

----- Original Message ----- 
From: "Thorsten Scherler" <>
To: <>
Sent: Friday, March 24, 2006 9:00 PM
Subject: Re: [RT] structurer location and resource types

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

If you give me an example of what needs changing I will have a go over the 

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

Dispatcher is moving along quickly, and so I guess is receiving a lot of 
at the moment, which is good. I do think though that other issues are taking 
back seat at the moment. I for one have been focusing my attentions on 
dispatcher working on my system, trying to find things I could contribute to 
this has the impact of me not looking at Jira for other issues that need 

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

Should the release of the Dispatcher from the Whiteboard come before, after
or at the same time as an official release of 0.8 ? Does releasing features 
Whiteboard have an effect of a minor build release in its own right, whether
it be dispatcher, or a plugin or some other Whiteboard event ?

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

So lets talk about it, I guess we need to filter Jira for what IS holding up
a 0.8 release and go through them. Perhaps the next Forrest Friday should
focus on this. What are the improvements to Forrest other than dispatcher
that warrant there being a 0.8 release ? Are bug fixes and patches from 0.7
reason enough to release Forrest 0.8 without dispatcher being factored
into it -- or are most bug fixes and patches from 0.7 in the current 0.7
downloadable version ?

Should Dispatcher, although as you suggest, not part of the 0.8 release 
and not holding up a 0.8 release, be moved from Whiteboard into core/plugin 
the same time, now, or after ?

What are the incentives for users to upgrade to 0.8 from 0.7 ?

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

Is this a PMC decision, or should those now not currently active, mark
themselves as away for a while ? If it is a 'wish' then have a quick chat 
about it
and do the neccessary, it might be an annoyance, but hardly a show-stopper, 
get it sorted out of the way, or put it out of mind until more important 
things are
out of the way.

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

What will this mean to the rest of Forrest, will those working on Dispatcher
then move away from Forrest to concentrate on it? This will impact I guess
on Forrests core development, but it might also mean those that are left can
concentrate on Forrest and just 'use' dispatcher in a fashion similar to 
devs just 'use' Cocoon. Not sure if this isn't such a bad idea after all.

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

Dispatcher to many is not complete, is still new and still in Whiteboard, 
and I
guess the fact that more are currently still skins biased is because of 

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

You have a vision of Dispatcher that is bigger than most people here, the 
is that Dispatcher was born out of Forrest, from an idea based on skins and 
its restrictions. Sure, move towards eventually making Dispatcher 
but I would not move it away from Forrest, although independent, Forrest I
would say relys on it in as much it relys on Cocoon. Without it, skins can 
be deprecated.

I don't agree that skins should stay, that users have the choice of skins vs 
too messy, too confusing. Give them the choice, stay as they are with skins 
and 0.7
and be supported with bug fixes for the time being - or upgrade to 0.8 and 
later and
move onto the much nicer dispatcher., with I guess 0.9 removing skins 

Just my 2 cents :)


> salu2
> -- 
> Thorsten Scherler
> COO Spain
> Wyona Inc.  -  Open Source Content Management  -  Apache Lenya
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.0/290 - Release Date: 23/03/2006

View raw message