On Mon, May 25, 2009 at 6:44 PM, Nathan Rixham <nrixham@xxxxxxxxx> 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.
>
Nathan,
I've thought on this a (read: very) little, and can't help but think
that some of what you describe sounds an awful lot like ASP.NET. I
haven't done much with .NET, so I could be really off here (I wouldn't
really consider ASP.NET a template engine), but from what I recall an
ASP.NET page is basically an XHTML document that includes special tags
that tell .NET to render content from the compiled code-behind for the
page:
<html>
<body>
<asp:DataGrid
id="DataGrid1"
style="Z-INDEX: 101; LEFT: 24px; POSITION: absolute; TOP: 16px"
runat="server"
BorderColor="#DEBA84"
BorderStyle="None"
CellSpacing="2"
BorderWidth="1px"
BackColor="#DEBA84"
CellPadding="3">
</asp:DataGrid>
</body>
</html>
In this example, DataGrid1 refers to a specific instance of a DataGrid
object in the code that would have been loaded with data in the page's
Page_Load method. As such, the code NEVER calls the template; rather,
the placeholder in the template triggers the framework to call a
function that renders the control using the object in the code-behind.
A DataGrid is an object that knows how to self-render and can be
extended.
Something like this could probably be done in PHP, but it seems to me
that it would itself become a framework, which you stated up front was
not an option.
Andrew
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
