David Crossley wrote:
Tim Williams wrote:
David Crossley wrote:
Tim Williams wrote:
I think I grasped the TR. I didn't grasp that the scope of the
current effort was implementing the entire TR. I thought we were only
focused on the first part -- using XTHML2 as our source. I just
didn't pick up on that earlier for some reason.
We are focussing on the first part, but that also involves
all the rest because we need new core pipelines.
My statement needs qualifying. We need to attend to
XHTML2 everywhere at least up to Step 4.
All that we managed to achieve on ForrestTuesday was
to get a basic xhtml2 source file generated, together
with a stylesheet to transform straight to html4 so
that we could see what we were dealing with.
Leaving that aside, we then started to explore Step 1
"Resolving the location of content" and detecting the
source type. That involves views and locationmap,
so we grabbed the code and copied it over. Perhaps we
should not have, but we needed some code to start with.
I think we achieved much more than that.
Since views are going into core, they must use XHTML2 both as their
input and their output. In the XHTML2 plugin we have a version of views
that allows for the refactoring of all the contracts to work with XHTML2
as an input and as an output.
In other words we have the basic grounding to do the full move to XHTML2
The XHTML2_to_html stylesheet is the final rendering stage. This will go
into an HTML output plugin. Then we need an XHTML2_to_FO plugin and that
will go into a FO output plugin, which in turn can be used by a PDF or
RTF or PS plugin (yes I have a solution in mind to allow plugins to
inherit from other plugins thus solving the dependency problem in
plugins - that is for another time).
Just chucking all the views code in like that may not be the best way of
doing things, but what we have done by using this approach is to get to
a point where we can see stuff happening.
So i think that we are still focussed on Step 1
and ocassionally peeking to see where else XHTML2
will have effect.
Step 1 is what I meant when I suggested refactoring views to use the
locationmap and why I agreed with Nicola right at the start of
ForrestTuesday about doing a rewrite of the core sitemaps.
Technically, these are two separate issues. I'm cool with it either
way but I just want to make note about what we really *need* to do vs.
what we're making a concious choice to do.
Yes, otherwise it is too easy to get carried away.
In order to use XHTML2
with views (or for the existing skins for that matter) we need a
transform (e.g. document2html) and a mod to the *.page pipeline that
calls that transform instead of the existing **body-*.html pipe (w/
some other small tweaks here and there). This new stylesheet and the
new pipe would still be re-used even in our new concept of views -- so
it wouldn't be throw-away as far as I can tell.
No the idea of aggregating content in the sitemap must be removed. It is
views that define the structure of the page, not the sitemap. See the
thread on defining views terminology and the audio from the Views
workshop at Apachecon (in our events SVN)
Let me be sure that we are talking about the same things ...
1) when we detect xhmtl2 as the source, then it is
directly injested.
Yes, although we will still need to pass through a transformation to
ensure there are no elements we don't handle. We may find that this
needs to go into an input plugin too, but first step will be direct
injection.
2) when we detect some other source format then its
input plugin will transform to xhtml2 (e.g. the
Apache document-v* formats). Even html and xhtml1
could be input plugins, though the TR document
has them happening in the core.
The TR needs to change then. The only thing that should be in core is XHTML2
3) Step 3 Filtering adds more xhtml2 content to
the overall structure.
Now at what stage does our process transform from
the internal xhtml2 to some presentation format,
for example HTML4. The current TR document shows
that Step 4 is that point.
I interpret it like that too. Step 4 is the output plugins stage, i.e.
transformation to the final rendering language.
This step is misleading in the TR because it is called "viewing" it has
nothing to do with viewing (that is step 3). Perhaps we should change
the title of this stage to "Translation".
I am confused by the abovementioned document2html.
Wouldn't we still be dealing with xhtml2 at this stage?
Or are you talking about somewhere at or after Step 4.
document2html will be thrown away, we do not need it in XHTML2 (actually
we will use it as the start of our XDoc to XHTML2 input plugin). To be
clear, if we have an XDoc as a source the pipeline will be:
XDoc Src (step 1) ->
XDoc input plugin (step 2) ->
Filtering, as provided by the structurer (step 3) ->
Translation, as provided by output plugins (step 4) ->
Themeing (step 5) -->
Serialisation (step 6)
Now, if we request an html version then step 4 will use the html plugin
and step 5 will be CSS. If we request PDF, for example, then step 4 will
be the FO plugin and step 5 will be the PDF plugin.
[OT] I wonder if we should provide the CSS generation in a separate
output plugin? I think so, this will be the themeing part of views and I
think that this identifies where that illusive "theme" plugin fits.
I'm still catching up on Thorsten's long email the other day about
views, dispatcher, etc so I'm not sure what the implication is quite
yet, but he's now thinking java for some and jxtemplates for the
structurer. So, views is also somewhat of a moving target. That
being the case, it's probably important that we explicitly recognize
that this will be the location for future view development from now on
vs. view/viewHelper.
That is very important.
+1, but first we have to get the XHTML2 stuff to the same level of
functionality. This is not a large job I don't think.
If we *want* to take it all on now, that's fine, I just didn't "get"
that for some reason.
I see that all aspects are entwined and it is hard
to know where to start and what to do next.
+1
I wonder
if we could do another collaborative work day soon.
and take on the whole job.
+1
Lesson learnt from this Forrest Tuesday.
We need to have more design discussion leading up to the day. It is
clear that a number of us had different ideas about the approach we were
going to take.
Ross
