forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [Proposal] Design meeting focus
Date Sun, 18 Sep 2005 17:15:15 GMT
El dom, 18-09-2005 a las 09:25 +1000, David Crossley escribió: 
> Tim Williams wrote:
> > David Crossley wrote:
> > > 
> > > The original topic was how to implement
> > > views/xhtml2/internals. I reckon that they
> > > are all entwined. 
> > 
> > I've said it before and I'll say it again, they aren't necessarily,
> > and I mean *technically*, entwined.  I've tried, and apparently
> > failed, in several emails to describe in technical terms why they are
> > not entwined, but it's essentially for how Thorsten says, "views *are*
> > *just* replacing site2xhtml.xsl of leather-dev".  If we view the
> > resultant html of document2html as an Interface (in oo terms), then
> > that's what views are programmed to and that's why they aren't
> > entwined.
> 
> Thanks to that paragraph i now understand heaps more
> about views. I was seeing views as covering many,
> if not all, of the steps in xdocs/TR/2005/WD-forrest10.html 
> Glad it is more confined. That means we can do things
> in stages.
> 

Tim are right for the current implementation. 

I have a version of views of on my laptop (which is currently
broken :( and which I have to fix till tonight) where I started to
change that. Actually that is only half truth. The design on the code, I
still need to check in, is what I said a refactored version of views
should look like
(http://marc.theaimsgroup.com/?l=forrest-dev&m=112616664615538&w=2).

I as well got rid of the leather-dev dependency by copy and paste the
leather-dev and common skin xslt into the internal.view plugin. Now this
pipes/xslt have to be slimed down because half of them are not needed
IMO. Further the refactoring should be done with where possible
contracts and not with yass (yet another stylesheet). That forces us to
look in the existing xsl and design them as contracts will get rid of
overhead code.

There is a change of paradigma in the dispatcher part. 
<map:match pattern="**.model.xml"> 
  <map:generate src="{lm:{0}}"/>
  <map:serialize type="xml"/>
<map:match/>

Everything have to be requested through the views nuggets 
(aka prepare-view-nugget.{1}). 
That is the dispatcher or filter of the processing pipeline. 
e.g. tab-* or menu-* is now requested as *.navigation.xml by 
a contract and is not included in the default pm. Actually there
is no default pm anymore. You get what your view requests!

                                                       theme
                                                          |
                                                         \|/
core (views) -> output plugin (views can bypass them) -> output
   |   /|\
  \|/   |
+------------------+    +-----------------+
|forrest:contracts |--->|  input plugin   |
|forrest:properties|<---|src (+navigation)|
+------------------+    +-----------------+




> > If we want to entwine them as a dev-decision, then that is obviously a
> > different story.  I just want to be clear that technically, it is not
> > [in the current views implementation] entwined.  I sincerely hope that
> > Thorsten will correct me if I've mis-spoke here.
> 
> I am trying to ensure that if views do have any
> requirements regarding xhtml2, then these are
> defined as early as possible. If there are not,
> then great, it makes the job simpler.

The xhtml2 move means that the contracts are not getting xml but xhtml2
as entrance format. That is basically it. ...but having said that raises
the question where we want to apply xhtml2? Should the tab-* and menu-*
as well output xhtml2? If so that means we have to refactor this pipes
and their stylesheets. How we should do it and whether we should first
move views to core and then using them to enable xhtml2 (refactoring the
core) should be one big point in our discussion in 3 hours.

salu2


Mime
View raw message