forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: status of skins and dispatcher for 0.8 release
Date Tue, 02 May 2006 22:45:40 GMT
El mar, 02-05-2006 a las 20:36 +0100, Ross Gardler escribió:
> 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?

yes. :)

That is the basic idea as I understood Nicola after x re-reads. ;) Just
output plain something (xhtml or xhtml2) and then let the theming engine
take over. 

...and yes, we only provide different seeds to the different
approaches. the end, who set the dispatcher is "better" then skins. ;) Skins
are still way faster and doing certain partial jobs very well, so not
need to migrate to the dispatcher right away. In the end the only thing
that we need in forrest as interface is *one* common interface (let it
be xdocs for now and xhtml2 in the future).

If somebody starts an skin plugin I reckon I am the first one to help
but we need a common output that is way easier as the question
dispatcher or skin in any way. ;) We need to remove all skin specific
stuff from core and _should_ move it to a plugin. The holes should be
filled with some very simple and basic *-to-xhtml(2) transformations.

...and yes IMO forrest is a framework that should be able to incorporate
any output coming from whatsoever. That is why I started work on the
dispatcher in the first place, remember? ...and currently working on
doco. ;)

> >>This means that new sites will be seeded with the 
> >>dispatcher as default, old sites will need to add the skins plugin to 
> >>their
> > 
> > 
> > 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).

Well v2 was always one step closer to a stable version for me personally
and nothing more. The current version of the dispatcher is incorporating
plain java processing over xsl magic (one major feedback we had). v2 was
to identify how we could move, v3 was "testing some new stuff" and IMO
the dispatcher (even with the current DOM implementation) is the "way to

...and I think you are the last person on earth to say no, if somebody
would provide e.g. a stax implementation on the cost of some minor
grammar changes (but with a 10* times faster backend) seeing the later
statements. ;)

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

from 0.8 up 

yes, *my personal opinion* (!!!)

...but that means we need to find more people providing backward
compatibility for this part of our code base from 0.8 up. 

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

That is discussed in the other answer of this thread (the interested
reader may follow).


"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message