On Thu, 2006-10-26 at 01:04 -0700, Paul Novitski wrote:
> At 10/25/2006 11:24 PM, Robert Cummings wrote:
> >Now, the thing that I dislike about heredoc for such small strings is
> >the switching between heredoc mode and the switching back. It's ugly on
> >the scale of switching in and out of PHP tags.
>
> It's so interesting that some details bug some people and others bug
> others. In an expression such as this:
>
> echo '<option value="' . $day . '"' . $selected . '>' . $day
> . '</option>';
HEY! what's with all those spaces around the dots? ;)
> ...I count eight transitions (instances of switching between PHP
> syntax and output text) -- one each time you open or close a quote --
> compared to just two transitions (the opening & closing labels) for
> the comparable heredoc statement:
>
> print <<< hdDay
> <option value="$day"$sSelected>$day</option>
>
> hdDay;
>
>
> >it would be less ugly if
> >the closing delimiter didn't have to be at the beginning of it's own
> >line in which case code could still maintain indentation formatting.
>
> I agree. Too bad the PHP developers didn't come up with a special
> symbol for heredoc closing labels to give us more control over script
> formatting. I do however find this a fairly minor irritation, a
> small price to pay for heredoc's power.
>
>
> >To lighten the mess of heredoc I
> >personally use the following format:
> >
> > $foo = <<<_
> ...
> >_;
>
> Nice and concise! Thanks, I'll use that.
>
>
> >However that's only useful if indenting the content is not an issue.
>
> I don't see how you draw that conclusion. Heredoc doesn't become
> useless if we need to indent the content, it just means we lose
> complete control over indenting every line of our PHP script. The
> functionality is still totally there.
Sorry, I should have re-iterated -- useful to my sense of aesthetics :D
>
> This script indenting issue with heredoc is for me one of the few
> irritations of PHP. I love the language and the power that heredoc
> gives me. I'm also irritated by the class member syntax $this->that
> but I still use it as well.
Oh yeah, in no way do i think that heredoc reduces PHP. I love PHP too,
one of it's great attractions is the flexibility it gives to the
developer while not being reduced to a pile of PERL resembling
gibberish :) Mind you, some developers are extremely adept at making
their code look like gibberish regardless.
> > > I ask because I use heredoc all the time, sometimes for inline code
> > > as above but most often for template assembly, maintaining HTML in
> > > external files that can be edited independently of the PHP logic.
> >
> >I use a tag based template system, there's no PHP in my content so my
> >content files for the most part just look like more HTML.
>
> This is a different topic, but also one close to my heart. Yes, I
> too use my own selector-based templating system. It does allow me to
> embed PHP variables into the template if I want, but the primary
> merge between plain HTML template and MySQL content happens through
> CSS-style selectors.
>
>
> >Hello <jinn:render name="email" selector="firstName"/>,
>
> Cool.
>
> My comparable example (but in an HTML context) would look like:
>
> Hello <span class="firstName">FIRSTNAME</span>,
>
> where the engine replaces the content of the span with the value from
> the database based on a match of 'span.firstName' or perhaps just
> '.firstName'. (In this example the 'FIRSTNAME' content in the
> template is merely a place-holder to make it easier to preview the
> markup and isn't necessary to the merge process.)
Out of curiosity is your template engine just a search and replace based
on the span tags? Mine involves parsing out the tags and recompilation
of tag generated content (so you can output template tags within a
template tag). Tags can also load modules and provide meta logic. The
following is an example of a form template:
----
<jinn:module name="loginForm" render="false">
<jinn:component
type="view"
source="Project/modules/user/loginForm.inc"
name="view">
</jinn:component>
</jinn:module>
<jinn:render name="loginForm" selector="formOpen"/>
<project:box class="right-sidebar" id="login-form">
<div>
<jinn:render name="loginForm" selector="login_textOpen"/>
Username:<project:mandatory/>
<jinn:render name="loginForm" selector="login_textClose"/>
<jinn:render name="loginForm" selector="login_field"/>
</div>
<div>
<jinn:render name="loginForm" selector="password_textOpen"/>
Password:<project:mandatory/>
<jinn:render name="loginForm" selector="password_textClose"/>
<jinn:render name="loginForm" selector="password_field"/>
</div>
<jinn:comment>
<div>
<jinn:render name="loginForm" selector="rememberMe_textOpen"/>
<jinn:render name="loginForm" selector="rememberMe_field"/>
<jinn:render name="loginForm" selector="rememberMe_textClose"/>
</div>
</jinn:comment>
<div align="right">
<jinn:render name="loginForm" selector="continue_field"/>
<jinn:render name="loginForm" selector="register_field"/>
</div>
<jinn:if xpath="module://loginForm/view/hasErrors">
<div>
<jinn:render name="loginForm" selector="formError"/>
</div>
</jinn:if>
</project:box>
<jinn:render name="loginForm" selector="formClose"/>
----
As you may be noticing, my template engine is a pull engine. Modules are
pulled into play by the template and accessed via the render tags (the
<jinn:if/> tag shows another way to access module fields). The exception
is for the email example I formerly sent since the email module is
instantiated for the email template by virtue of being loaded by the
mail service -- but the email template can also load modules and can
access any other custom tags created for the project. For instance I
often have tags like the following:
<project:access level="admin">
Some content
</project:access>
Which means only a user with admin access will see the content. Also,
for simplicity I'll have:
<project:user field="firstName"/>
Which will inject the firstName value of the currently logged in user.
So basically, my code never references my templates, my templates just
include modules themselves which makes the code far more re-usable.
This is in contrast to many template systems that have the code include
the template.
The template engine is also not limited to tags. It's a generic engine
with registered "compilers" most of which will extend either the tag
compiler or the embed compiler. But I also use other types such as a
space compacter which just processes a complete template and removed any
extra white space etc. An embed compiler allows the following:
<a href="mail:{jinn:render selector=email}">send an email</a>
In other words it can get around the deficiency of using tags when you
want to embed content within a tag's attributes. Although, other than
the jinn:render embed, most embeds return raw values for use in
conditional tags.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
