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
