You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by David Crossley <cr...@apache.org> on 2006/05/02 07:09:11 UTC
status of skins and dispatcher for 0.8 release
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?
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
-David
Re: status of skins and dispatcher for 0.8 release
Posted by Ross Gardler <rg...@apache.org>.
Gav.... wrote:
>
>>-----Original Message-----
>>From: Ross Gardler [mailto:rgardler@apache.org]
>>Sent: Wednesday, 3 May 2006 3:47 AM
>>To: dev@forrest.apache.org
>>Subject: Re: status of skins and dispatcher for 0.8 release
>>
>>Thorsten Scherler wrote:
...
>>Are the broken links in the issue I reported [1] still a problem? That
>>issue was closed but I never saw any commits to resolve it.
>
>
> For that xhtml2_subset file yes still broken. Bit I don't think it an Issue
> yet since xhtml2 is not yet being worked on.
OK, thank you both for your clarifications.
My only caution would be, if XHTML2 is not supported then it should not
be in the samples when dispatcher comes out of the whiteboard. Perhaps a
separate "dev" seed could be used to demonstrate "in progress" features.
Ross
Ross
RE: status of skins and dispatcher for 0.8 release
Posted by "Gav...." <br...@brightontown.com.au>.
> -----Original Message-----
> From: Ross Gardler [mailto:rgardler@apache.org]
> Sent: Wednesday, 3 May 2006 3:47 AM
> To: dev@forrest.apache.org
> Subject: Re: status of skins and dispatcher for 0.8 release
>
> Thorsten Scherler wrote:
> > El mar, 02-05-2006 a las 20:27 +0100, Ross Gardler escribió:
> >
> >>Ross Gardler wrote:
> >>
> >>>David Crossley wrote:
> >>
> >>...
> >>
> >>
> >>>>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.
> >>
> >>It looks good to me. I think it has the right balance. We may want to
> >>create a matrix showing what is supported in the dispatcher and what is
> >>not supported. For example, one cannot generate PDF's with a dispatcher
> >>enabled site.
> >
> >
> > That is not true. Why do you think so?
> >
> > It is not possible to generate PDF in the dispatcher out of *xhtml2*
> > (like in general).
>
> I thought this because of [1]. Re-reading alongside your comment above I
> see I may have misunderstood.
>
> I see now that you say that PDF generation does ot work because the
> sample is an XHTML2 source file and we need XHTML2-to-FO, OK that is
> fine and is not a dispatcher issue but is part of the move to XHTML2.
>
> Can you confirm that if I use XDoc as a source in a dispatcher enabled
> site I will still be able to generate PDF?
I can confirm it, PDFs work fine.
>
> Are the broken links in the issue I reported [1] still a problem? That
> issue was closed but I never saw any commits to resolve it.
For that xhtml2_subset file yes still broken. Bit I don't think it an Issue
yet since xhtml2 is not yet being worked on.
Gav...
>
> Ross
>
> [1] http://issues.apache.org/jira/browse/FOR-863
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.5.1/328 - Release Date: 1/05/2006
Re: status of skins and dispatcher for 0.8 release
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 02-05-2006 a las 20:47 +0100, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El mar, 02-05-2006 a las 20:27 +0100, Ross Gardler escribió:
> >
> >>Ross Gardler wrote:
> >>
> >>>David Crossley wrote:
> >>
> >>...
> >>
> >>
> >>>>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.
> >>
> >>It looks good to me. I think it has the right balance. We may want to
> >>create a matrix showing what is supported in the dispatcher and what is
> >>not supported. For example, one cannot generate PDF's with a dispatcher
> >>enabled site.
> >
> >
> > That is not true. Why do you think so?
> >
> > It is not possible to generate PDF in the dispatcher out of *xhtml2*
> > (like in general).
>
> I thought this because of [1]. Re-reading alongside your comment above I
> see I may have misunderstood.
>
> I see now that you say that PDF generation does ot work because the
> sample is an XHTML2 source file and we need XHTML2-to-FO, OK that is
> fine and is not a dispatcher issue but is part of the move to XHTML2.
yes, thanks for clarifying.
>
> Can you confirm that if I use XDoc as a source in a dispatcher enabled
> site I will still be able to generate PDF?
yes, since the pdf generation is coming from the plugin.
>
> Are the broken links in the issue I reported [1] still a problem?
I do not find broken links in the issue. If you mean the redirect
to /index.* that was a quick workaround back in v3. The trunk does not
suffer this problem.
> That
> issue was closed but I never saw any commits to resolve it.
Hmm, how about
http://marc.theaimsgroup.com/?l=forrest-dev&m=114554635309074&w=2
"Comment by Thorsten Scherler [20/Apr/06 03:07 PM]
v3 is not up to date and will be deleted in the process of FOR-798.
Further http://localhost:8888/samples/xhtml2_subset.html is using xhtml2
as input and not xdocs. This means that the pdf will not work anyway
since we do not have a xhtml2-to-fo transformation established.
Another point is that the xhtml2 integration demonstrated in v3 needs to
be done in a different way like I described in a couple of threads on
dev (e.g. [RT] structurer location and resource types).
This issue will be actual when we base the dispatcher on xhtml2 as input
format."
...and the quick workaround for v3 based site is: un-comment the
links. ;) In the current dispatcher that is fixed.
Maybe we should change the description to "implement xhtml2-to-fo
transformation".
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: status of skins and dispatcher for 0.8 release
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El mar, 02-05-2006 a las 20:27 +0100, Ross Gardler escribió:
>
>>Ross Gardler wrote:
>>
>>>David Crossley wrote:
>>
>>...
>>
>>
>>>>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.
>>
>>It looks good to me. I think it has the right balance. We may want to
>>create a matrix showing what is supported in the dispatcher and what is
>>not supported. For example, one cannot generate PDF's with a dispatcher
>>enabled site.
>
>
> That is not true. Why do you think so?
>
> It is not possible to generate PDF in the dispatcher out of *xhtml2*
> (like in general).
I thought this because of [1]. Re-reading alongside your comment above I
see I may have misunderstood.
I see now that you say that PDF generation does ot work because the
sample is an XHTML2 source file and we need XHTML2-to-FO, OK that is
fine and is not a dispatcher issue but is part of the move to XHTML2.
Can you confirm that if I use XDoc as a source in a dispatcher enabled
site I will still be able to generate PDF?
Are the broken links in the issue I reported [1] still a problem? That
issue was closed but I never saw any commits to resolve it.
Ross
[1] http://issues.apache.org/jira/browse/FOR-863
Re: status of skins and dispatcher for 0.8 release
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 02-05-2006 a las 20:27 +0100, Ross Gardler escribió:
> Ross Gardler wrote:
> > David Crossley wrote:
>
> ...
>
> >> 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.
>
> It looks good to me. I think it has the right balance. We may want to
> create a matrix showing what is supported in the dispatcher and what is
> not supported. For example, one cannot generate PDF's with a dispatcher
> enabled site.
That is not true. Why do you think so?
It is not possible to generate PDF in the dispatcher out of *xhtml2*
(like in general).
> I'm not sure of the status of other plugins when used in
> conunction with dispatcher, would a matrix help in showing how
> "complete" the dispatche is?
>
> Ross
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: status of skins and dispatcher for 0.8 release
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
...
>> 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.
It looks good to me. I think it has the right balance. We may want to
create a matrix showing what is supported in the dispatcher and what is
not supported. For example, one cannot generate PDF's with a dispatcher
enabled site. I'm not sure of the status of other plugins when used in
conunction with dispatcher, would a matrix help in showing how
"complete" the dispatche is?
Ross
Re: status of skins and dispatcher for 0.8 release
Posted by Cyriaque Dupoirieux <Cy...@pcotech.fr>.
le 04/05/2006 06:36 David Crossley a écrit :
> 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.
>
Yes it's excellent,
>
>>> 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.
>
Perfect,
>
>> 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.
>
>
Ok,
>> 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 ;)
>>
>
>
Perfect,
> 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...
[SNIP]
I think the future forrest architecture starts to be clear in our mind
:-) !
Salutations,
Cyriaque,
>>
>> Thanks David.
>>
>> salu2
>> --
>> thorsten
>> "Together we stand, divided we fall!"
>> Hey you (Pink Floyd)
>>
>
>
>
Re: Plugin dependencies (Re: status of skins and dispatcher for 0.8
release)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> Ross Gardler wrote:
>
>
>>Just to be clear. The reason we decided (in the past) not to allow
>>plugins to have dependencies in this way is because it requires the user
>>to have a deep understanding of what plugins work with what other
>>plugins. Even worse, they need to know which versions of plugins will
>>play happily.
>
>
>>By requiring the user to know this we will end up with user support
>>questions, which in turn will result in us having to maintain
>>documentation, which in turn will get out of synch with the reality of
>>development, which will result in more user confusion.
>
>
>>So, my proposal is to document what plays with what in a feature
>>definition file as described in the previous email. We can generate
>>documentation from this file and it removes the need for the user to
>>worry about version numbers of plugins.
>
>
> This was really helpful because if made me go back and re-read you
> previous posting and really understand features.
>
> +1 for the concept
>
> How about naming them in a way that explains better what they are.
> Something like compound-plugin for example?
I really have no problem with any name. Features can be a little
misleading and did confuse me for a while in the Eclipse environment.
Ross
Re: Plugin dependencies (Re: status of skins and dispatcher for 0.8 release)
Posted by Ferdinand Soethe <fe...@apache.org>.
Ross Gardler wrote:
> Just to be clear. The reason we decided (in the past) not to allow
> plugins to have dependencies in this way is because it requires the user
> to have a deep understanding of what plugins work with what other
> plugins. Even worse, they need to know which versions of plugins will
> play happily.
> By requiring the user to know this we will end up with user support
> questions, which in turn will result in us having to maintain
> documentation, which in turn will get out of synch with the reality of
> development, which will result in more user confusion.
> So, my proposal is to document what plays with what in a feature
> definition file as described in the previous email. We can generate
> documentation from this file and it removes the need for the user to
> worry about version numbers of plugins.
This was really helpful because if made me go back and re-read you
previous posting and really understand features.
+1 for the concept
How about naming them in a way that explains better what they are.
Something like compound-plugin for example?
--
Ferdinand Soethe
Re: Plugin dependencies (Re: status of skins and dispatcher for 0.8
release)
Posted by Cyriaque Dupoirieux <Cy...@pcotech.fr>.
le 04/05/2006 16:24 Ross Gardler a écrit :
> Ross Gardler wrote:
>> Cyriaque Dupoirieux wrote:
>
> ...
>
>>> Projects can select their implementations :
>>> If a project specifies project.required.plugins=C, A, it's OK,
>>> If a project specifies project.required.plugins=C, B, it's OK too
>>> - but with a different behaviour or rendering,
>>
>>
>> There you go, you just wound up at the Eclipse definition of a Feature.
>
> Just to be clear. The reason we decided (in the past) not to allow
> plugins to have dependencies in this way is because it requires the
> user to have a deep understanding of what plugins work with what other
> plugins. Even worse, they need to know which versions of plugins will
> play happily.
>
> By requiring the user to know this we will end up with user support
> questions, which in turn will result in us having to maintain
> documentation, which in turn will get out of synch with the reality of
> development, which will result in more user confusion.
>
> So, my proposal is to document what plays with what in a feature
> definition file as described in the previous email. We can generate
> documentation from this file and it removes the need for the user to
> worry about version numbers of plugins.
Ok, I fully agree.
It's a very nice solution :-) .
Cyriaque,
PS : I wanted to see how rpm packages manage dependencies, but I have
not the time... I think it must be close to your solution...
>
> Ross
>
>
Re: Plugin dependencies (Re: status of skins and dispatcher for 0.8
release)
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Cyriaque Dupoirieux wrote:
...
>> Projects can select their implementations :
>> If a project specifies project.required.plugins=C, A, it's OK,
>> If a project specifies project.required.plugins=C, B, it's OK too -
>> but with a different behaviour or rendering,
>
>
> There you go, you just wound up at the Eclipse definition of a Feature.
Just to be clear. The reason we decided (in the past) not to allow
plugins to have dependencies in this way is because it requires the user
to have a deep understanding of what plugins work with what other
plugins. Even worse, they need to know which versions of plugins will
play happily.
By requiring the user to know this we will end up with user support
questions, which in turn will result in us having to maintain
documentation, which in turn will get out of synch with the reality of
development, which will result in more user confusion.
So, my proposal is to document what plays with what in a feature
definition file as described in the previous email. We can generate
documentation from this file and it removes the need for the user to
worry about version numbers of plugins.
Ross
Plugin dependencies (Re: status of skins and dispatcher for 0.8 release)
Posted by Ross Gardler <rg...@apache.org>.
Cyriaque Dupoirieux wrote:
> le 04/05/2006 09:06 Ross Gardler a écrit :
>
>> David Crossley wrote:
>>
>>> Thorsten Scherler wrote:
>>>
>
>> [SNIP]
>
>
>> Nice overlap with Ferdinands proposal for a clear development
>> proposal. Lets use this as a test case. I'll be proposing the Daisy
>> plugin too once I have enough time to document it a little better. We
>> can use both the Daisy and the Dispatcher/themer plugins as test cases.
>>
>> One thing that will have to happen before the Dispatcher comes out of
>> core is to resolve the plugin dependency issues.
>>
>> Some time ago we agreed that plugins should not have any dependencies
>> on one another. We also acknowledged that here may come a time in
>> which such a dependency is required. This may be it, but the plugin
>> architecture does not currently support dependencies. We need to
>> create the concept of "features" which are collections of plugins that
>> work together to achieve a specific goal.
>
> I think we need to specify the concept of "feature" for plugins and the
> notion of plugin dependency of "features".
Sorry, I'm using Eclipse terminology here. It is a little counter
intuitive. A feature is a collection of plugins that work together well.
So for example, a feature may be "convert ODT files to PDF". This would
require the ODT input plugin and the PDF output plugin. Or a feature may
be "provide a theming ability based that allows individual pages to be
given a different structure", this would be the Dispatcher internal
plugin and the themer plugin.
> Try to explain :
>
> * Plugin A implement the Feature 1
> * Plugin B also implement the feature 1
>
> * Plugin C depends on the feature 1
So, given the above definitions of feature a plugin does not implement a
feature. A feature is a set of plugins. Instead a plugin adds a unit of
functionality to the core of forrest, which can be used to create a
specific feature.
By doing this a plugin is not directly dependant on another plugin.
Instead a feature defines a collection of plugins that will work happily
together. This means that we can then have a feature that uses, for
example, the dispatcher plugin, but does not use the themer plugin,
instead it uses, for example, a hypothetical JXTemplates plugin for
themeing.
> For instance, Plugin C is the dispatcher and Plugins A and B two
> implementations of the core.theme
> So what ?
>
> Projects can select their implementations :
> If a project specifies project.required.plugins=C, A, it's OK,
> If a project specifies project.required.plugins=C, B, it's OK too -
> but with a different behaviour or rendering,
There you go, you just wound up at the Eclipse definition of a Feature.
In other words, I agree. We just need to define the terminology and
implement the ability to define a feature in forrest.properties. This is
really easy to do. It can be something like:
feature-def.xml:
<feature id="org.apache.forrest.feature.ODT2PDF">
<description>Enables the rendering of ODT documents as PDF
documents</description>
<version>0.1</version>
<minForrestVersion>0.8</minForrestVersion>
<plugins>
<plugin id="org.apache.forrest.plugin.input.ODT">
<version>0.1</version>
</plugin>
<plugin id="org.apache.forrest.plugin.output.PDF">
<version>0.2</version>
</plugin>
</plugins>
</feature>
forrest.properties:
requried.features=org.apache.forrest.feature.ODT2PDF
Version management just utilises the existing plugin version management.
However, we could have incompatabilities between plugin versions. For
example, two features may demand incompatible plugin versions. We will
need to check this at startup:
1. collect list of all requied plugins
2. look for clashing versions of plugins
3. warn user of potential probelems (if any exist)
4. install latest version of each requirted plugin
Thus if, for example, feature A requires plugin P-0.1 (version 0.1) and
feature B requires plugin P-0.2 (version 0.2). The user is warned as
follows:
"Feature A requires plugin P-0.1 whilst feature B requires P-0.2.
Forrest has installed the latest version (P-0.2). This may couse
unexpected results in Feature A."
If this looks OK then we should get this into an issue before we forget it.
Ross
Re: status of skins and dispatcher for 0.8 release
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> Cyriaque Dupoirieux wrote:
>
>
>>I think we need to specify the concept of "feature" for plugins and the
>>notion of plugin dependency of "features".
>>Try to explain :
>
>
>> * Plugin A implement the Feature 1
>> * Plugin B also implement the feature 1
>
>
>> * Plugin C depends on the feature 1
>
>
>>For instance, Plugin C is the dispatcher and Plugins A and B two
>>implementations of the core.theme
>>So what ?
>
>
>>Projects can select their implementations :
>> If a project specifies project.required.plugins=C, A, it's OK,
>> If a project specifies project.required.plugins=C, B, it's OK too -
>>but with a different behaviour or rendering,
>
>
> Perhaps it would be a good idea to have this important architectural
> discussion in a new thread?
We did:
http://marc.theaimsgroup.com/?l=forrest-dev&m=114675058628417&w=2
Ross
Re: status of skins and dispatcher for 0.8 release
Posted by Ferdinand Soethe <fe...@apache.org>.
Cyriaque Dupoirieux wrote:
> I think we need to specify the concept of "feature" for plugins and the
> notion of plugin dependency of "features".
> Try to explain :
> * Plugin A implement the Feature 1
> * Plugin B also implement the feature 1
> * Plugin C depends on the feature 1
> For instance, Plugin C is the dispatcher and Plugins A and B two
> implementations of the core.theme
> So what ?
> Projects can select their implementations :
> If a project specifies project.required.plugins=C, A, it's OK,
> If a project specifies project.required.plugins=C, B, it's OK too -
> but with a different behaviour or rendering,
Perhaps it would be a good idea to have this important architectural
discussion in a new thread?
--
Ferdinand Soethe
Re: status of skins and dispatcher for 0.8 release
Posted by Cyriaque Dupoirieux <Cy...@pcotech.fr>.
le 04/05/2006 09:06 Ross Gardler a écrit :
> David Crossley wrote:
>> Thorsten Scherler wrote:
>>
> [SNIP]
> Nice overlap with Ferdinands proposal for a clear development
> proposal. Lets use this as a test case. I'll be proposing the Daisy
> plugin too once I have enough time to document it a little better. We
> can use both the Daisy and the Dispatcher/themer plugins as test cases.
>
> One thing that will have to happen before the Dispatcher comes out of
> core is to resolve the plugin dependency issues.
>
> Some time ago we agreed that plugins should not have any dependencies
> on one another. We also acknowledged that here may come a time in
> which such a dependency is required. This may be it, but the plugin
> architecture does not currently support dependencies. We need to
> create the concept of "features" which are collections of plugins that
> work together to achieve a specific goal.
I think we need to specify the concept of "feature" for plugins and the
notion of plugin dependency of "features".
Try to explain :
* Plugin A implement the Feature 1
* Plugin B also implement the feature 1
* Plugin C depends on the feature 1
For instance, Plugin C is the dispatcher and Plugins A and B two
implementations of the core.theme
So what ?
Projects can select their implementations :
If a project specifies project.required.plugins=C, A, it's OK,
If a project specifies project.required.plugins=C, B, it's OK too -
but with a different behaviour or rendering,
Salutations,
Cyriaque,
>
> We can return to this after the 0.8 release though.
>
> Ross
>
>
Re: status of skins and dispatcher for 0.8 release
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> Ross Gardler wrote:
>
>
>>Nice overlap with Ferdinands proposal for a clear development proposal.
>>Lets use this as a test case. I'll be proposing the Daisy plugin too
>>once I have enough time to document it a little better. We can use both
>>the Daisy and the Dispatcher/themer plugins as test cases.
>
>
> +1
>
> As much as I appreciate lazy consensus, should we not call a vote on
> this to make people aware of this rather drastic change in our
> guidelines?
Once time has passed for discussion on your Proposal you should call a
vote to make that proposal part of our guidelines. Probably best to
leave it for at least a week since it is a very important discussion
that is rounding up many previous similar discussions. It will take
people time to consider the ramifications and find the time to respond.
Note that David linked your thread to an issue for tracking these
related items. Before voting we will need to ensure your proposal
includes everything said in the past.
(this should move back to your proposal thread now)
Ross
Ross
Re: status of skins and dispatcher for 0.8 release
Posted by Ferdinand Soethe <fe...@apache.org>.
Ross Gardler wrote:
> Nice overlap with Ferdinands proposal for a clear development proposal.
> Lets use this as a test case. I'll be proposing the Daisy plugin too
> once I have enough time to document it a little better. We can use both
> the Daisy and the Dispatcher/themer plugins as test cases.
+1
As much as I appreciate lazy consensus, should we not call a vote on
this to make people aware of this rather drastic change in our
guidelines?
--
Ferdinand Soethe
Re: status of skins and dispatcher for 0.8 release
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Thorsten Scherler wrote:
>
>>Ross Gardler escribi??:
>>
>>>Thorsten Scherler wrote:
>>>
>>>>Ross Gardler escribi??:
...
>>>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?
To be stable with respect to backward compatability it needs to have a
fixed grammar so that users need not change anything to keep up with any
internal changes in the code. A move to XHTML2 should not affect this as
it is an internal format and would not affect the source format or the
structurer grammar.
>>>>>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".
Agreed.
>>>>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.
Nice overlap with Ferdinands proposal for a clear development proposal.
Lets use this as a test case. I'll be proposing the Daisy plugin too
once I have enough time to document it a little better. We can use both
the Daisy and the Dispatcher/themer plugins as test cases.
One thing that will have to happen before the Dispatcher comes out of
core is to resolve the plugin dependency issues.
Some time ago we agreed that plugins should not have any dependencies on
one another. We also acknowledged that here may come a time in which
such a dependency is required. This may be it, but the plugin
architecture does not currently support dependencies. We need to create
the concept of "features" which are collections of plugins that work
together to achieve a specific goal.
We can return to this after the 0.8 release though.
Ross
Re: status of skins and dispatcher for 0.8 release
Posted by David Crossley <cr...@apache.org>.
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)
Re: status of skins and dispatcher for 0.8 release
Posted by Thorsten Scherler <th...@apache.org>.
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.
...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).
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 ;)
...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 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).
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* (!!!)
...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.
>
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"
> >
> >
> > 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).
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: status of skins and dispatcher for 0.8 release
Posted by Ross Gardler <rg...@apache.org>.
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
Re: status of skins and dispatcher for 0.8 release
Posted by Thorsten Scherler <th...@apache.org>.
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.
> 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? ;)
> 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).
...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.
> 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?
> > 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)
Re: status of skins and dispatcher for 0.8 release
Posted by Ross Gardler <rg...@apache.org>.
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. 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.
It is my understanding that this is scheduled to happen in the 0.9
release, by which time the dispatcher should be stable.
So, my questions are:
1) is my understanding correct?
2) is the dispatcher stable in its implementation? 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?
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 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.
Ross