binarycloud-dev

[binarycloud-dev] Page class status

[Alex B. <en...@tu...>]

hi all,

I have a functioning Page class, which (though it's a little, uh, dense at
the moment) works just fine.

It includes modules, and executed Init() and Output() for each module within
each module group in the correct order.

It appends the output of each module to:

$this->output[group_name]

so...

next thing up is actually to build TemplateManager so I can do master
templates and layouts in XSLT.

I could be lazy and just make a shell templatemanager that includes files,
but egh :)

---
So, on the list of core classes:
    Init (done, cooked)
    Page (baking, but you can smell it in the living room)
    Auth (kneading the dough)
    Perm (ditto)
    DB  (ah, thanks manuel)
    Err (need to putz with PEAR_Error to see if it jives)
    Lang (this is simple, and will come last)
    Sess (done)
    Request (done, but needs poking and prodding before going into CVS)

soon! soon!

_alex





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

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

vox+510.666.0074
fax+510.666.0093

[binarycloud-dev] Yet _more_ Page class status

[Alex B. <en...@tu...>]

> next thing up is actually to build TemplateManager so I can do master
> templates and layouts in XSLT.

I got here and realized that was in-a-coding-stupor talk, and that's bull.

master templates, and module layouts, are normal php-in-html for a number of
reasons, not least of which we'd have to generate a huge amount of xml for
every page render, only to be hurt by using xsl.

anyway,

I have a completely functional Page class in cvs. The entire page render
pipeline is functional, I even have the ability to dynamically switch a
template based on a call to the name of the template in request_uri.
(woohoo!).

...

for those of you not familiar with the idea of layouts, it goes like this:

in r1, I had this itch, like sometimes I wanted to have a little bit of
extra fluff/formatting html in a particular page that I didn't necessarily
want to associate with a module.

so, layouts were born in r2, and they solve the only
production/implementation flaw with core_template: no "extra page specific
layout code"

quite convenient, and you can do nearly anything in a layout, cuz it's php.
:)

...

some of the methods in Page are a little dense for my taste, although anyone
can gain a cursory understanding of the class by reading Page::BuildPage

Where possible, I will attempt to simplify the methods, but then again no
one will need to putz with (or even know much about) this code so long as
they are aware of how it acts under varying conditions.

some examples:
    -you can entirely omit the $bc_page[templates] array (you don't have to
have a master template.. if you don't the module groups will just be printed
in sequence.
    -you can change the load order of module::Init methods, just as in r1.
    -etc.

this will all be documented.

time for sleep.

_a


an update:
>   Init (done, cooked)
>   Page (done, cooked)
>   Auth (kneading the dough)
>   Perm (ditto)
>   DB  (ah, thanks manuel)
>   Err (need to putz with PEAR_Error to see if it jives)
>   Lang (this is simple, and will come last)
>   Sess (done)
>   Request (done, but needs poking and prodding before going into CVS)
> 
> soon(er!)! soon(er!)!


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

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

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] Yet _more_ Page class status

[Nico G. <sc...@ac...>]

--* Alex Black (Tue, May 22, 2001 at 12:11:06AM -0700) *--

> master templates, and module layouts, are normal php-in-html for a numb=
er of
> reasons, not least of which we'd have to generate a huge amount of xml =
for
> every page render, only to be hurt by using xsl.
>
> some examples:
>     -you can entirely omit the $bc_page[templates] array (you don't hav=
e to
> have a master template.. if you don't the module groups will just be pr=
inted
> in sequence.

what i was wondering, if we're always trying to separate code and
layout, how come we have a 'hello world' module that echo()'s a content?

ok i agree, it's an example module, so echo()'ing stuff is it's job (as
in the "hello world" module definition), but shouldn't be the table
layout defined in this module be somewhere else?

or am i missing the point once again?

--nicolas


--
nico galoppo   -   tremelo/leuven, belgium
               -   erasmus/socrates student in grenoble, france
               -   4, rue b=E9ranger -- phone: +33-(0)76-85 23 19
---------------------------------------------------------------
[bash]:~$ man woman                 nico at crossbar dot net
No manual entry for woman           debian linux :: vim powered

Re: [binarycloud-dev] Yet _more_ Page class status

[Alex B. <en...@tu...>]

> what i was wondering, if we're always trying to separate code and
> layout, how come we have a 'hello world' module that echo()'s a content?

because it takes three seconds to build, will never change, and doesn't need
to language or presentation independent.

I wanted something about as simple as possible, and I think that fits the
bill.

> ok i agree, it's an example module, so echo()'ing stuff is it's job (as
> in the "hello world" module definition), but shouldn't be the table
> layout defined in this module be somewhere else?
> 
> or am i missing the point once again?

sorta, but maybe this is a good point and I shouldn't put the idea in
people's heads :)

_alex


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

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

vox+510.666.0074
fax+510.666.0093