Hi Andrey,
> I've been programming with PHP for quite a long time now and used to
> separate PHP code and HTML. I just put HTML into defferent .ihtml
> files and load them as needed using the PHPLib's Template class. Now,
> as I'm trying to develope with Midgard, the next problem arises:
>
> Suppose, I want to include a page switcher into the News page
> (something like "Page: [1] [2] [3] [4] [5]"). Without Midgard, I then
define
> the following three .ihtml templates:
>
> pager.ihtml:
> <p class="pager">
> Page:
> {PAGES}
> </p>
>
> pager.item.cur.ihtml:
> <span class="pagercuritem">{PAGE}</span>
>
> pager.item.ihtml:
> <span class="pageritem"><a href="{URL}page={PAGE}">{PAGE}</a></span>
>
> Then I construct some Pager class that I feed the URL and the number
> of pages to. The following line then goes into my PHP code:
>
> $pager = new Pager("http://blah-blah-blah?action=news&";, 5);
> $pager->output();
>
> So, the question is: how do I implement the same functionality with
> Midgard?
>
> I suppose I could put my code into a snippet and then call it later on
> the page. But how do I define and access the templates withing the
> snippet code then?
There has been a similar thread on how to separate presentation from logic:
see http://marc.theaimsgroup.com/?t=101396736900001&r=1&w=2
Styles relate to templates a bit the same way as the "html-mode" relates to
the "php-mode" way of coding pages. (there's more to say than that, but let
me explain first).
With html-mode I mean that you write an html page in which you embed some
php, whereas with php-mode I mean a php page that executes and calls or
includes html chunks from the file server.
The latter way of working is most of the time preferred, because it allows
you to separate presentation and logic better, by, e.g. reusing template
files with placeholders on different pages in the site. You can describe it
also as: working inside-out, this is, writing code to produce the specific
dynamic pieces, and then calling a template where you substitute the
placeholders with the results your code just produced from get, post,
cookies and from database.
Comes in Midgard. Midgard starts by processing the ROOT style-element of
the Style connected to a page. In a Style, you typically put stuff (html,
php) that is common over several pages. Page-specific html or code, you put
in the content field of the page, or in page-elements. You have to call
this <[content]> or <[page-element]> from within your style, the same way
you're calling style-elements, so here we're working "outside-in": you start
with the global template, and the global template calls elements that are
more specific, so we might have as ROOT Style for a page:
<html>
<head>
<title>
<(title)>
</title>
<[se_vfb_css]>
</head>
<body link="#004080" vlink="#356A9F" alink="#0000FF" <[se_vfb_javascript]>
>
<(se_vfb_maintable)>
</body>
</html>
(actually this root style element can contain php as well, but I'll come
back on that)
<[se_vfb_css]>, <[se_vfb_javascript]> , <(se_vfb_maintable)> are style
elements you have to fill in, <(title)> refers to a property of the page.
<(se_vfb_maintable)> could then be something like:
<table>
<tr>
<td >
<[se_vfb_navi]>
</td>
<td >
<[content]>
</td>
<td >
<[se_vfb_right]>
</td>
</tr>
</table>
Let's bring in some code and assume <[se_vfb_navi]> has to display the pager
you described. If you wanna do it the classic Midgard way, you'd have to
make the <[se_vfb_navi]> style element contain :
<?php
$url = "http://blah-blah-blah/news/";;
$pages_to_display = 5;
?>
<p class="pager">Page: <[PAGES]> </p>
this assuming http://blah-blah-blah/ is an active page that takes "news" and
"3" as argv[0], argv[1] values when is encounters a request for
http://blah-blah-blah/news/3.html ! You can than use these values in
"content" to pull the right information from a database or from a Midgard
Topic tree. ( I have to assign the parameters you passed to variables, see
(4) in my conclusions at the end)
We continue working further "outside-in" by defining <[PAGES]> as:
<?php
for ($counter = 1, $counter <= $pages_to_display, $counter++)
{
if ($counter == argv[1]) {?> <[PAGE_CUR_ITEM]> <? }
else {?> <[PAGE_ITEM]> <? }
}
with the two last style elements respectively equal to:
<span class="pagercuritem"><?php echo $counter; ?></span>
<span class="pageritem"><a href="<?php echo $url.$counter; ?>.html"><?php
echo $counter; ?></a></span>
If I were to elaborate on your example to the extreme, I'd have to create
style-elements here to replace the pieces <?php ... ?>, but that seems a bit
overdone...
In fact this illustrates the third of the points I'll be making:
1 In the templating system you described, you're writing the code (in this
pager class) for the process that glues together the global and partial
templates with dynamic data. With Midgard, you do not have to write code
for this anymore, since the Midgard system works like an onion: the outer
template (Root style element) fetches automatically the placeholders (style
and page elements) and includes their content. This works recursively, so
you can delegate the rendering of your page to smaller and smaller
page/style elements, one contained in the other.
2 Because the templating system works automatically, and it uses a nice
inheritance system
http://www.midgard-project.org/manual/en/part.concepts.pagestyle.php#AEN454
, the process of refining styles , by overriding style elements in inherited
(child) styles, splitting them up in even smaller adjustable fragments,
stays manageable. You only have to concentrate in a child style (or in a
child page, if it's about page elements!) on those things are different from
the parent, from which it inherits the rest. Most php templating mechanism
are flat (they don't have templates in templates) and a refined variant of
the template requires changes in the calling php code, thus duplicating the
calling script. Not so with Midgard, and Midgard has the further advantage
that you can also override pieces of the logic because the page and style
elements can contain php as well.
3 However, the disadvantage of this (namely that elements can consist of
both html and php), is that Midgard doesn't really stimulate separating html
and php rigorously. If you want to do so, you end up with a lot more
different style elements contained in the same style. All Midgard does is
produce one mixed php/html result page (in memory) from that tree of
html/php fragments you set up, which is then processed as a normal
html-with-embedded-php page. So for every time that this resulting page
switches from php to html or vice versa, you'd need to create another
style/page element in the underlying tree. You can't jump out of the
process and apply a different style to the page you're processing, because
you're trapped in that style from the start on. The style normally already
produced some output before even starting to process your php logic.
(4) Other differences (with your system) to Midgards disadvantage: you
cannot pass parameters to an style/page element. Since a referral to a
<[style-element]> pretty much works the same way as an "include()", the way
to transfer information from one style element to another, is by setting a
global variable in one style-element, that you reuse in another. This
creates heavy dependencies and risks of name clashes of course, Midgard
programmers solve them by using standard variable names such as $article or
$topic...
5 the snippet system doesn't really help here since it doesn't offer scoping
either (snippets or simply included, you can of course use it as a classes
or functions repository), and if you want to call a style element from a
snippet, you have to use mgd_eval() in order to parse the elements, a
resource-consuming and not very elegant hack (?? or am I wrong here??)
(My goodness, sorry people, I just wanted to answer a question and I ended
up opening my heart over Midgard :-)
Of course several people have seen these and other problems, and you might
have some advantage with Alan Knowles' approach in
http://marc.theaimsgroup.com/?l=midgard-user&m=101408213519998&w=2 or by
keeping part of your code in the file system instead of in the Midgard
system, and calling it from a style. I for myself try to maintain
everything that has to do with presentation in the easily maintainable but
slow web interface (OldAdmin or Aegir). The actual application scripts I
try to keep in php files on the file server, because I can update them
faster with my ftp-enabled editor and I really do not want to be hindered by
the webinterface in testing and debugging (being an rookie programmer I need
to debug a lot.:-). Another approach that might interest you is the Midcom
system that's currently developed... that helps to componentize your
application (I didn't test it because I work in a hosted environment and I
can't use repligard).
pascal
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
