Re: [scalawithsails-devl] Layout templating in SwS

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

>
> I'm currently noodling "page composition"... basically the right way  to 
> specify what components go on a page and then how they ordered  into the 
> resulting HTML (there's a CSS related issue here, but I'm  punting on that 
> for right now.)
>

The basic pattern I tend to go for to compose markup is a simplified xslt. 
Generate xml, then transform it using a decorator. This might be a good 
starting point conceptually.

e.g.
myxml =
  <decorate template="mytemplate">
    <content name="left-bit">/*generate left markup*/</content>
    <content name="right-bit">/*generate right markup*/</content>
  </decorate>

mytemplate =
    <html>
      <table><tr>
        <td><value-of select="content[name='left-bit']</td>
        <td><value-of select="content[name='right-bit']</td>
      </tr></table>
    </html>

In addition
1. myxml can explicitly include component markup,
e.g.
   <div><include component="mycomponent"></div>
2. decorators can be based on higher decorators
e.g.
  mytemplate =
    <decorate template="pagetemplate">
      <table><tr>
        <td><value-of select="content[name='left-bit']</td>
        <td><value-of select="content[name='right-bit']</td>
      </tr></table>
    </decorate>
3. decorate can appear anywhere in the markup. i.e. you can have a template 
to compose the whole screen, or you can have a template just to put a border 
around something

The nice thing about using Scala is that (hopefully) the transforming markup 
e.g. <value-of...>, <component..>,etc can be replaced with simpler non-xml 
syntax, e.g. {leftBit}, so the only markup left in the code is html

For a given view class, maybe we could mixin templates/components using 
traits? Anyhow, the idea is to use Scala's DSL flexibility to express these 
transforms to avoid the bulkiness of xsl

I guess the challenge here is to keep it really simple, so you can get in 
there and write code straightaway without frst having to configure x-billion 
xml files... would be nice to be able to get a simple page up and running 
(like the example Index class), then incrementally build components and 
decorators as a natural refactoring process in the Scala code.

As for how this fits in with other aspects of components, like a component's 
behaviour (handling ajax, the back button, Faces-style component lifecycle, 
etc) I don't know.

(Seems to me sometimes that a lot of ideas inspired by the genesis of xml 
(like xslt) got lost along the way in a sea of pointy brackets. Maybe the 
simplicity of Scala can be the cure)

> The moving parts in my mind are:
> - The components that exist on a page (e.g., the search box, the  menu, 
> the "main" part, etc.)
> - The order in which the components are laid out in the fully  rendered 
> HTML page
> - The "decoration" around each component (although the need for 
> decoration is lessened with CSS)
> - How the component is rendered for a partial page render (e.g., AJAX  or 
> Comet update)
>
> I don't know if there should be a meta-view and/or meta-controller 
> over-laid on the existing Rails-style controller/view paradigm.   Perhaps 
> this stuff should all just be infinitely layered so a view  can be a 
> meta-view of other views, etc. and using your paradigm,  you'd have a 
> bunch of decorators and content and the "output" of one  could be piped 
> into another.
>
> Sound reasonable?

I definitely like the idea of infinitely layered views. That's something I 
know will save me effort.

As for the controllers.. the controller:
a) responds to the request by changing the model (updates db, etc)
b) selects the view,  generates data for the view, forwards to the view.

(a) doesn't need to be layered.. it just corresponds to an action (e.g. 
deleteitem?id=4), but (b) does need a sense of the layering of the view it 
calls.

So I don't know whether the controllers need to be layered as such, for this 
issue at least, altho that might be the best way to achieve (b).

Perhaps each view/decorator could define its own default data generator, 
that could optionally modified by the controller? So, for a listbooks view 
decorated with pagetemplate, the listbooks controller would generate the 
list of books, whereas the controller would delegate to pagetemplate's own 
default generator to get standard header data like the number of books sold 
today, etc.

Haven't other systems addressed the issue of layered pages in MVC before?