Thorsten Scherler wrote:
On Wed, 2005-07-13 at 10:33 +0100, Ross Gardler wrote:
As suggested by Ferdinand I am just dumping some ideas I have in my mind
about the future of views.
I've not really considered these in detail, so they could be full of
holes, I'm just hoping to seed a few ideas to explore them at the views
workshop/hackathon if time permits.
We have to start using the view specific naming for e.g. templates
otherwise we will not understand each other very well.
Yes, and this should be another outcome form our views workshop. I am
thoroughly confused by the many names in use within views. I feel sure
many are not needed. For example, in this mail you introduce, for the
first time, the definition of *.vt as "view tiles". These files are
templates. They have the same syntax as other templates why give them a
diffferent name?
<xsl:cal-template ...>, for example, does not call a complete different
type of template. why should <forrest:call-temlate>
Then we have contracts, which are acrtually defined in *.ft
(forrest-templates), but the syntax of their language is
<forrest:tempalte>. It is thoroughly confusing, and I believe totally
unnecessa/ Lets pick a few simple terms to refer to simple concepts and
stick with them.
(if there is a nedd for different terminology convince us (me?) in
Stuttgart after we have a solid grounding, it will be much easier for
you I am sure)
...
I would like to see a new type of plugin that is a single template.
about which templates do you talk about? About forrest:contract (*.ft)
or (*.vt)? Or forrest:views (*.fv)?
Here is a perfect example of why we need clear, unambiguos names. I was
referring to *.ft (forret-template) *.fv is a view so I don't understand
why it is even a possability here.
As for *.vt this is something that was introduced a couple of days ago.
I am not sure why *.vt even needs to exist as a separate extension
(think <xsl:template match=""> and <xsl:template name=""/>) and so did
not think about it when writing the above sentence.
Do you mean adding all contracts that we extracted (like
content-feeder.ft) again into one single template?
No. I mean making all contracts (i.e. *.ft = forrest-templates)
availablew as separate units of functionlaity rather than bundling them
up within a view plugin that prevents their easy reuse across different
views (*.fv)
However...
Like I will implement soon in our viewHelper.xhmtl. We will have
default.fv and pelt.fv (as soon as we created it) ;-) which are two
different skins sharing the same contracts.
OK, this is very similar to what I am proposing, but it is a different
approach. I think there is merit in both approaches so we need to
discuss these in Stuttgart. I won;t try and do it now as I am starting
my travels tomorrow so I won;t be able to follow up.
Just as a teaser for my thinking avout my alternative approach. It has
the advantage of allowing the reuse of contracts across different
formatsm, which you approach does not (unless you create dependencies
between views plugins). For example, Hanax needs to reuse most of the
XHTML view in his voiceML view.
org.apache.forrest.output.Pelt
org.apache.forrest.output.Leather
etc.
You are using skin names here.
No, the idea should be to have skins *in* the view plugin.
Only in your implementation. Like I say, I see merit in both approaches.
We can discuss in Stuttgart and come up with a proposal fot the list
from that. Chances are we will take the best of both approaches.
---
Currently we have output plugins that do things like create the various
output documents. Are vew going to replace these plugins? Thinking about
the list of output plugins we currently have I see none that cannot be
replaced by a view. However, Imagine a use case in which we have an
output plugin that is designed to upload the page to a server when it is
generated.
Do we need a new view plugin or should we reuse the existing output
plugin namespace?
org.apache.forrest.plugin.output.viewHelper.{format}
The main different I see is that output plugins 'normally' just do a
document2{format} transformation. A view plugin is using this as one
part.
It is the use of 'normally' that makes me think there may be a need for
a different type of plugin. This is a point for discussion. I am totally
undecided at present.
------------------------------------------------------------------------
Moving into Core
================
We need to think carefully about when to do this. The Locationmap work
is going to rewrite most of the *.xmap files in core and the Views work
will touch many of these files too.
We should consider the implications of these changes and decide which to
do first.
I think the locationmap and view should be coordinated and happen to the
*same* time.
Again lets discuss. I am not at all sure this is possible. There are
simply to many overlapping changes. However, without a roadmap for views
(and I suppose this portion of the locationmap work too), it is
impossible to decide.
All we need is good coordination and communication. ;-)
Starting with a plan from Stuttgart followed by a review onlist from
other devs - this looks like excellent timing.
------------------------------------------------------------------------
Portals
=======
<snip what="agreement on 'we need to understand more about portals"/>
At the very least I would like to consider the ability for individual
users to customise their views.
What do you mean?
I mean the user eing able to turn on/off contracts in their view. Kind
of like a user choosing to view a web page with their own CSS rather
than that provided by the webiste designer. Or, to stick with the portal
theme, the user being able to turn on/off some of the portlets.
Clearly this is only approproate in a dynamic envirnment.
We are not going to have time for everything. This "portals" stuff is
future wish list stuff. I'll be attending the portals presentations at
Apachecon, but they are after the workshop. I think the immediate work
needs to be on getting views complete for 0.8. Portals (if they ever
emerge) will come after that.
Ross
