forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: status of skins and dispatcher for 0.8 release
Date Thu, 04 May 2006 04:36:28 GMT
Thorsten Scherler wrote:
> Ross Gardler escribi??:
> > Thorsten Scherler wrote:
> > > 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...

Good, i agree.

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

Good, i agree.

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

Good, i agree. I would like to see skins remain.
They can satisfy certain limited uses and i reckon
that they can be enhanced.

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

Lets do this ASAP after the 0.8 release. Existing
skins to core plugins; xhtml2 as the internal format;
enhance the input.XDoc plugin; and create the input.html
plugin.

Probably need a quick svn branch and some dedicated
team effort.

I reckon that we will find that our core sitemaps
will be able to be vastly simplified.

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

We say that Forrest is a framework in our description.
Good to see the concept being refined.

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

I am not sure what that smiley means, but i have
given some feedback that makes we worry that it
is not stable, e.g. poor performance and the initial
Cocoon profiling indicates complexity.

> > 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
> go".
>
> ...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.
>
> agree
>
> > Devs expect
> > things to break in alpha code, users do not understand that.
>
> agree
>
> > So is it
> > stable enough for us to promise backward compatability?
>
> from 0.8 up
>
> yes, *my personal opinion* (!!!)

Are you sure that the move to xhtml2 in the core
ASAP after the release is not going to affect that?

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

Do you mean "after 0.8" or do you mean "starting with 0.8"?

What do you mean by "find more people"? That seems to
be a sign that there is not yet sufficient community
for this code.

> > > ...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.
>
> exactly
>
> > Your opinion that it is stable in respect to the grammar (pending
> > feedback) is good enough for me.
>
> ok
>
> > >>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"

If we agree on the above discussion about continuing
skins as plugins, then say "alternative to".

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

I don't know what is involved. This case is one of
the first that we have had. I suppose that we would need
a clear proposal and the PMC needs to decide that we agree
with the overall direction and timing, etc.

I don't see why it needs to move out of the whiteboard
at this stage.

-David

> > > I made a start today with a new document called:
> > > "Status of Themes: Skins and Dispatcher" ...
> > > http://svn.apache.org/viewcvs?rev=398810&view=rev
> >
> > It's down at the moment - will look later.
>
> Sounds good.
>
> Thanks David.
>
> salu2
> --
> thorsten
> "Together we stand, divided we fall!"
> Hey you (Pink Floyd)

Mime
View raw message