FAQ

PHP Template Global Variables

David Wheeler
Oct 22, 2005 at 6:59 am
Hi All,

Apologies for cross-posting, but I wanted to get feedback both from
the Bricolage camp and from the PHP camp.

Right now, the Bricolage PHP burner sets up a single global variable,
$BRIC. In it, you can access the typical Bricolage templating objects:

<?= $BRIC['story']->get_title() ?>

However, in Mason and Template Toolkit templates, you can access
these things directly:

<% $story->get_title %>
[% story.get_title %]

Now, the reason these variables ($story, $element, and $burner) are
stored in $BRIC is because, as George told me, sticking stuff into
the PHP global namespace is considered bad manners. Well, it's also
bad manners in Mason, but I'm starting to lean toward moving these
variables directly into the PHP namespace for consistency with the
Mason and TT burners, as well as for simpler code:

<?= $story->get_title() ?>

Since the Bricolage templates are a relatively controlled
environment, I'm personally not too worried about the pollution. But
what do you think?

One wrinkle: code evaluated from the PERL_LOADER directive currently
can export symbols into the namespace used by the Mason and TT
templates. For example, if I have

PERL_LOADER = use HTML::Entities;

Then I can use the exported encode_entities() function directly in
the Mason or TT templates:

<% encode_entities($story->get_title) %>
[% encode_entities(story.get_title) %]

I'd like to do this in the PHP templates, too, but this also means
that more stuff will be stuck into the global namespace:

<?= encode_entities($BRIC['story']->get_title()) ?>

So getting rid of $BRIC[] and just using $story, $element, and
$burner directly goes right along with that:

<?= encode_entities($story->get_title()) ?>

Granted, HTML::Entities is not a great example (I know that PHP has
its own functions for that), but there are other useful things
exported by PERL_LOADER code, such as burner constants. So consider
it a given that Bricolage will be putting PERL_LOADER exports into
the PHP namespace.

Anyway, your feedback would be greatly appreciated.

Many TIA,

David
reply

Search Discussions

9 responses

  • Scott Lanning at Oct 23, 2005 at 7:06 pm

    On Fri, 21 Oct 2005, David Wheeler wrote:
    but I'm starting to lean toward moving these variables directly into the PHP
    namespace for consistency with the Mason and TT burners, as well as for
    simpler code:

    <?= $story->get_title() ?>

    Since the Bricolage templates are a relatively controlled environment, I'm
    personally not too worried about the pollution. But what do you think?
    I think the same. It's consistent with other burners.
  • David Wheeler at Oct 27, 2005 at 2:05 am

    On Oct 23, 2005, at 12:06 PM, Scott Lanning wrote:

    <?= $story->get_title() ?>

    Since the Bricolage templates are a relatively controlled
    environment, I'm
    personally not too worried about the pollution. But what do you
    think?
    I think the same. It's consistent with other burners.

    Thanks, Scott. Unfortunately, that might make setting the $element
    variable too the current element by display_element() tricky.
    Currently, it'd done like this:

    $php->eval(q/function setBric($key, $var) {
    global $BRIC;
    $BRIC[$key] = $var;
    }/);

    $php->setBric(element => $elem);

    I'm not sure how this could be done to set the global $element
    variable instead of $BRIC['element']. George, is this possible? Could
    you perhaps add a set_global method to PHP::Interpreter to simplify
    this sort of thing?

    Thanks,

    David
  • George Schlossnagle at Oct 27, 2005 at 2:44 am

    David Wheeler wrote:
    On Oct 23, 2005, at 12:06 PM, Scott Lanning wrote:

    <?= $story->get_title() ?>

    Since the Bricolage templates are a relatively controlled
    environment, I'm
    personally not too worried about the pollution. But what do you think?

    I think the same. It's consistent with other burners.


    Thanks, Scott. Unfortunately, that might make setting the $element
    variable too the current element by display_element() tricky.
    Currently, it'd done like this:

    $php->eval(q/function setBric($key, $var) {
    global $BRIC;
    $BRIC[$key] = $var;
    }/);

    $php->setBric(element => $elem);
    The quick hack to make this work is to do:

    $php->eval(qq/function setBric(\$key, \$var) {
    global \$$key;
    \$$key = \$var;
    }/);

    $php->setBric(element, $elem);
  • David Wheeler at Oct 27, 2005 at 3:12 am

    On Oct 26, 2005, at 7:43 PM, George Schlossnagle wrote:

    The quick hack to make this work is to do:

    $php->eval(qq/function setBric(\$key, \$var) {
    global \$$key;
    \$$key = \$var;
    }/);

    $php->setBric(element, $elem);
    Quick for me to do now, and so I will, but not so performant, I
    suspect. Am I right?

    Best,

    David
  • George Schlossnagle at Oct 27, 2005 at 3:38 am

    David Wheeler wrote:
    On Oct 26, 2005, at 7:43 PM, George Schlossnagle wrote:

    The quick hack to make this work is to do:

    $php->eval(qq/function setBric(\$key, \$var) {
    global \$$key;
    \$$key = \$var;
    }/);

    $php->setBric(element, $elem);

    Quick for me to do now, and so I will, but not so performant, I
    suspect. Am I right?
    Not so bad, really. A more elegant solution might be more aesthetic,
    but I don't think there'll be a noticeable performance impact either way.
  • David Wheeler at Oct 27, 2005 at 3:43 am

    On Oct 26, 2005, at 8:37 PM, George Schlossnagle wrote:

    Not so bad, really. A more elegant solution might be more
    aesthetic, but I don't think there'll be a noticeable performance
    impact either way.
    Just the overhead of the eval every time I instantiate a new burner,
    then, which means for every publish. But that was true before, too.

    This reminds me: George, a while ago you and I discussed on IM the
    idea of adding a method to the $perl object to make it easier to call
    Perl class methods. Currently, we have to do this:

    $perl = Perl::getInstance();
    $perl->call(
    'Bric::Biz::Asset::Business::Story::list',
    'Bric::Biz::Asset::Business::Story',
    # args to list()
    );

    This is annoying, of course, especially since it's wrong. The list()
    method is defined in Asset, and Story inherits it. So I'd actually
    have to do this:

    $perl = Perl::getInstance();
    $perl->call(
    'Bric::Biz::Asset::list',
    'Bric::Biz::Asset::Business::Story',
    # args to list()
    );

    I have to know too much about the internals. Any chance you could add
    the methods we'd discussed before to make this more idiomatic?

    Thanks,

    David
  • George Schlossnagle at Oct 27, 2005 at 3:46 am

    David Wheeler wrote:
    I have to know too much about the internals. Any chance you could add
    the methods we'd discussed before to make this more idiomatic?
    Could you remind me what the syntax we discussed is/was?
  • David Wheeler at Oct 27, 2005 at 3:54 am

    On Oct 26, 2005, at 8:46 PM, George Schlossnagle wrote:

    I have to know too much about the internals. Any chance you could
    add the methods we'd discussed before to make this more idiomatic?
    Could you remind me what the syntax we discussed is/was?
    You suggested:

    $perl->method('DateTime', 'now');

    That works for me. A use() or require() method (probably the latter,
    given that it's runtime) would be welcome, to:

    $perl = Perl::getInstance();
    $perl->require('DateTime');
    $now = $perl->method('DateTime', 'now');

    Thanks!

    David
  • David Wheeler at Oct 27, 2005 at 4:18 am

    On Oct 26, 2005, at 7:43 PM, George Schlossnagle wrote:

    $php->eval(qq/function setBric(\$key, \$var) {
    global \$$key;
    \$$key = \$var;
    }/);
    This worked:

    $php->eval(q/function setGlobal($key, $var) {
    global $$key;
    $$key = $var;
    }/);

    Woot! Thanks, George!

    David

Related Discussions

Discussion Navigation
viewthread | post