[prev in list] [next in list] [prev in thread] [next in thread] 

List:       smarty-dev
Subject:    Re: [SMARTY-DEV] template param syntax
From:       "Luna Kid" <listreader () neuropolis ! org>
Date:       2003-12-17 1:39:54
[Download RAW message or body]

First of all, thanks for your time very much!

> One of the best things about Smarty has got to be its API and plugin
> architecture. You may want to consider writing a general function that
> parses items as you have indicated. It would be wise for your function
> to call-upon Smarty's base functionality where appropriate. This would
> then give you a general way to implement custom compiler plugins that
> followed your prescribed syntax and semantics. This would give you the
> best of both methods and could make for a worthy add-on if done with
> care.

Thanks, I'll try that if my time allows.

The rest below is some "due" support to this "streamline 
syntax" thing. I felt it necessary to tell, sorry if you
are actually all fed up with this... ;)

------------------------------------------------------------

> importantly, also for the user writing the code who must remember
> the proper ordering sequence (semantics), and for other users reading
> the code who must do the same without any embedded clues. Contrast this
> to named parameters where no such confusion can arise and to which
> parameters are (more) obvious even to users who may be unfamiliar with
> a particular function.

Well, this may be quite true in a general, theoretical context, 
but if one keeps focus on the mundane, frequent, practical cases, 
there is hardly any confusion, extreme parameter-ordering to follow, 
obscure syntax etc.

The actual subjects of this issue are just very simple, very clear,
straightforward things, which are currently unsupported. They are 
almost supported, though, and they could be supported fully, at 
the one valid expense of the one-time HTML/XHTML-like quoting 
"compatibility shock"... (Perhaps a poll should be conducted on 
this one.)

I think I understand your concerns, but I just still can't just
acknowledge not taking the (so close...) opportunity of writing 
templates in probably the simplest and most intuitive manner 
one can possibly come up with:

    {err "Oops, what was that?" fatal}

    {popup "sdfsdfsdfdf" caption="caption" sticky left}

    {listmode ordered}

    {list 'item 1' 'item 2' 'item n' bulleted}

        (BTW, I think you can't even do this last one 
        currently, without some extra reading and hacking 
        around Smarty internals or uglifying both your 
        template and plugin function code significantly.)

And the semantics is very simple, too: "the order of unnamed
parameters is kept as is". I doubt anyone who's smart enough 
to use something like Smarty would have problems with that.

The quoting thing is really a bummer, though... That is the only 
good reason against blatantly introducing the "streamline" syntax. 
But even that could be handled by a config switch, defaulting 
to the "legacy" unquoted-string-literal support [what I'd call 
a mistaken idea, BTW], but still letting those who'd like to 
write the nicest templates on Earth ;) to do just that with 
the stock Smarty parser.

Please also note that these unnamed parameters would be a natural 
choice not just in *some* cases, but probably for the *majority* 
of all template functions. This is because most template functions 
are operations that work on a well-known subject. That subject
is typically the "main parameter" of the function. The role of 
that argument is clearly implied by the function name itself, so 
naming it as something like 'text', 'name', 'file' etc. usually 
adds no useful information, but just noise to skip in the code.

So, not supporting the optimal syntax for perhaps the most common 
*normal* cases in exchange for e.g. debugging aid in some obscure 
*error* cases (like accidentally omitting an equal sign) doesn't 
quite sound like a very good deal to me.

It is the authoring of template code where Smarty should play
its main role best, so this is the area which should be optimized 
the most (as long as other constraints, like performance, allow). 
If the parser could help make the template and plugin authors' 
lives easier -- then it actually *must* do that. Simply, because 
that's the reason why a template engine exists.

(On the API side, supporting the above is simply an additive 
thing. You don't have to break existing plugin code, smarty 
could just pass the array of unnamed args in

        $params['_unnamed_']

and evertything would remain clean and simple.)


> > passing syntax, Smarty could bite quiet a huge chunk 
> > of extra usability (and finally could even beat my 
> > own hacky template processor, hopefully... ;) ).
> 
> Well, I've never seen your template processor, but I think that even
> as-is, Smarty is a pretty good horse to bet on ;)

I was kidding here (see the smiley ;) ). Smarty, as-is, is 
a LOT better in almost every aspect than my hack (there is 
a reason why I spend my time here, trying to improve Smarty, 
rather than my own crap... ;) ). So, Smarty is better in 
everything -- except for this single syntactic matter, which 
well, accidentally, also happens to be the heart of the whole 
templating idea... (Templates are "syntax optimizer" facilities.)
 
> All that being said, I DO see cases where something like you are
> suggesting would be interesting indeed. Unfortunately, I see these
> cases as not being appropriate for users at-large.

I can understand this, of course. A poll would be better, 
tough -- but honestly, even I think that most people in the 
"PHP buisness" would probably not consciously recognize the 
value of those proposed "subtleties", but they would immediately 
recognize the "value" of keeping their sloppy, unquoted string 
literals unquoted forever... :-/

OTOH, "users at-large" usually need guidance. Sometimes we could 
(or should?) just use our "magical touch" and do our little bit 
to drive people to the right direction...


Thanks very much for your patience!

Sz.

-- 
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[prev in list] [next in list] [prev in thread] [next in thread]