[Petal] [BUG] can't set variables to static values
Steve Purkis
spurkis at mkdoc.com
Wed May 28 12:47:04 BST 2003
On Monday, May 26, 2003, at 02:22 am, Fergal Daly wrote:
> On Friday 23 May 2003 11:24, Steve Purkis wrote:
>> Yeah - too much complexity in templates is definitely not a good
>> thing.
>> And I admit that trying to set $lang/fu in this case is a bit of a
>> hack... But in general, I don't see why auto-vivifying a hash is a
>> bad
>> thing - it's a handy way of grouping things for the template writer.
>
> TAL does't have hashes, so that's why it can't autovivify them. You
> cannot set
> "a/b". From the TAL spec
>
> [snip]
Ahh, a shame that. It's not very intuitive from a Perly point of view.
And I'm assuming Petal aims to be 100% TAL compliant?
I'd be inclined to implement it anyway, but if no-one else would use it
then it's not really worth it. So perhaps Petal::Hash should be
modified to throw an error if you attempt the above? At least that
would save anyone else from falling into the same trap...
> It really depends on what you're looking for from your templating
> language. I
> get the impression that TAL is very deliberatley designed to prevent
> you
> doing anything complicated in the template. That suits me perfectly.
> Before
> TAL I was using a homegrown system that had variable and loops and
> that's
> all, everything else had to worked out by the app. I was working with
> HTML
> coders, some of whom produced lovely looking web page but had quite a
> bit of
> trouble even with loops and variable substitutions. So I have no
> desire to
> put any logic at all in my templates.
Yeah, I've also worked with HTML people who don't know the first thing
about coding. The way I see it you can either train them up to use
various template systems if they are so inclined, or you can take the
HTML and cut it up into templates yourself. I prefer to work with
people who can do the former. And I don't see anything wrong with
doing complicated things in templates so long as both they and their
purpose are obvious, but I think it really does boil down to preference.
>> But maybe this depends on what you consider to be a presentation
>> issue... Say for some reason you didn't know how many columns would
>> be
>> in a table until runtime. I'd like to be able to do something like:
>>
>> $table/cols = foo/number_of_attributes
>> $table/col1/width = 100 / $table/cols
>> ...
>>
>> Ok, so it's not the best example in the world :) but IMHO, this is a
>> presentation issue, and should be handled in the template.
>
> Even though you don't like the example, I think it is illustrative.
> Your ...
> hides a lot. It hides the fact that you would actually need a for loop
> here
> because you don't know how many columns you will need to initialise.
> So now
> you have a for loop in your template that doesn't produce any output,
> you're
> using TAL as a programming language but TAL makes a pretty poor
> programming
> language as you can see
>
> <div tal:define="table/cols foo/number_of_attributes" tal:omit-tag />
> <div tal:for="column table/cols" tal:omit-tag>
> <div tal:define="table/cols/$column/width perl:100 / $table/cols"
> tal:omit-tag />
> </div>
You don't really need the for-loop for columns of the same width:
<?var name="set: table/cols foo/number_of_attributes"?>
<?var name="set: table/colwidth perl:100 / $table/cols"?>
But you're right, the '...' does hide a lot. it *was* a poor example
:).
You're right that I am trying to use TAL as a programming language
(though in a minimalist kind of way). But that's what I see template
systems as. I think the point is that we're coming at this from
slightly different angles, and there's nothing wrong with that. You
prefer to do as little as possible in the templates, whereas I prefer
to do a little bit more. But only a little bit, mind you! I've worked
on systems where half the application logic was hard-coded into the
templates... tell me how you're supposed to debug/test that..
*shudders*
> apart from being horribly verbose and cumbersome, there's lots more
> functionality missing from TAL the programming language, so rather than
> turning TAL into a very bad programming language you should do all your
> calculating in functions
>
> <table petal:define="table utils/setup_table_widths
> foo/number_of_attributes">
> ...
> </table>
>
> that way you can use it in all your other templates too.
The major problem I have with doing this is that my HTML guy can't come
along and change table widths and other presentational things. Which
means I have to do it (but heck, I'm doing everything at the moment
;-). On projects where the back-end functionality is very complicated
or labour intensive I like to be able to off-load as much of the
front-end work as possible.
> I know your example was a bad one but I don't think there is an
> example where
> it isn't easier to just put it in a function and you'll be glad of it
> if you
> ever have to let someone non-technical near your templates.
If I do let that happen, there will be a certain amount of trust
involved.
> Just because
> something is a presentation issue doesn't mean the code for it has to
> be in
> the template. Zope comes with a package of utility functions for table
> layout
> and other common things and I got the impression that TAL is the way
> it is
> because it's predecessor (DTML) allowed people to do too much
> programming in
> the templates and caused a lot headaches,
The pendulum swings... I guess it's a matter of finding a balance that
works for you. I prefer tools that don't limit what you can do too
much - this way you can put your own limitations in place. And in
general TAL/Petal lets me do that. Which is a good thing.
I agree utility functions are a good idea (I've introduced a few in the
project I'm working on, such as a date string formatting tool). As an
aside, I think that that's one place where Petal suffers from an
out-of-the box point of view - it needs more standard plugins.
-Steve
More information about the Petal
mailing list