On Mon, 2009-06-01 at 12:38 -0400, Andrew Ballard wrote:
> 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.
My template engine supports exactly this principle. Specific components
can be included all at once similar to the above, or they can be
included such that the component receives execution and sets up slices
for individually outputting to the template, or the template can
directly access the view object to retrieve properties. This is in
addition to custom tags and generic content handling triggers/template
processors. The module tag that does this is specifically tied to the
InterJinn framework, though the framework is designed such that custom
tags can even be overriden to produce some other coupling if desired.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
