On Tuesday 26 May 2009 01:44:43 am Nathan Rixham wrote:
> Stuart wrote:
> > 2009/5/25 Robert Cummings <robert@xxxxxxxxxxxxx>:
> >> I continued the discussion with Nathan.
> >
> > I too have had an off-list discussion with Nathan on this topic, and a
> > productive one at that.
>
> which would probably be a good time for me to step back in; having had a
> nice little inside in to both Robert and Stuarts template systems, and
> indeed way(s) of doing things. Also thanks to everybody else who made
> suggestions and gave input - it was all appreciated.
>
> I'm far from making a final decision, as I've decided to approach this
> by setting a few guidelines and a wishlist, then either finding /
> modifying something to do the job, or creating something from scratch.
>
> Both Rob and Stuarts systems were more in common than they may think,
> focus in both was on performance, and only making set data available to
> the templates (whether pushing or pulling).
>
> The syntax did differ though, and functionality aside this is probably
> one of the most important aspects (imho).
>
> Markup & XML sits well with me (and most) because we are web developers
> and use it daily.
>
> PHP syntax also sits well because we also use it daily.
>
> The fact remains though that this "feels like" (and possibly is) a
> different job which requires something different. Both XHTML and PHP do
> their job well - just as ecma(java)script and css do theirs.
>
> However none of these technologies / languages are suited and dedicated
> to converting provided data in to specified output; specifically, and
> only, xhtml.
>
> XSL Templates are near perfect, built for the job, and very powerful -
> but time hasn't favoured them well; and until (if ever) a wide spread
> adoption happens something else needs to fill the gap.
>
> Template Specific Thoughts:
>
> Smarty, Stuarts Engine, Robs Engine, PHPLIB and many more had one common
> theme, they all limited the data available. My terminology of limited
> perhaps sounds wrong, so maybe "make specified selected data available"
> or "provide access to the view" will make more sense. Inline with
> layered and tiered application design this makes perfect sense; thus..
>
> A template /should/ only be able to access the data made available to
> it, nothing else. Whether it requests the data or the data is provided
> is covered later. If it doesn't have all the data needed then this needs
> reviewed and the application needs changed to provide it. Not the
> template engine bastardized to accommodate a limited app.
>
> A template ~should~ have unique yet easy to understand syntax, something
> that complements xhtml and provides all needed functionality. (IMHO it
> should not be php syntax)
>
> A template engine must stick within it's role boundaries, it's not a
> cache engine, its not php, its not xhtml, its not for implementing
> functionality - it is simply and purely to do its job - take data,
> populate an xhtml template with it and return the result - nothing more,
> nothing less.
>
>
> Push vs Pull.
>
> This is a much bigger issue than I thought, and perhaps is the crux of
> the whole thing. I can see two clear approaches;
>
> Firstly, (the common one)
> - app passes data and a template to the template engine
> - template engine merges it together and passes back
> - app does as it pleases with data (sends it to client, caches it, fires
> it in an email - whatever)
>
> Secondly, (uncomment)
> [think modular]
> - app provides an api / gateway to views of data
> - template engine requests view(s) specified in template from app
> - template engine populates template modules with data & sends output to
>
> I guess the first is template engine as a Util / Service - and the
> second is template engine as a Layer / App.
>
> There are pros and cons in each design, concentrating on the second
> design for now - this brings in a lot of scope which seems to fit well
> both practically and architecturally.
>
> The freedom to be able to specify in template that...
>
> this is template module "latest posts", it is bound to the data view (or
> data provider) "latest posts(8)"
> whilst overall combining template (page) is comprised of modules x,y and
> z - here, here and here.
>
> ...really appeals to me; certainly in this scenario where you request
> (pull) from the application rather than make it all available. This way
> you only ever perform the business logic required for the information
> available. The counter part of making everything available incase it may
> be used is ridiculous (and makes me think coldfusion for some reason??).
>
> Architecturally this appears to be good - it's the presentation tier
> being a presentation tier, the logic tier knows nothing of the
> presentation tier and simply serves up what is requested. However thats
> only on the one side of the tier - on the other side we have a huge
> gaping hole where functionality should be (cache, compilation, delivery)
> etc, which would require another, as yet unknown layer (or 2).
>
> The abstraction and separation of concerns in this setup really appeals
> - but practically I'm not sure if the time spent implementing on a small
> or even medium sized project would be worth it. Still appeals massively
> though - pull makes more logical sense to me.
>
> Meanwhile, we have the first option, the way it's done, "push" the data
> - specify a template for that data and let template engine X do the
> merging. IMHO a clean, simple, lightweight implementation wouldn't be
> the hardest thing to make, and hundreds of apps are freely available all
> ready.
>
>
> Push vs Pull Conclusion
> Mentally I'm sticking with "pull" for a long term goal, however
> practically I'm going to look at creating "push"; which isn't hard and
> focussing specifically on template syntax, which is were I'm going next :p
>
>
> Syntax
>
> As mentioned previously I strongly feel all the current offerings I've
> seen are not ideal, the syntax is just a bit wrong
>
> preference goes to smarty/phplib style of syntax {$var.child} for only
> one reason.. because it's not as intertwined as:
> echo '<li>'. $var->child . '</li>';
> //simple example but you know how messy this can get
> likewise it's not as ..?.. as xslt nor is it as potentially confusing as
> two versions of markup in the same document.
>
> however, I still don't like it - it's just a workaround imho, a
> temporary measure.
>
> between the last line and here there is a massive trail of thought I
> can't even begin to type out, and it'd be v boring. BUT it leads me to
> the following..
>
> An extended version of xhtml, with a simple dtd, specifically for
> templates. This isn't intertwined or alternative markup, it's enhanced
> with more attributes.. consider
>
> <div id="comments" datasource="blog.recentcomment">
> <p>
> <strong data="title" /><br /> ..PROBLEM..
> </p>
> </div>
>
> and here in and there in lies the great big feckin problems which means
> we'll never have a proper solution.
>
> ..PROBLEM.. how do we specify what the content of problem area is?
> without introducing a new tag rather than just an attribute?
>
> making a template syntax is simple, while you do block elements, the
> second you hit inline elements you are stuffed.
>
> <b> is the bane of our lives, because we can't represent inline elements
> in any language bar xhtml, we work with blocks of everything. Consider
> drawing API's, you can draw a circle inside a square easily, the code is
> just:
> object.drawSquare( x , y , w , h );
> object.drawCircle( x , y , r);
> it's never
> object.drawSquare( x ,{object.drawCircle( x , y , r)} y , w , h ); //lol
>
> back in xhtml world, to mark off a segment as <b> without using the
> syntax or sending an xhtml fragment in a var we'd have to do it using an
> instruction with offsets and positions.
> $string = 'some content here';
> $boldBit = substr( $string , 5 , 7);
> // .. more code
>
> so the syntax of xhtml doesn't really fit any programming language (?)
>
> interestingly I finished that ..PROBLEM.. off mentally and came up with
> a tag like <data data="whatever" /> which may as well just be <value-of
> data="whatever" /> which is just xslt.
>
> square one.
>
> sub thought.. is that an xslt pre processor which figured out what data
> the xsl needs, then provides it as xml and delivers client side ready
> for rendering would be nice.
>
> ultimately though, I feel I'm getting no-where, syntax syntax syntax - I
> re-iterate, I'll have the solution to this when this can be accomplished
>
> <?php
>
> if( isset($comments) && is_array($comments) && count($comments) > 0 ) {
> echo '<h2>Comments</h2>';
> echo '<div id="comments">';
> foreach( $comments as $index => $comment ) {
> echo '<a href="' . $comment->link . '">';
> echo $comment->title;
> echo '</a>';
> }
> echo '</div>';
> } else {
> echo '<h3>No Comments</h3>';
> }
> ?>
>
> without php and without xml style markup (unless it's by extension of
> xhtml with data attributes)
>
> that was a big one!
>
> regards & any thoughts more than welcome.
Well I try to follow with my limited English knowledge.
My offer is.
template.php;
<?php
$content = 'No Comments';
if(isset($comments) and is_array($comments) and count($comments) > 0 ) {
$content = '';
foreach( $comments as $index => $comment ) : $content. = "<a href='".
$comment->link."'>".$comment->title."</a>"; endforeach;
}
?>
<h2>Comments</h2>
<div id="comments">
<?=$content?>
</div>
index.php
ob_start();
require('template.php');
echo ob_get_clean();
I'm still do not understand for complex template system requirement.
Why it have to be very complex system.
Large data array, some conditions, lots of loops, and What else ?
http://www.flytag.de/
http://urlaub-finder.de/
http://airportdirekt.de/
All same system. With different css designs.
Regards.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
