Alex,

Some things, once you start thinking about them, seem better off in the template and template parser, than in the code, or plug-in module, especially a _display hook, that will go off each time, whether needed or not.

Specfic example:

With the multiple attachments module, I need a whole bunch of _display hooks, but mainly have to worry about link.html and detailed.html where the "link" data is being processed.

If a link "hasAttachments" then I need to do a "select" from the attachments table, and create an array of hashes "elements" for the <%loop%> routine, just like for link_results.

Would it be "better" to do this in the template, where "hasAttachments" can actually be checked? Or would it be better off as a _display call, that is executed for every "link" and which has to check whether "hasAttachments" is positive?

<%if hasAttachments%>
<%execute function get_attachments%>
<%loop elements%>
<%include element.txt%>
<%endloop%>
<%endif%>

Or, via the _display hook: "get_attachments"

my $link =shift;
if ($link->{'hasAttachments'}) {big do block of code}
return $link;

and then:
<%if elements%>
<%loop elements%>
<%include element.txt%>
<%endloop%>
<%endif%>


??

The template version has obvious appeal, but is that expecting too much of the template parser, and the plug-in call is "less expensive" even if called when not needed?

BTW... I could add functions to the template global.txt file during install, by reading in that file with the datadumper code, checking for the existence of the tag I want to add, adding the tag, then dumping it back out, right?? No problems there?? (obviously, default template set only)



PUGDOG® Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum

Hi,

The template parser is very quick, and it won't run functions that are in a negative if statement, so if you had:

<%if hasAttachments%>
<%Plugins::MultipleUpload::get_attachments%>
<%loop elements%>
<%include element.txt%>
<%endloop%>
<%endif%>

the if hasAttachments is false, the template parsers isn't even going to look at anything except for the closing endif tag. I think this would be a better solution then using a hook as it makes it obvious to the user what's going on.

As for globals, yes you would:

my $globals = do "$CFG->{admin_root_path}/templates/default/globals.txt";
$globals->{newkey} = "newvalues";
open (FILE, "> $CFG->{admin_root_path}/templates/default/globals.txt");
print FILE GT::Dumper::dump ( data => $globals, var => '' );
close FILE;

should do the trick.

Cheers,

Alex

--
Gossamer Threads Inc.

>> The template parser is very quick

I remember you saying that in an announcement awhile back, which is why I
wanted to check just how fast ;)


>> I think this would be a better solution then using a hook as
>> it makes it obvious to the user what's going on.

That's what I wanted to check :) Putting this sort of <%loop%> in the template,
really does make things a lot clearer, and a lot simpler, since if someone needs
to add the attachments to another template, it's just a few template tags, not
fiddling with plug-in code, and the code is only executed based on a value in the
passed data. Additionally, less data gets passed, fewer calls (both necessary and
unnecessary) are made, and things look cleaner, and should work more efficiently.

When you start thinking this way, it starts to make sense, using the scripts to
output the main point of the template, but let the template make decisions about
the "design".

The template parser is sort of a version of mod_php and emb_perl, since the
templates can now include instructions to execute, not just layout data that was
sent to them via a back-end cgi process.

I haven't yet exploited all the potential, but it's one more step towards unlinking
the data and function from the layout & design.



PUGDOG® Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum

Just from a users point of view, I think you're correct in removing the design from the code as much as possible.

When designing my site, I spent quite a lot of time trying to find display tags that were inside the code, such as <ul> or <td> tags that were unwanted for my particular design. Every time there's an upgrade, I have to rack my brain trying to remember where I found the appropriate tags and make sure to edit it again or my site displays wrong.

Bryan