heres an outline of what I normally do these days..
------------------
dynamic page <[code-init]>
mgd_include_smippet("mysite/stdpage.class");
$page = new stdpage($argv);
----------------
navigation style element -- or this could just be the body of a large
stylesheet.
<[navbar]>
<? $page->show_navbar() ?>
--------------------
in snippet stdpage.class
class stdpage {
var $content;
var $navbar_items; // (
function stdpage($argv) {
... do some lookups and set up the content vars
}
function show_navbar() {
foreach ($this->navbar_items as $topic) {
?><[navbar_item]><?
}
}
}
------------------
the navbar item <[navbar_item]>
<a href=&(this.mgdroot);/&(topic.name:u);/">&(topic.extra) </a><br>
--------------------
Other tricks that can be done using this technique:
<[ROOT]>
<? mgd_eval("?".">".mgd_template($page->template) . "<"."?"); ?>
to use different templates for the same page....
thats a simple example of the theory that is used in a number of projects.
-- if the navbar does not change on most pages, I just stick it in a
sessoin var so that it is not loaded each time.
This keeps the general concept of seperating code and layout - note that
midgards templating engine is not a 'complete engine' however it
acknowledges that
php itself was originally supposed to be a template system - it just
grew into a programming language :)
so putting some limited php into style elements is a handy trick.
the use of classes obviously has a number of advantages here
- code reuse - if you have similar page trees you could extend the same
class
- security - since there is only 1 global variable '$page' which is
always declared.. - you would not suffer from the global variable leak.
- maintance (or clarity of management) - code changes will be in 1
location, design changes in another.....
regards
alan
Pascal Van Hecke wrote:
>>The common sense says it must go in a style element
>>or in an overridden page
>>element if one is to reach the economy factor that a
>>CMS is supposed to
>>offer.
>>
>
>sure!
>
>
>>Based on the above style organisation, what if one
>>would like those
>>navigation elements to grow or shrink as one is
>>adding new pages and/or
>>topics/articles. Then, this style would have to be
>>dynamic, therefore
>>should contain "code" to retrieve all the subtopics
>>(for example) or all the
>>pages (for example) under a hat topic or page. My
>>point is that "no code
>>should be put in style or page elements" in order to
>>separate logic and
>>presentation. My question is : how can we have at
>>the same time relatively
>>static styles that contain a small amount of logic
>>to scan directories and
>>be updated as new section are added or subtracted?
>>
>
>I think I just do not agree when you say that
>"separating logic and presentation" implies "no code
>should be put in style or page elements". It's not
>because you use code to dynamically build a navigation
>bar, that it's not part of the presentation. Call it
>"presentation logic" :-) to distinguish it from the
>"application logic" specific for a page, containing
>for example some form processing code. However,
>you're right this is a very thin line: the code in
>pages often does nothing more than displaying article
>titles or contents in some way or another, so where's
>the difference with a style element building a dynamic
>navigation bar based on the topic hierarchy?
>I think the rule of thumb here is: code specific to
>one URL (with or without parameters) belongs in a
>page, common cross-page code belongs in a style (think
>I'm repeating myself?).
>But then, it is still advisable to separate code from
>"layout elements" (hehe, this way avoiding the word
>presentation) by isolating them in several page/style
>elements or snippets, and/or by using a CSS.
>
>pascal
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Sports - Coverage of the 2002 Olympic Games
>http://sports.yahoo.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
