headers
Benjamin Tucker | 27 Jul 08:37

control over encoding

Hi all,

I'm new to Petal and the list, so I apologize if this is something  
that's been discussed before.  I spent the better part of today  
integrating Petal into a mod_perl-based CMS.  All went very well with  
one exception.  There are a number of methods I had wanted to expose  
to the templates which return HTML.  Of course Petal helpfully  
encodes them.  I know that it provides the 'structure' keyword to  
turn this off, but I didn't want template authors to be forced to  
think about it, and rather wanted control from the data side of when  
escaping should not occur.

So my solution was I changed all the exposed methods that returned  
HTML to return the string as a scalar ref.  next I changed  
Petal::Hash::Var::process to not dereference scalar refs.  then I  
added to Petal::Hash::get_encoded logic not to not encode if $res is  
a scalar reference, and then dereferences $res.  (see attached patches).

Will this break anything?  is Petal::Hash::Var::process ever accessed  
without going through Petal::Hash::get_encoded?  Does anyone have a  
suggestion of a better solution.

Thanks!
Ben
Attachment (Hash.pm.diff): application/octet-stream, 602 bytes
Attachment (Var.pm.diff): application/octet-stream, 357 bytes
Permalink | Reply | 2 comments |
headers
Jonathan Vanasco | 27 Jul 16:30

Re: control over encoding


On Jul 27, 2006, at 2:37 AM, Benjamin Tucker wrote:

> Hi all,
>
> I'm new to Petal and the list, so I apologize if this is something  
> that's been discussed before.  I spent the better part of today  
> integrating Petal into a mod_perl-based CMS.  All went very well  
> with one exception.  There are a number of methods I had wanted to  
> expose to the templates which return HTML.  Of course Petal  
> helpfully encodes them.  I know that it provides the 'structure'  
> keyword to turn this off, but I didn't want template authors to be  
> forced to think about it, and rather wanted control from the data  
> side of when escaping should not occur.
>
> So my solution was I changed all the exposed methods that returned  
> HTML to return the string as a scalar ref.  next I changed  
> Petal::Hash::Var::process to not dereference scalar refs.  then I  
> added to Petal::Hash::get_encoded logic not to not encode if $res  
> is a scalar reference, and then dereferences $res.  (see attached  
> patches).
>
> Will this break anything?  is Petal::Hash::Var::process ever  
> accessed without going through Petal::Hash::get_encoded?  Does  
> anyone have a suggestion of a better solution.

Teach your people to use 'structure' when they want HTML and not when  
they don't-- because that distinction is in the TAL specification,  
which means your hack is Petal specific, and your templates worthless  
with any other implementatino
(Continue reading)

Permalink | Reply | 1 comment |
headers
Benjamin Tucker | 27 Jul 18:19

Re: control over encoding

On Jul 27, 2006, at 10:30 AM, Jonathan Vanasco wrote:

>
> On Jul 27, 2006, at 2:37 AM, Benjamin Tucker wrote:
>
>> Will this break anything?  is Petal::Hash::Var::process ever  
>> accessed without going through Petal::Hash::get_encoded?  Does  
>> anyone have a suggestion of a better solution?
>
> Teach your people to use 'structure' when they want HTML and not  
> when they don't-- because that distinction is in the TAL  
> specification, which means your hack is Petal specific, and your  
> templates worthless with any other implementatino

Of course it's petal specific, as is the backend API which I'm  
exposing to the templates and the Petal path expression parsing  
code.  These methods will always return html which should not be  
encoded.  Why force redundancy?  I'm not advocating this hack be  
included with the Petal distribution, I was just looking for advice  
on whether this would break something I'm not aware of, or if there's  
a better (read: equally DRY) valid way to do it.

Thanks,
Ben
Permalink | Reply | 0 comments |

Gmane