forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: status of skins and dispatcher for 0.8 release
Date Tue, 02 May 2006 19:36:59 GMT
Thorsten Scherler wrote:
> El mar, 02-05-2006 a las 17:50 +0100, Ross Gardler escribió:
> 
>>David Crossley wrote:
>>
>>>We need to have a very clear statement about the
>>>status of "Skins" and "Dispatcher" for the upcoming
>>>0.8 release. This statement needs to reflect the vision
>>>of developers and where the PMC wants the project to
>>>be going.
>>>
>>>At the same time we need to be careful to not get
>>>people over-excited about new technologies that are
>>>not quite ready. Remember the mess that we got into
>>>at Apache Incubator.
>>>
>>>Users and developers need to know that Skins are
>>>still usable and still the main mechanism.
>>>
>>>There is then the Dispatcher work-in-progress that
>>>has reached an excellent stage. We certainly want to
>>>encourage people to investigate it and help to
>>>develop it.
>>>
>>>It is my understanding that we have not yet made a
>>>decision about when Dispatcher will be ready, nor
>>>whether it will replace skins or whether both will
>>>be usable as plugins. I, for one, am happy to further
>>>delay that decision, but we need to come up with
>>>some words to define the situation.
>>>
>>>What do others think?
>>
>>It is my understanding that the intention is to eventually have 
>>dispatcher in core and that the current skins functionality will move to 
>>an internal plugin. 
> 
> 
> No, not sure about the moving to core part. I do not think it is a good
> idea to add the dispatcher "directly" to the "core". 
> 
> Lately I reread lots of Nicolas Ken threads about html as internal
> format, then I looked at the plain skin and our WD. I agree the core
> should provide xhmtl2 and xhtml support from the core, but I think that
> should be *un-skinned* or *un-dispatched*. Basically *only* the plain
> skin applied, but even without any navigation information (such as menu,
> tabs, etc.). I will write a plain theme to explain. ;)
> 
> The dispatcher will become as well a core plugin (but stay within a
> plugin) and as well the themes.core. The skins should (not sure if
> somebody will do it) as well become a plugin.

If I understand you correctly I think this is a great idea. Let me 
explain why...

I currently use the Cocoon Portal to generate the final skinned/themed 
content for many of my sites. I am also doing a new project now that 
uses Tiles (within Struts). In these instances I request the body-*.html 
page from Forrest and include it in the relevant rendering platform.

If we do as you suggest, and have core only outputting XHTML2, the user 
is free to use whatever skinning/theming engine they need. This makes 
Forrest much more flexible in terms of embedding it in new applications 
and would help us get away from the view that "Forrest is a web site 
generation tool".

We can still provide a number of seed and samples illustrating different 
approaches to content skinning.

Am I following you correctly?

>>This means that new sites will be seeded with the 
>>dispatcher as default, old sites will need to add the skins plugin to 
>>their forrest.properties.
> 
> 
> yes
> 
> 
>>It is my understanding that this is scheduled to happen in the 0.9 
>>release, by which time the dispatcher should be stable.
> 
> 
> yes
> 
> 
>>So, my questions are:
>>
>>1) is my understanding correct?
>>2) is the dispatcher stable in its implementation? 
> 
> 
> Seems stable from the community feedback, or? ;)

Yes it does seem stable, but then I thought that about views 2 as well, 
then you went and made major architectural changes (for the better of 
course).

>>That is, can people 
>>adopt it without fear of their sites breaking or the dispatcher moving 
>>so far from its current implementation that sites will need to be 
>>reconfigured?
> 
> 
> Well I am tended to play the oracle from delphi, but seriously I think
> we should adopt user feedback as well in the future like now. If that
> means we need to change some things than we need to do it (like we
> always did). 

If users get involved they need backward compatability. Devs expect 
things to break in alpha code, users do not understand that. So is it 
stable enough for us to promise backward compatability?

> ...but I personally consider the current structurer/contract grammar
> (the only thing that would need reconfiguring) as stable. Like said
> above when we get lots of feedback to change some things then we need to
> decide on a case-per-case basis but generally we are always open for
> enhancements. 

Of course, sometimes things need to break. If the payoff is sufficient 
this is worthwhile.

Your opinion that it is stable in respect to the grammar (pending 
feedback) is good enough for me.

>>If dispatcher cannot be called stable yet then I do not think we should 
>>be encouraging users to adopt it. If it is considered stable then I 
>>think a statement to the effect of "cutting edge users and developers 
>>are encouraged to *test* the dispatcher which is intended to replace 
>>skins in 0.9"
> 
> 
> I think we should move the dispatcher out of the whiteboard now. There
> are only some minor enhancements that keeps it still in there. I reckon
> when we are switching to dispatcher after the 0.8 release (in 0.9-dev)
> then the least thing is to add the dispatcher to the official plugins
> before the 0.8 release. It is just a svn mv and some other things, or?

What is required to get things like PDF generation of a dispatcher 
enabled site working?

Ross


Mime
View raw message