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
PHP Template Global Variables
| Tweet |
|
Search Discussions
-
Scott Lanning at Oct 23, 2005 at 7:06 pm ⇧
I think the same. It's consistent with other burners.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?
-
David Wheeler at Oct 27, 2005 at 2:05 am ⇧
On Oct 23, 2005, at 12:06 PM, Scott Lanning wrote:I think the same. It's consistent with other burners.
<?= $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?
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 ⇧
The quick hack to make this work is to do: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);
$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 ⇧
-
George Schlossnagle at Oct 27, 2005 at 3:38 am ⇧
Not so bad, really. A more elegant solution might be more aesthetic,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?
but I don't think there'll be a noticeable performance impact either way.
-
David Wheeler at Oct 27, 2005 at 3:43 am ⇧
Just the overhead of the eval every time I instantiate a new burner,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.
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 at Oct 27, 2005 at 3:54 am ⇧
You suggested:On Oct 26, 2005, at 8:46 PM, George Schlossnagle wrote:Could you remind me what the syntax we discussed is/was?
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?
$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 ⇧
Related Discussions
Discussion Navigation
| view | thread | post |
Discussion Overview
| group | php-sandwich-dev
|
| categories | perl |
| posted | Oct 22, '05 at 6:59a |
| active | Oct 27, '05 at 4:18a |
| posts | 10 |
| users | 3 |
| website | perl.org |
