forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: xhtml2 tonights update & questions
Date Fri, 09 Sep 2005 08:20:18 GMT
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

Mime
View raw message