forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Williams" <>
Subject Re: WM2006 - New internal format for the dispatcher
Date Sun, 02 Jul 2006 23:43:15 GMT
On 7/2/06, Thorsten Scherler <> wrote:
> El vie, 30-06-2006 a las 08:06 -0400, Tim Williams escribió:
> > On 6/28/06, Thorsten Scherler <> wrote:
> ...
> > So these "internal" formats act essentially like input plugins except
> > the output isn't necessarily an xdoc?
> Not all of them.
> For the *.internal, yes internal plugins produce xdocs so should the
> internal contracts.
> ...on the other hand we have other internal contracts in skins which do
> not produce xdocs. book-to-menu.xsl and tab-to-menu.xsl this produces
> internal markup used for generating the navigation contracts.

Right, I think we're saying the same thing here (e.g. variable input->
variable output).

> > Either way, I don't see how
> > modularizing content could be a bad thing, go for it.
> >
> :)
> > I think that it doesn't "feel right" might be because you're naming
> > them generic "internal1", "internal2", etc.  Other view/@types are
> > format-specific (e.g. html), right?  Why not stick with something like
> > that?
> >
> Actual internal is treated as "format". You can reach it via requesting
> *.internal instead of *.html.
> Picking up the *-to-menu.xsl they should go into internal-navigation and
> be reachable via *.internal-navigation. This way skins and the
> dispatcher can reach the same output without code-duplication. Further
> this allows the user to quickly change the navigation without
> duplicating the whole skin code.

Sounds good.  I've obviously missed a decision somewhere, but I
thought dispatcher is still on the road to skin-replacement rather
than living together.  In other words, what you describe sounds good
but not necessarily for the reasons you describe it.

> > On the other hand, it seems that this is a slightly different use of
> > views (e.g. variable input and output), so a more difficult solution
> > might be to extend the views grammar to accept a view
> > type="conversion" with from/to attrs or something.
> >
> Can you elaborate on this? I do not understand the type="conversion"
> part.

This maybe a misunderstanding on my part but....

Our dispatcher currently has @type="XYZ", wherein the input of the
view is expected to be xdoc and the "@type" value is the output.  So,
if we have a new type that explicitly declares the input/output, then
it seems to me we would gain more reusability/content modularity -
enabling, for example, a one to ask for a conversion/transform from
XYZ->ABC (e.g. xdoc->xhtml2) generically.

But then again... I'm still just thinking off the top of my head and
could be missing what you're saying so take all my comments with a
grain of  sand...


View raw message