Re: [binarycloud-dev] Er, Decoration Layout Facility

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

> I would like a facility in BC that allowed multiple layouts
> per group.  The reason for this is the felt need to have
> some "standard" layouts that are quite common.  Just to
> give an example, there may be a site that in the "main pane"
> (not the master template scope) there is a need for a
> standard piece of HTML decoration, text or whatever, such
> as maybe a copyright notice, a set of links, a mailto: to
> the webmaster or whatever.
> 
> Logically, something like the below would be necessary,
> namely you need anoth'layout' => array(
>       'one'   => array(
>               'name' => "example",
>               'package' => "html.layouts",
>               ),
>       'two'   => array(
>               'name' => "copyright",
>               'package' => "html.layouts",
>               ),
>       'three' => array(
>               'name' => "webmaster",
>               'package' => "html.layouts",
>               ),
>       ),

ola:

well, you're going to have the ability to have modules directly embedded in
master templates.

layouts are really intended to "catch" those extra bits of html that you
don't necessarily want to include in a module (say a paragraph break between
modules, or a specific table layout, etc)

The "default modules" thing is something I'm working on right after the PEAR
integration, actually.

I was thinking of this syntax, actually:

<html>
<p> Other crap in a template </p>
<bc:module id="moo" name="HelloWorld" package="hello_world">
    <params>
        <attribute>value</attribute>
        <attribute>value</attribute>
        <attribute>value</attribute>
        <attribute>value</attribute>
    </params>
</bc:module>
</html>

gets translated into:

<?php $Page->OutputModule(array('id' => 'moo','name' =>
'HelloWorld','package' => 'hello_world','params' => array('attribute' =>
'value','attribute' => 'value','attribute' => 'value','attribute' =>
'value'))); ?>

at make time.

Note that the <?$Page->OutputModule(stuff)?> syntax will work in _any_
template, so theoretically you could have a module that includes a template
that outputs another module and some extra stuff. The possibilities are of
course infinite, system design is up to the user.

Also note that $Page->OutputModule doesn't exist yet and I may change the
name :)

I would prefer to use xslt for the above translation, but that would require
that all templates are valid xml documents, which could be a real pain in
the a** to support (single root elements not least among those problems). It
will probably be just a boring grep, as I really don't want to lock people
into using xhtml for _everything_.

> er array level, viz:
> 
> 'layout' => array(
>       'one'   => array(
>               'name' => "example",
>               'package' => "html.layouts",
>               ),
>       'two'   => array(
>               'name' => "copyright",
>               'package' => "html.layouts",
>               ),
>       'three' => array(
>               'name' => "webmaster",
>               'package' => "html.layouts",
>               ),
>       ),
> 
> and the example layout may have the buffer output, but
> the "copyright" and "webmaster" layouts are just
> very common bits of HTML and have no Output()
> stuff at all....

I'm not really opposed in theory to doing that, but at the same time I
_love_ that the page class is so clean and simple. As much as I can preserve
clarity and simplicity in that class, I'd like to.

The system as it stands is quite flexible, I think you'll be able to do that
stuff without a problem as soon as I get "embedded" module support up for
layouts and master templates. (and for that matter, anywhere)

> Right now, if you have standard header_like_things and
> footer_like_things in various groups, you must make a
> single layout for that group with all the bits and pieces
> necessary, even though these bits and pieces make up
> a set.

Yes, that's kludegeware, default modules will solve all those problems.

> Anyway, I won't try and justify this.  I feel this need,
> and I suppose that I would like for the rest of the group
> to comment on it.

I see it as well, but I think all the above will probably solve your problem
as soon as it's ready...

_alex

--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093