html-template-users — Discussion of HTML::Template and related modules

Re: [htmltmpl] Designating which template produced the output HTML?

[Kevin S. <kev...@gm...>]

On 7/30/05, Justin Simoni <ju...@sk...> wrote:
>=20
> Does anyone have any best practices in labeling the code that each
> template creates? For example, he proposed that we simply use HTML
> comments and wrap the template itself around them. For example:
>=20
> <!-- start [template_name].tmpl -->
>=20
> and
>=20
> <!-- end [template_name].tmpl -->
>=20
> What do you guys do?

I do exactly what you described here.  Each of my templates have the
following 2 HTML comments:

<!-- begin foo.tmpl -->
<!-- end foo.tmpl -->

--
Kevin.

[htmltmpl] Designating which template produced the output HTML?

[Justin S. <ju...@sk...>]

Hello all,

Recently, I ripped out most of the inline HTML from within a large  
app I've been working for some time and converted the mix of CGI.pm  
method's, inline HTML, and the ilk into HTML::Template templates, in  
the hopes that it would foster greater collaboration with people who  
may not know Perl, or want to deal with the sloppy coding I put forth.

Long story short, it's been very incredibly helpful in meeting this  
goal - so, go go HTML::Template!

With collaboration, one of my developers is making sure all the  
templates are XHTML compatible and is running into an issue of not  
always knowing which template outputting what code (original post:  
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/archive/dadadev/ 
20050730124002/ ) -

Does anyone have any best practices in labeling the code that each  
template creates? For example, he proposed that we simply use HTML  
comments and wrap the template itself around them. For example:

<!-- start [template_name].tmpl -->

and

<!-- end [template_name].tmpl -->

What do you guys do?

Cheers,

Justin Simoni
-- 
:: is an eccentric artist, living and working in Denver, Colorado
:: URL: http://justinsimoni.com
:: PHO: 720.436.7701
:: Mailing List - http://justinsimoni.com/mailing_list.html

[htmltmpl] ANNOUNCE: Krang 1.999

[Aaron D. <aa...@da...>]

We're pleased to announce that Krang v1.999 is now available.  This
is a test release leading up to the Krang v2.000 later this summer.
As you'll see Krang v1.999 is packed with new features!

Notable changes in this release:

  * Add-On Version 2

    The add-on v2 project is complete, bringing many improvements to the
    way Krang add-ons work. Here's a list of the biggest changes:

    * Add-ons are now located installed into a separate direction called
      "addons/". They may be developed in-place, potentially under
      separate version control.

    * Add-ons may be packaged with dependencies from CPAN in a "src/"
      directory. The Krang build system will build these modules at
      install time.

    * Add-ons may be uninstalled using the new "krang_addon_uninstaller"
      script. (This does not apply to addons installed with the old
      system.)

    * Add-ons may register new links in the left-navigation area.

    * Add-ons may selectively override core Krang classes via
      inheritance and the use of the "conf/class.conf" configuration file.

    * Add-ons may include SQL source for new tables which will be
      included in the databases built by "krang_createdb".

  * Scheduler Addons

    * Added the ability to add external scheduler addons to Krang.

    * Added conditional Scheduler link in left nav bar under admin section
      This is for non story or media related administrative scheduler
      addons. Link points to new admin scheduler screen. Allows you to use
      scheduler addons in place of external scripts run by cron.

    * Added support for Scheduler addon classes that are tied to story or
      media content. This will show up in current scheduler screen.

  * WYSIWYG HTML Editor
    Added a new element class, Krang::ElementClass::XinhaEditor, which
    offers a WYSIWYG HTML editor based on the Xinha Javascript editor.

  * Upgraded to Apache v1.3.33.
    This brings Krang up-to-date with all released Apache security
    fixes.


For more information about Krang, visit the Krang website:

  http://krang.sourceforge.net/

There you can download Krang, view screenshots, read documentation,
join our mailing-lists and access the CVS tree.

Detailed change-log here: http://krang.sf.net/docs/changelog.html

Krang is an Open Source web-publisher / content-management system
designed for large-scale magazine-style websites.  It is a 100% Perl
application using Apache/mod_perl and MySQL, as well as numerous CPAN
modules.

Krang provides a powerful and easy to use story and media editing
environment for magazine editors, as well as a complete template
development environment for web designers. On the back-end, Perl
programmers can customize Krang to control the data entered in the
story editor and add code to drive the templates to build
output. Krang can be enhanced with add-ons containing new skins and
other new features.  Krang easily handles large data sets and can
manage multiple websites in a single installation.

  - the Krang team

----
Aaron Dancygier

Re: [htmltmpl] Re: Loop Quirk???

[Michael G. <ma...@th...>]

> Ok, here goes, the onChange event kick starts the request to a perl script
> which sends back the data to for innerHTML and targets the <DIV
> id="select">.  This works np in FF.

Okay, I will freely admit that I'm out of my depth with this
XMLHTTPRequest stuff.

But I'm beginning to see what you're saying.  I had originaly thought
you meant that your TMPL_LOOP was generating the javascript.

Okay.  Now I understand that in the code:

> alert(t);
> window.getObject(name).innerHTML = t;

the 't' variable contains the complete output of your Perl cgiapp
program, as generated from a TMPL_LOOP.  Have I got that right?

If alert(t) shows what you expect, then I highly doubt that this is a
problem with HTML::Template loops.

More likely, you are either (a) generating HTML that has a subtle flaw
in it (but which is ignored by Firefox), or (b) your HTML elements are
nested in in a way that IE can't deal with.

So I guess I asked you to post the wrong part.  What you really should
be looking at is the value of 't', i.e. the rendered HTML::Template
loop; examining it for strutural or syntax problems.


Michael


--
Michael Graham <ma...@th...>

[htmltmpl] Got it

[Leander G. <le...@vi...>]

You guys rock,

Thanks for the fresh perspective and forcing me to think.

It was indeed that I was using the same var for the div repeatedly hard =
coded for testing. FF must assign a different id even when named the =
same, IE doesn't.  Regardless there is the weird string issue, but that =
is probably not related to Template As well and not something I have to =
solve at least for now.

Thanks again everyone.


Leander

[htmltmpl] Loop Quirk

[Leander G. <le...@vi...>]

You have me thinking about a couple of things, let me try another test.

-- Leander

Re: [htmltmpl] t, name var Re: Loop Quirk

[Leander G. <le...@vi...>]

To be exact I'm saying that whatever the cause is, I can't properly use =
innerHTML with internet explorer if I place the <div =
id=3D"select"></div> tag anywhere within the HTML::Template Loop.  All =
other areas are fine. FF works, don't know why.=20

Although anything is possible but  I dont' understand why it works in =
all other areas other than within an HT Loop if there are html errors.

I'll try sending the outp to a file and see what happens, however I've =
checked and everything appears to be ok as far as the first output is =
concerned.  It is with onchange event that the problem arises and IE =
doesn't seem to like the Template Loop which at that point is just html. =
 So either I have an html formatting or DOM issue with IE during the =
HTML Temp Loop creation  or like you said JS.

So far everything has come up clean. =20

Regards,


Leander


  ----- Original Message -----=20
  From: Mark Fuller=20
  To: Leander Gillard ; htm...@li...=20
  Sent: Thursday, July 21, 2005 2:53 PM
  Subject: Re: [htmltmpl] t, name var Re: Loop Quirk


  Leander,

  Are you saying that you believe H:T isn't working correctly because IE =
doesn't behave the same as other browsers? Or, are you really seeing =
H::T emit something different than you expect it to emit? That's a big =
difference. You may have invalid HTML causing IE to break (or its =
version of java script to break).

  When you say a large chunk is missing, do you mean in display? Or, =
from the actual output method of H::T? You can write the output from =
H::T to a file and examine whether it is emitting the template =
correctly.

  Mark

  ----- Original Message -----=20
    From: Leander Gillard=20
    To: htm...@li...=20
    Sent: Thursday, July 21, 2005 11:39 AM
    Subject: [htmltmpl] t, name var Re: Loop Quirk


    Hello again.

    name is unique to every row in the table iterated over during the =
initial=20
    build of the loop, t gets assigned a value from the perl script it =
calls=20
    through the xml object.

    The template works initially but it causes some confusion for =
Internet=20
    Explorer and I'm assuming the DOM structure since placing the DIV =
"select"=20
    anywhere but in the template loop works fine. As usual FF seems to =
have no=20
    trouble with any of this.

    You can try the script in FF and IE here=20
    http://project1.vianet.ca/?rm=3Dmode_203  just click on ADD and then =
choose a=20
    CID in the Select Box


    -- Leander=20



-------------------------------------------------------------------------=
-----


  No virus found in this incoming message.
  Checked by AVG Anti-Virus.
  Version: 7.0.323 / Virus Database: 267.9.2/54 - Release Date: =
7/21/2005

Re: [htmltmpl] t, name var Re: Loop Quirk

[Mark F. <mar...@ea...>]

Leander,

Are you saying that you believe H:T isn't working correctly because IE =
doesn't behave the same as other browsers? Or, are you really seeing =
H::T emit something different than you expect it to emit? That's a big =
difference. You may have invalid HTML causing IE to break (or its =
version of java script to break).

When you say a large chunk is missing, do you mean in display? Or, from =
the actual output method of H::T? You can write the output from H::T to =
a file and examine whether it is emitting the template correctly.

Mark

----- Original Message -----=20
  From: Leander Gillard=20
  To: htm...@li...=20
  Sent: Thursday, July 21, 2005 11:39 AM
  Subject: [htmltmpl] t, name var Re: Loop Quirk


  Hello again.

  name is unique to every row in the table iterated over during the =
initial=20
  build of the loop, t gets assigned a value from the perl script it =
calls=20
  through the xml object.

  The template works initially but it causes some confusion for Internet =

  Explorer and I'm assuming the DOM structure since placing the DIV =
"select"=20
  anywhere but in the template loop works fine. As usual FF seems to =
have no=20
  trouble with any of this.

  You can try the script in FF and IE here=20
  http://project1.vianet.ca/?rm=3Dmode_203  just click on ADD and then =
choose a=20
  CID in the Select Box


  -- Leander=20

[htmltmpl] Right list wrong name

[Leander G. <le...@vi...>]

My mistake sam,

I called it CGI::Template  instead of HTML::Template.

Regards.

> On Thu, 21 Jul 2005, Leander Gillard wrote:
>=20
>> Hello, I'm developing a web application using a combination of
>> CGI::App, CGI::Template, xmlHTTPreq.
>=20
> I don't see HTML::Template in that list.  Are you on the wrong
> mailing-list?
>=20
> -sam

[htmltmpl] t, name var Re: Loop Quirk

[Leander G. <le...@vi...>]

Hello again.

name is unique to every row in the table iterated over during the =
initial=20
build of the loop, t gets assigned a value from the perl script it calls =

through the xml object.

The template works initially but it causes some confusion for Internet=20
Explorer and I'm assuming the DOM structure since placing the DIV =
"select"=20
anywhere but in the template loop works fine. As usual FF seems to have =
no=20
trouble with any of this.

You can try the script in FF and IE here=20
http://project1.vianet.ca/?rm=3Dmode_203  just click on ADD and then =
choose a=20
CID in the Select Box


-- Leander=20

[htmltmpl] Re: Loop Quirk???

[Leander G. <le...@vi...>]

Ok, here goes, the onChange event kick starts the request to a perl =
script=20
which sends back the data to for innerHTML and targets the <DIV=20
id=3D"select">.  This works np in FF.

Thanks in advance.

--Leander

JS:

function loadXMLDoc(url, x_name, rmode) {
// Internet Explorer
try { this.req =3D new ActiveXObject("Msxml2.XMLHTTP"); }
catch(e) {
try { this.req =3D new ActiveXObject("Microsoft.XMLHTTP"); }
catch(oc) { req =3D null; }
}
// Mozailla/Safari
if (!req && typeof XMLHttpRequest !=3D "undefined") { req =3D new=20
XMLHttpRequest(); }
// Call the processChange() function when the page has loaded
if (req !=3D null) {
name =3D x_name;
req.open("POST", url, true);
req.send(rmode);

req.onreadystatechange =3D self.processChange;

}

}
function processChange() {

// The page has loaded and the HTTP status code is 200 OK
if (req.readyState =3D=3D 4 && req.status =3D=3D 200) {
t =3D window.req.responseText;

// when equal to 2 it will return a 1 x 2 array
if((t.charAt(0)) =3D=3D 2){

info =3D t.split(",,,");

//Need to add a method to clear divs leftover from other actions
window.redir(info[1], info[2], info[3]);


}else if((t.charAt(0)) =3D=3D 1){
// when equal to 1 it will return a 1 x 4 array

info =3D t.split(",,,");

window.getObject(name).innerHTML =3D info[1];


}else if((t.charAt(0) !=3D 1) && (t.charAt(0) !=3D 2)){

window.getObject(name).innerHTML =3D t;


}
}


}

function getObject(name) {
var ns4 =3D (document.layers) ? true : false;
var w3c =3D (document.getElementById) ? true : false;
var ie4 =3D (document.all) ? true : false;

if (ns4) return document[name];
if (ie4) return document.all[name];
if (w3c) return document.getElementById(name);
return false;
}

function redir(script, location, rm){
loadXMLDoc(script,location,rm);

}


HERE IS THE TMPL

<TMPL_LOOP NAME=3D"add_loop">
<tr bgcolor=3D"E8EEF7" onmouseover=3D"ChangeColor(this, true);"=20
onmouseout=3D"ChangeColor(this, false);">
<td width=3D"15" height=3D"10" >
<div align=3D"center">
<input type=3D"checkbox" name=3D"<TMPL_VAR ESCAPE=3DHTML =
NAME=3D"check">">
</div></td>
<td><select name=3D"<TMPL_VAR ESCAPE=3DHTML NAME=3D"cid">" =
onChange=3D"var=20
params=3D'cid=3D' + window.document.add_account.<TMPL_VAR ESCAPE=3DHTML=20
NAME=3D"cid">.value + '&amp;rm=3Dmode_205'; var=20
target=3Dwindow.document.add_account.<TMPL_VAR ESCAPE=3DHTML=20
NAME=3D"domain_target">.name; window.redir('index.cgi','select', =
params);" >
<TMPL_VAR NAME=3D"cid_info">
</select></td>
<td nowrap><div align=3D"center">
<input name=3D"<TMPL_VAR ESCAPE=3DHTML NAME=3D"fname">" type=3D"text" =
size=3D"8">
</div></td>
<td nowrap><div align=3D"center">
<input name=3D"<TMPL_VAR ESCAPE=3DHTML NAME=3D"lname">" type=3D"text" =
size=3D"8">
</div></td>
<td nowrap><div align=3D"center">
<input name=3D"<TMPL_VAR ESCAPE=3DHTML NAME=3D"uname">" type=3D"text" =
size=3D"8">
</div></td>
<td><div id=3D"select"><select id=3D"<TMPL_VAR ESCAPE=3DHTML =
NAME=3D"dom_id">"=20
name=3D"<TMPL_VAR ESCAPE=3DHTML NAME=3D"dom_id">">
<TMPL_VAR NAME=3D"domain_info">
</select></div></td>
<td nowrap><div align=3D"center">
<input name=3D"<TMPL_VAR ESCAPE=3DHTML NAME=3D"e_quota">" type=3D"text" =
size=3D"8">
</div></td>
</tr>
<tr onmouseover=3D"ChangeColor(this, true);" =
onmouseout=3D"ChangeColor(this,=20
false);">
<td width=3D"15" height=3D"10" >
<div align=3D"center">
<input type=3D"checkbox" name=3D"<TMPL_VAR ESCAPE=3DHTML =
NAME=3D"check_alt">">
</div></td>
<td><select name=3D"<TMPL_VAR ESCAPE=3DHTML NAME=3D"cid_alt">" =
onChange=3D"var=20
params=3D'cid=3D' + window.document.add_account.<TMPL_VAR ESCAPE=3DHTML=20
NAME=3D"cid">.value + '&amp;rm=3Dmode_205'; var=20
target=3Dwindow.document.add_account.<TMPL_VAR ESCAPE=3DHTML=20
NAME=3D"domain_target_alt">.name; window.redir('index.cgi',target, =
params);" >
<TMPL_VAR NAME=3D"cid_info">
</select></td>
<td nowrap><div align=3D"center">
<input name=3D"<TMPL_VAR ESCAPE=3DHTML NAME=3D"fname_alt">" =
type=3D"text" size=3D"8">
</div></td>
<td nowrap><div align=3D"center">
<input name=3D"<TMPL_VAR ESCAPE=3DHTML NAME=3D"lname_alt">" =
type=3D"text" size=3D"8">
</div></td>
<td nowrap><div align=3D"center">
<input name=3D"<TMPL_VAR ESCAPE=3DHTML NAME=3D"uname_alt">" =
type=3D"text" size=3D"8">
</div></td>
<td><select id=3D"<TMPL_VAR ESCAPE=3DHTML NAME=3D"dom_id_alt">" =
name=3D"<TMPL_VAR=20
ESCAPE=3DHTML NAME=3D"dom_id_alt">">
<TMPL_VAR NAME=3D"domain_info">
</select></td>
<td nowrap><div align=3D"center">
<input name=3D"<TMPL_VAR ESCAPE=3DHTML NAME=3D"e_quota_alt">" =
type=3D"text"=20
size=3D"8">
</div></td>
<td height=3D"10" ></td>
</tr>
</TMPL_LOOP>=20

Re: [htmltmpl] Loop Quirk??

[Sam T. <sa...@tr...>]

On Thu, 21 Jul 2005, Leander Gillard wrote:

> Hello, I'm developing a web application using a combination of
> CGI::App, CGI::Template, xmlHTTPreq.

I don't see HTML::Template in that list.  Are you on the wrong
mailing-list?

-sam

Re: [htmltmpl] Loop Quirk??

[Michael G. <ma...@th...>]

> alert(t);
> But when I set the innerHTML of a div immediately after like so.
>
> window.getObject(name).innerHTML = t;
>
> It removes a beginning chunk of the string
[snip]

Can you post the entire template code (just the loop part) and the
javascript source code that gets generated from it?

Where do 'name' and 't' get assigned?  If name doesn't change from
iteration to iteration, then maybe window.getObject(name).innerHTML
gets clobbered by an assignment in a later iteration of the loop?


Michael


--
Michael Graham <ma...@th...>

[htmltmpl] Loop Quirk??

[Leander G. <le...@vi...>]

Hello,

I'm developing a web application using a combination of CGI::App, =
CGI::Template, xmlHTTPreq.

The problem I am having is that when I get a return string from my =
xmlhttpReq request it comes back as expected, I check this like this.

alert(t);
But when I set the innerHTML of a div immediately after like so.

window.getObject(name).innerHTML =3D t;

It removes a beginning chunk of the string when trying to use innerHTML =
on a select box and just doesn't do anything using innerHTML on a =
DIV(but the div solution works for FF).  It must be noted that if I put =
the div anywhere outside of the html::template loop it then works in IE.

This seems to be IE specific or related.

Any and all help would be appreciated.

Sincerely,



Leander =20

[htmltmpl] ANN: Bricolage 1.8.6

[David W. <da...@ki...>]

     The Bricolage development team is pleased to announce the  
release of
     Bricolage 1.8.6. This maintenance release addresses numerous minor
     issues in Bricolage 1.8.5 and adds a number of improvements,  
including
     SOAP, document expiration, and bric_queued fixes. The most  
important
     changes include:

Improvements

       * Added JavaScript code to validate that the username in the user
       profile does not have leading or trailing spaces. [David]

       * Events in the event log are now returned (and displayed) in  
reverse
       chronological order. [David]

       * The SOAP server now uses a user's template sandbox when  
executing
       previews (such as with bric_soap --to-preview workflow publish).
       Reported by Marshall. [David]

       * Bric::Biz::Workflow now caches calls to allowed_desks().  
This will
       allow desks to render much Faster, since most assets on a desk  
will
       list the same desks in the "Move to" select lists. [David]

       * When the PUBLISH_RELATED_ASSETS bricolage.conf directive is
       enabled, aliases are now also republished. Only aliases that have
       previously been published will be republished, and only the last
       published version will be republished, rather than any versions
       created since the last publish. Suggested by Serge Sozonoff.  
[David]

       * A story or media document published with an expire date earlier
       than the scheduled publish time no longer bothers with the  
publish
       but just expires the story or media document. [David]

       * Media documents without an associated media file will no  
longer be
       displayed in the search results when attempting to relate a media
       document to an element. Reported by Adam Rinehart. [David]

Bug Fixes

       * Form validation and group management now properly work in  
the user
       profile. [David]

       * The SFTP mover now works with bric_queued. [David]

       * Cloned stories now properly set the published_version  
attribute to
       undef rather than the value of the original story, thus  
preventing
       the clone from having a published version number greater than its
       current version number. Reported by Nate Perry-Thistle and Joshua
       Edelstein. [David and Nate Perry-Thistle]

       * When a category is added to a story that creates a URI  
conflict,
       the new category does not remain associated with the story in the
       story profile after the conflict error has been thrown.  
Reported by
       Paul Orrock. [David]

       * Contributor groups created in the contributor profile are no  
longer
       missing from the contributor manager search interface.  
Reported by
       Rachel Murray and Scott. [David]

       * The favicon.ico works again. [David]

       * Stories are now properly expired when the BRIC_QUEUED
       bricolage.conf directive is enabled. Reported by Scott. [David]

       * When a template is checked out of the library and then the  
checkout
       is canceled, it is no longer left on the desk it was moved  
into upon
       the checkout, but properly reshelved. Reported by Marshall.  
[David]

       * Super Bulk Edit now works for media as well as stories.  
Reported by
       Scott. [David]

       * When a template is moved to a new category, the old version  
of the
       template is undeployed when the new version is deployed to the  
new
       category. The versions in the sandbox are properly synced, as  
well.

     For a complete list of the changes, see the changes list at
     http://www.bricolage.cc/news/announce/changes/bricolage-1.8.6/.  
For the
     complete history of ongoing changes in Bricolage, see  
Bric::Changes at
     http://www.bricolage.cc/docs/api/current/Bric::Changes.

     Download Bricolage 1.8.6 now from the Bricolage Website at
     http://www.bricolage.cc/downloads/, from the SourceForge  
download page
     at http://sourceforge.net/project/showfiles.php?group_id=34789, and
     from the Kineticode download page at
     http://www.kineticode.com/bricolage/downloads/.

ABOUT BRICOLAGE

     Bricolage is a full-featured, enterprise-class content  
management and
     publishing system. It offers a browser-based interface for ease- 
of use,
     a full-fledged templating system with complete HTML::Mason,
     HTML::Template, and Template Toolkit support for flexibility,  
and many
     other features. It operates in an Apache/mod_perl environment  
and uses
     the PostgreSQL RDBMS for its repository. A comprehensive,
     actively-developed open source CMS, Bricolage has been hailed as  
"quite
     possibly the most capable enterprise-class open-source application
     available" by eWEEK.

     Enjoy!

     --The Bricolage Team

[htmltmpl] Re: TT's support for methods and complex structures. Why not?

[Mark S. <ma...@su...>]

On 2005-07-18, Mark Stosberg <ma...@su...> wrote:
>
>> I really dislike systems that try to collapse hash dereferences and
>> method calls into a single syntax.  Petal does this and it drives me
>> nuts - I can never figure out what I'm looking at from the template.
>> And it does matter because methods may have side-effects and hash
>> derefs don't.
>
> I can see your point here. Should we bring back the arrow for methods?
> That seems to be the most obvious (Until Perl6 gets here). 
>
> Or we could keep the dot notation because that's where Perl6 is going, 
> and bring back the bracket notation for hashes. 

I'm thought more about this. The arrow should be avoided because ">" is
not valid HTML.

More significantly, I've come back to advocating the dot notation for
both because from the user's perspective it's an implementation detail.

As a programmer, I think I can quickly check the top level name to see
what's going on. Already we have to look at $value and guess whether
it's a string, an arrayref or a hashref.  

    Mark

-- 
http://mark.stosberg.com/ 

Re: [htmltmpl] TT's support for methods and complex structures. Why not?

[Mark S. <ma...@su...>]

On Mon, Jul 18, 2005 at 06:01:46PM -0400, Sam Tregar wrote:
> On Mon, 18 Jul 2005, Mark Stosberg wrote:
> 
> > In the current CGI::Application scheme, we solve this with mix-ins and
> > hooks for callbacks at various points. H::T seems rather mature already,
> > and I'm not suggesting making these kind of extensions to it. This seems
> > like a case where modifying the core strikes me as reasonable.
> 
> I think I'd take a patch to add a callback system like CGI::App has.
> I doubt it would be hard at all.

It's not hard. There are third-party modules to help, but recommend adding
your own, if only for a little extra performance.

> I really dislike systems that try to collapse hash dereferences and
> method calls into a single syntax.  Petal does this and it drives me
> nuts - I can never figure out what I'm looking at from the template.
> And it does matter because methods may have side-effects and hash
> derefs don't.

I can see your point here. Should we bring back the arrow for methods?
That seems to be the most obvious (Until Perl6 gets here). 

Or we could keep the dot notation because that's where Perl6 is going, 
and bring back the bracket notation for hashes. 

    Mark

-- 
http://mark.stosberg.com/ 

Re: [htmltmpl] TT's support for methods and complex structures. Why not?

[Sam T. <sa...@tr...>]

On Mon, 18 Jul 2005, Mark Stosberg wrote:

> In the current CGI::Application scheme, we solve this with mix-ins and
> hooks for callbacks at various points. H::T seems rather mature already,
> and I'm not suggesting making these kind of extensions to it. This seems
> like a case where modifying the core strikes me as reasonable.

I think I'd take a patch to add a callback system like CGI::App has.
I doubt it would be hard at all.

> > Yes, I think that would be the easiest way.  HTML::Template::Expr
> > exploits code-ref variables to offer function calls, so why not
> > methods too?
> 
> Are you suggesting that the method technique may make sense to add to
> HTML::Template::Expr ? 

Possibly.  The bar for new features in ::Expr is pretty low.  There's
already so much in there not to like that a little more can't hurt!

> The template system has to know what 'defined' means here to parse it. 
> I'm suggesting:
> 
>  <TMPL_IF foo.is_defined>
> 
> As now, we just need to check to see if we have "foo" to use, and
> quickly check to see to if it's a object or a complex data structure to
> see what to do with the bit after the dot.

I really dislike systems that try to collapse hash dereferences and
method calls into a single syntax.  Petal does this and it drives me
nuts - I can never figure out what I'm looking at from the template.
And it does matter because methods may have side-effects and hash
derefs don't.

-sam

Re: [htmltmpl] TT's support for methods and complex structures. Why not?

[Mark S. <ma...@su...>]

On Mon, Jul 18, 2005 at 05:34:01PM -0400, Sam Tregar wrote:
> > 
> > I'm also more interested in number 1 than number 2. Do you mean "get
> > behind" as in: "go forth and prepare a patch ye feature requester"
> 
> I guess I mean if there was a module on CPAN that did this I might use
> it.  I'm not presently inclined to include it in the core module, if
> only because it's obviously something that would be easy to do in a
> sub-class.

I've learned by following the developments of modules such as
WWW::Mechanize and CGI::Application and Data::Page that subclass'ing
isn't always a good solution. The problem arises when two people have
good ideas for sub-classes and each release their own. As long as you
just need one feature, it's OK. If you want both, it seems like an
awkward situation if not impossible situation. What if two sub-classes
both overrode param() with an interesting and non-overlapping features? 

In the current CGI::Application scheme, we solve this with mix-ins and
hooks for callbacks at various points. H::T seems rather mature already,
and I'm not suggesting making these kind of extensions to it. This seems
like a case where modifying the core strikes me as reasonable.

> > Wouldn't the method call support be sort of like coderef support that is
> > already there?
> 
> Yes, although I'd wager that the percentage of anonymous subs that
> have side-effects is much lower than the percentage of methods that
> have side-effects.  I realize that either one could but methods just
> seem more likely to encourage this abuse.

I would say "encourage", but it doesn't actively try to prevent it
either. My take is that these kind of quality issue that should be in
hands of the programmer to deal with, and not of H::T's concern. Much
like if they use H::T in combination with many global variables or bad
indentation. 

> Although, if you want to get to the heart of the matter, code-ref
> variables were not my idea.  I added them in response to a majority of
> the users declaring their interest.  Sometimes I do that...
> 
> > It seems like it might even be implemented like that: as as callback
> > which gets the method name passed in as a parameter.
> 
> Yes, I think that would be the easiest way.  HTML::Template::Expr
> exploits code-ref variables to offer function calls, so why not
> methods too?

Are you suggesting that the method technique may make sense to add to
HTML::Template::Expr ? 

Personally, I'm a purist and haven't yet used ::Expr for a project. 

The syntax would be a little different, but I think in a key way. Here's
how ::Expr uses functions:

 <TMPL_IF expr="defined(foo)">

The template system has to know what 'defined' means here to parse it. 
I'm suggesting:

 <TMPL_IF foo.is_defined>

As now, we just need to check to see if we have "foo" to use, and
quickly check to see to if it's a object or a complex data structure to
see what to do with the bit after the dot.


    Mark

Re: [htmltmpl] TT's support for methods and complex structures. Why not?

[Sam T. <sa...@tr...>]

On Mon, 18 Jul 2005, Mark Stosberg wrote:

> > #1 I can get behind.  #2 makes me itch.  There's a high potential for
> > abuse here since methods can have side-effects which would break the
> > straight data-path from code to template to output.
> 
> I'm also more interested in number 1 than number 2. Do you mean "get
> behind" as in: "go forth and prepare a patch ye feature requester"

I guess I mean if there was a module on CPAN that did this I might use
it.  I'm not presently inclined to include it in the core module, if
only because it's obviously something that would be easy to do in a
sub-class.

> In between the coder the designer is some kind of understanding about
> what valid token names are, usually provided by the programmer.
> 
> I think most often this communication is implicit because the programmer
> puts the tokens in the document in the first place. In this case,
> exactly how the tokens came to be isn't interest to the designer.

Right on.

> Wouldn't the method call support be sort of like coderef support that is
> already there?

Yes, although I'd wager that the percentage of anonymous subs that
have side-effects is much lower than the percentage of methods that
have side-effects.  I realize that either one could but methods just
seem more likely to encourage this abuse.

Although, if you want to get to the heart of the matter, code-ref
variables were not my idea.  I added them in response to a majority of
the users declaring their interest.  Sometimes I do that...

> It seems like it might even be implemented like that: as as callback
> which gets the method name passed in as a parameter.

Yes, I think that would be the easiest way.  HTML::Template::Expr
exploits code-ref variables to offer function calls, so why not
methods too?

-sam

Re: [htmltmpl] TT's support for methods and complex structures. Why not?

[Mark S. <ma...@su...>]

Thanks for a response Sam. 

On Mon, Jul 18, 2005 at 05:10:07PM -0400, Sam Tregar wrote:
> On Mon, 18 Jul 2005, Mark Stosberg wrote:
> 
> > There are a couple features of TT that seem reasonable to support, and
> > seem at first glance like things that an be added while maintaining
> > compatibility.
> > 
> > 1. Support for complex data structures.
> >
> > 2. Method calls.
> 
> Isn't there something on CPAN to enable this yet?  Everytime someone
> asks I point out how easy this would be with an overridden param() in
> a sub-class.  I figured someone would have gotten on it by now!
> 
> > To me, these additions wouldn't violate the integrity of H::T's
> > philosophy, which I interpret as being about keeping the tag language as
> > simple as possible.
> 
> #1 I can get behind.  #2 makes me itch.  There's a high potential for
> abuse here since methods can have side-effects which would break the
> straight data-path from code to template to output.

I'm also more interested in number 1 than number 2. Do you mean "get
behind" as in: "go forth and prepare a patch ye feature requester"
 
> > They simply give the programmers more power and freedom expression, and
> > can help prevent extra hoop jumping when you have an complex data
> > structure or an object that need to hook up with the template anyway.
> 
> HTML::Template isn't really about power and freedom of expression.  I
> think TT or EmbPerl are more appropriate for someone that wants those.
> HTML::Template is more about simplicity and reasonable constraints on
> expression.  I think of my user-base as being composed in equal parts
> Perl coders and HTML designers.  Power and freedom of expression may
> help the Perl coder but they're nothing but trouble for your HTML
> designer!

In between the coder the designer is some kind of understanding about
what valid token names are, usually provided by the programmer.

I think most often this communication is implicit because the programmer
puts the tokens in the document in the first place. In this case,
exactly how the tokens came to be isn't interest to the designer.

Wouldn't the method call support be sort of like coderef support that is
already there? It seems like it might even be implemented like that: as
as callback which gets the method name passed in as a parameter.

    Mark

Re: [htmltmpl] TT's support for methods and complex structures. Why not?

[Sam T. <sa...@tr...>]

On Mon, 18 Jul 2005, Mark Stosberg wrote:

> There are a couple features of TT that seem reasonable to support, and
> seem at first glance like things that an be added while maintaining
> compatibility.
> 
> 1. Support for complex data structures.
>
> 2. Method calls.

Isn't there something on CPAN to enable this yet?  Everytime someone
asks I point out how easy this would be with an overridden param() in
a sub-class.  I figured someone would have gotten on it by now!

> To me, these additions wouldn't violate the integrity of H::T's
> philosophy, which I interpret as being about keeping the tag language as
> simple as possible.

#1 I can get behind.  #2 makes me itch.  There's a high potential for
abuse here since methods can have side-effects which would break the
straight data-path from code to template to output.

> They simply give the programmers more power and freedom expression, and
> can help prevent extra hoop jumping when you have an complex data
> structure or an object that need to hook up with the template anyway.

HTML::Template isn't really about power and freedom of expression.  I
think TT or EmbPerl are more appropriate for someone that wants those.
HTML::Template is more about simplicity and reasonable constraints on
expression.  I think of my user-base as being composed in equal parts
Perl coders and HTML designers.  Power and freedom of expression may
help the Perl coder but they're nothing but trouble for your HTML
designer!

-sam

[htmltmpl] TT's support for methods and complex structures. Why not?

[Mark S. <ma...@su...>]

I hope this isn't a broken-record question.

There are a couple features of TT that seem reasonable to support, and
seem at first glance like things that an be added while maintaining
compatibility.

1. Support for complex data structures. Flattening is no longer necessary
   to do a separate step. It's like H::T users are able to skip this
   step anyway. We either do it by hand, or use something like
   Data::Grouper.

   In TT, if you give it a hashref that looks like { a => { b => c} }

   Then you can directly access "c" as "a.b.c". 

   I like that.

2. Method calls. In TT you can pass this into your template:   
  
   shopcart => My::Cool::Shopping::Cart->new(),

   And then access methods on the shopping cart object like this

   shopcart.total 


To me, these additions wouldn't violate the integrity of H::T's
philosophy, which I interpret as being about keeping the tag language as
simple as possible.

They simply give the programmers more power and freedom expression, and
can help prevent extra hoop jumping when you have an complex data
structure or an object that need to hook up with the template anyway.

    Mark
 

Re: [htmltmpl] (no subject) [Patch]

[Sam T. <sa...@tr...>]

On Wed, 13 Jul 2005, Emanuele Zeppieri wrote:

> Here it is Sam.

Awesome!  I'll take a closer look soon.  If you don't hear from me in
a few days please feel free to nag.

-sam

Re: [htmltmpl] (no subject)

[Jochen C. <htm...@dh...>]

>>
>>>Well, I'm probably missing something (or everything), but 
>>it seems to me
>>
>>>that the following compiled code layout could solve the problem:
>>>
>>>	JUMP to A IF false
>>>	... # first true instruction
>>>	...
>>>	... # last true instruction
>>>	JUMP TO B
>>>A: 	... # first false instruction
>>>	...
>>>	... # last false instruction
>>>B:	... # normal execution after the IF/ELSE, if any...
>>
>>Yup, that would do it.  That's much easier than trying to store state
>>from the first one.  So, when can I see a patch?
> 
> 
> Well, I just didn't want to steal such a privilege to the person who
> originally pointed out this issue ;-)
> 
> Joking apart, I'll be more than happy to work on a patch, as soon as my
> clients give me a break and my newborn first son here will stop crying!
> 
> Any further hint about it?
> 
> --Emanuele.

Hey cool,

So I just have to wait ;)


right now my workaround does a regexp and replace the rand function with 
the value of the evaluated part...
so a <tmpl_if expr="int(rand(10))"> becomes a <tmpl_if 
expr="int(4.3332)"> or something similar. Thats fair enought, but 
anyway, only usable on a few steps... so sometimes I do a fallback onto 
the current timestamp (milliseconds).

But as I say thats only a workaround (read the file, precompile, give it 
to HTML::Template::Expr)


Bye,