>
tal:omit-tag />
>
You don't really need the for-loop for columns of the same width:
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
>
>
>
> 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
From spurkis at quiup.com Wed May 28 12:54:04 2003
From: spurkis at quiup.com (Steve Purkis)
Date: Wed May 28 11:58:50 2003
Subject: [Petal] [PATCH] refactored Petal::Hash::Var + todo tests
Message-ID:
Hi,
I've done a major refactoring of Petal::Hash::Var with the following
goals in mind:
* extensibility
* readability
* improved error reporting
The patch introduces a parser object to Petal::Hash::Var. IMHO, this
would do better off as something like Petal::Expression::Parser - then
other objects would be able to use it (which is what I was originally
planning on doing to auto-vivify things in Petal::Hash).
Note that performance may drop slightly as a result of this patch: what
used to be one static method has now become many different instance
methods. I doubt this will be a big issue though.
Other things this patch addresses:
* Fixes a bug: $current->$next methods always called with @args
* regexs are now pre-compiled (though I think I've missed a couple)
* TODO tests for auto-vivifying hashes (should these be errors
instead?)
Regards,
-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Petal-0.92-refactor-var.patch
Type: application/octet-stream
Size: 27724 bytes
Desc: not available
Url : http://www.email-lists.org/pipermail/petal/attachments/20030528/532ea69f/Petal-0.92-refactor-var.obj
From william at knowmad.com Wed May 28 09:29:06 2003
From: william at knowmad.com (William McKee)
Date: Wed May 28 13:25:59 2003
Subject: [Petal] [PATCH] refactored Petal::Hash::Var + todo tests
In-Reply-To:
References:
Message-ID: <20030528122906.GA873@knowmad.com>
On Wed, May 28, 2003 at 11:54:04AM +0100, Steve Purkis wrote:
> The patch introduces a parser object to Petal::Hash::Var. IMHO, this
> would do better off as something like Petal::Expression::Parser - then
> other objects would be able to use it (which is what I was originally
> planning on doing to auto-vivify things in Petal::Hash).
Have you looked at the TALES specs for type prefixes? It defines a
prefix called `python:`. Jean-Michel has opted not to implement a
similar prefix for perl to prevent punching holes in the security of the
templating system (at least I think that's his reason). It sounds like
the Petal::Expression::Parser that you are talking about could be
implemented as a modifier a plug-in module.
Personally, I follow the philosophy of templates as limited
mini-languages. Thus I haven't needed the ability to run perl code or
auto-vivify hashes inside of my templates. However, if it makes Petal a
better tool, I'm generally all for it.
> Note that performance may drop slightly as a result of this patch: what
> used to be one static method has now become many different instance
> methods. I doubt this will be a big issue though.
That depends on the benefits that are gained. Not being familiar with
the Petal::Hash::Var module, I can't offer an answer to that question.
Hopefully Jean-Michel will have some input on this thread soon. In the
meantime, have you done any benchmarking to see how big the speed
difference is?
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
From jhiver at mkdoc.com Wed May 28 15:48:32 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Wed May 28 14:48:39 2003
Subject: [Petal] [PATCH] refactored Petal::Hash::Var + todo tests
In-Reply-To: <20030528122906.GA873@knowmad.com>
References:
<20030528122906.GA873@knowmad.com>
Message-ID: <20030528134832.GA22340@mkdoc.com>
> > The patch introduces a parser object to Petal::Hash::Var. IMHO, this
> > would do better off as something like Petal::Expression::Parser - then
> > other objects would be able to use it (which is what I was originally
> > planning on doing to auto-vivify things in Petal::Hash).
That's cool, I'll try that when I get a minute, unfortunately I don't
have many of them to spare at the moment. I hope waiting for a couple of
weeks is not too bad...
I think auto-vivifying hashes is an acceptable behavior. If it makes
your life easier and no one else's worse then I don't see why we should
not include this.
However this change should not happen in Petal::Hash::VAR...
> Have you looked at the TALES specs for type prefixes? It defines a
> prefix called `python:`. Jean-Michel has opted not to implement a
> similar prefix for perl to prevent punching holes in the security of the
> templating system (at least I think that's his reason).
Not really. It's just that I don't want to see Perl code in my
templates, and having a 'perl:' modifier would be like trying not to
smoke with an opened packet of ciggies on the table. Some people would
be disciplined enough not to use 'perl:', I'm sure I wouldn't. :)
> It sounds like the Petal::Expression::Parser that you are talking
> about could be implemented as a modifier a plug-in module.
This sounds like a good idea, until the patch is applied to Petal at
least.
> > Note that performance may drop slightly as a result of this patch: what
> > used to be one static method has now become many different instance
> > methods. I doubt this will be a big issue though.
I am not so sure about this. Petal::Hash::VAR is basically called very,
very, VERY often when a template is executed. I'll do some testing
before I release anything to make sure it's not too bad...
Cheers,
--
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
From fergal at esatclear.ie Wed May 28 23:18:43 2003
From: fergal at esatclear.ie (Fergal Daly)
Date: Wed May 28 22:12:26 2003
Subject: [Petal] [BUG] can't set variables to static values
In-Reply-To:
References:
Message-ID: <200305282218.43889.fergal@esatclear.ie>
On Wednesday 28 May 2003 11:47 am, Steve Purkis wrote:
> On Monday, May 26, 2003, at 02:22 am, Fergal Daly wrote:
> 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 don't think so. There are already some things you can with Petal that you
can't do with TAL so one more wouldn't be out of the question.
> 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...
There certainly should be an error at least.
If you are going to implement it, here's something else to think about.
path:a/b can mean $hash->{'a'}->b() or $hash->{'a'}->{'b'} depending on
whether a is an object or a hash. Also path:a/0 can mean a hash or an array
dereference. This gives rise to the question of what to autovifvify if you
try to set a/0, a hash or an array? Most likely an array I suppose.
> You don't really need the for-loop for columns of the same width:
>
>
There is a crucial difference between Petal and TAL, at the moment Petal
doesn't do local variables whereas TAL does them by default, so in TAL you
can do
you don't have to worry about overwriting the old value of cols and colwidth
because once you get to the , the old values will come back. But like
I said, TAL doesn't do that yet.
> 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 want as little as possible in the templates, I guess we just differ on our
wants.
> 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.
Yeah. TAL is just a small piece of Zope. Petal stands alone and so is missing
all the standard utilites that come with Zope. I guess someone should look at
what utilities Zope provides for templates and produce something similar...
but not me.
F
From jhiver at mkdoc.com Thu May 29 09:58:42 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Thu May 29 08:58:47 2003
Subject: [Petal] [BUG] can't set variables to static values
In-Reply-To:
References: <200305260222.07774.fergal@esatclear.ie>
Message-ID: <20030529075842.GA29356@mkdoc.com>
> 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.
Well, I agree and I disagree!
Petal doesn't need more standard plugins, Petal needs more optional CPAN
plugins.
Petal will automatically look in @INC and import named
Petal::Hash:: and assign it to 'something:', so anybody can
quite easily write Petal plugins. Once the plugin is installed on the
system Petal will pick it up as if by magick!
So everybody is quite welcome to write plenty of wonderful, useful
plugins and upload them on CPAN :)
All the best,
--
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
From jhiver at mkdoc.com Thu May 29 13:08:10 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Thu May 29 12:08:16 2003
Subject: [Petal] [TRICK] Custom modifiers in your applications with Petal
Message-ID: <20030529110810.GA31402@mkdoc.com>
Hi List,
I would like to submit this trick to the list. Your applications are
split in a horde of modules, and you would like to access some of the
those modules functionality from Petal.
For example, let's imagine that you have a class 'FruitFactory' with a
static instanciate ($fruitclass, @args) method that instanciates fruits.
You want to be able to instanciate those fruits from Petal.
In your FruitFactory class, write:
use Petal; # sell your soul!
$Petal::Hash::MODIFIERS->{'new_fruit:'} = sub {
my $hash = shift;
my @args = @_;
return FruitFactory->instanciate (@_);
};
Then from your template you can do:
Banana
At the moment I use this technique to instanciate various objects
(config, web logic, data objects) which I need to use and it works well!
Cheers,
--
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
From william at knowmad.com Thu May 29 09:36:49 2003
From: william at knowmad.com (William McKee)
Date: Thu May 29 13:33:39 2003
Subject: [Petal] [TRICK] Custom modifiers in your applications with Petal
In-Reply-To: <20030529110810.GA31402@mkdoc.com>
References: <20030529110810.GA31402@mkdoc.com>
Message-ID: <20030529123649.GC873@knowmad.com>
On Thu, May 29, 2003 at 12:08:10PM +0100, Jean-Michel Hiver wrote:
> At the moment I use this technique to instanciate various objects
> (config, web logic, data objects) which I need to use and it works well!
Hey Jean-Michel, this trick looks interesting, but I'm not making the
leap from the FruitFactory ex. to instanciating config or web logic
objects. Could you fill in the details a bit for me. I'm particularly
interested in the config object. It sounds like you are using this
object to build a config page that allows a user to modify the values
stored by your application. I have a need for such a solution RSN.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
From jhiver at mkdoc.com Thu May 29 15:07:33 2003
From: jhiver at mkdoc.com (Jean-Michel Hiver)
Date: Thu May 29 14:07:40 2003
Subject: [Petal] [TRICK] Custom modifiers in your applications with Petal
In-Reply-To: <20030529123649.GC873@knowmad.com>
References: <20030529110810.GA31402@mkdoc.com>
<20030529123649.GC873@knowmad.com>
Message-ID: <20030529130733.GA32377@mkdoc.com>
> I'm particularly interested in the config object. It sounds like you
> are using this object to build a config page that allows a user to
> modify the values stored by your application. I have a need for such a
> solution RSN.
Unfortunately I'm not, I'm just doing that to fetch some config
values... I have a module that'll turn an XML file into a text email,
and I'm using Petal to produce the XML file, and some of the values
(From, CC, Organization...) need to be taken out of the config.
------------- %< completely OT -------------
As for your problem, if you need a quick solution you can always store
the config in a database, re-write your config module to attack the
database (using the same API), and use an open-source database web admin
tool as an interface to your config (I know, it always sounds easier
than it is...)
Of course the only bit of config that you could not administrate would
be the database connection parameters themselves.
------------- TO yletelpmoc >% -------------
Cheers,
--
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
From chris at webarchitects.co.uk Thu May 29 17:05:50 2003
From: chris at webarchitects.co.uk (Chris Croome)
Date: Thu May 29 16:05:51 2003
Subject: [Petal] [INFO] Dublin Core Translation Tool
Message-ID: <20030529150550.GC5876@webarchitects.co.uk>
Hi
----- Forwarded message from "Wagner,Harry" -----
Date: Thu, 29 May 2003 10:56:40 -0400
From: "Wagner,Harry"
Subject: Registry Phase 2 & New Translation Tool
To: DC-INTERNATIONAL@JISCMAIL.AC.UK
A companion application - the DCMI Translation Tool - is also now
available. This tool is open-source and serves 2 purposes:
- Provides a convenient, and simplified, means of translating the
DCES, qualifiers, etc. and for translating the Registry user
interface.
- Demonstrates, by example, how an application can utilize the
Registry application interface.
The application is available at:
http://wip.dublincore.org/translate/index.html. There is also a
link on this page for the application source code.
The translate tool currently supports English, German and Japanese
user interfaces, and includes a property editor which facilitates
the creation of additional translations. I encourage you to try
this application, particularly if your language is not currently
supported by the Registry, or if the current Registry translation is
incomplete.
----- End forwarded message -----
--
Chris Croome
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
From chris at webarchitects.co.uk Thu May 29 17:17:44 2003
From: chris at webarchitects.co.uk (Chris Croome)
Date: Thu May 29 16:17:45 2003
Subject: [Petal] Re: [INFO] Dublin Core Translation Tool
In-Reply-To: <20030529150550.GC5876@webarchitects.co.uk>
References: <20030529150550.GC5876@webarchitects.co.uk>
Message-ID: <20030529151744.GD5876@webarchitects.co.uk>
Hi
Aarh, worong list....!
Sorry
Chris
On Thu 29-May-2003 at 04:05:50PM +0100, Chris Croome wrote:
> Hi
>
> ----- Forwarded message from "Wagner,Harry" -----
>
> Date: Thu, 29 May 2003 10:56:40 -0400
> From: "Wagner,Harry"
> Subject: Registry Phase 2 & New Translation Tool
> To: DC-INTERNATIONAL@JISCMAIL.AC.UK
>
> A companion application - the DCMI Translation Tool - is also now
> available. This tool is open-source and serves 2 purposes:
>
> - Provides a convenient, and simplified, means of translating the
> DCES, qualifiers, etc. and for translating the Registry user
> interface.
>
> - Demonstrates, by example, how an application can utilize the
> Registry application interface.
>
> The application is available at:
> http://wip.dublincore.org/translate/index.html. There is also a
> link on this page for the application source code.
>
> The translate tool currently supports English, German and Japanese
> user interfaces, and includes a property editor which facilitates
> the creation of additional translations. I encourage you to try
> this application, particularly if your language is not currently
> supported by the Registry, or if the current Registry translation is
> incomplete.
>
> ----- End forwarded message -----
--
Chris Croome
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
From 587nzeoyn6 at commercecheck.com Sat May 31 19:32:25 2003
From: 587nzeoyn6 at commercecheck.com (Lawanda Frederick)
Date: Sat May 31 13:35:47 2003
Subject: [Petal] Re: is there a way to resolve a such situation? cge sudiy
sat
Message-ID: <0e03g926g74-5t$ofb2--7v@rob.io2g>
An HTML attachment was scrubbed...
URL: http://www.email-lists.org/pipermail/petal/attachments/20030531/5a2a63dd/attachment.htm