Re: Template feature possibility

[dean]

On Dec 15, 2003, at 9:54 PM, Robert Moser II wrote:

> > On Dec 14, 2003, at 10:00 PM, Dan Sully wrote:
> >> Template Toolkit - http://www.template-toolkit.org/ is my prefered
> >> solution, and already has a syntax very like what the SlimServer
> >> already has. I'm not wanting to get into template system wars here.
>
> to which dean blackketter blurted out:
>
>> I have no problem with this at all. We'll need to move over all the
>> existing skins...
>> Volunteers?
>
> I've been looking at it, and it seems very powerful.
> For minimal disturbance we should probably try to bend it into
> a drop-in replacement for our home-brew template system.
Agreed. The best thing would be to have a tool that we could run over
the skins to upgrade them to the new syntax.

> Once we've had more of a chance to explore the possibilities, we could
> rework the whole HTTP interface to fully leverage this tool. Off hand,
> I'm thinking of making some custom Slim specific Template::Plugins
> which would expose all the information to the templates.
>
> Something like:
> [% USE Library %]
> <table>
> [% FOREACH genre = Library.genres %]
> <tr><td><a href="browseid3.html?song=&artist=&album=&genre=
> [% genre.name %]&player=[% player.id %]">[% genre.name %]</a><td>
> <td><a href="status.html?p0=playlist&p1=addalbum&p2=
> [% genre.name %]&p3=&p4=&player=[% player.id %]" target="status">
> </td></tr>
> [% END %]
> </table>
>
> naturally an actual template would be much more involved.

Neat. Robert or Dan: Any idea what the performance impact would be
in moving to this system?

-dean

[Dan Sully]

* dean blackketter <dean (AT) slimdevices (DOT) com> shaped the electrons to say...

> Agreed. The best thing would be to have a tool that we could run over
> the skins to upgrade them to the new syntax.

Yes, quite.

> Neat. Robert or Dan: Any idea what the performance impact would be
> in moving to this system?

I'm not sure yet. I haven't looked at the current template system in
depth. But I suspect it's something like $template =~ s/TOKEN/$value/
at the core level. Which depending on the number and size of the
operation will likely be faster. I can do some benchmarks if needed.

-D
--
Any technology sufficiently advanced is indistinguishable from a perl script.

[Robert Moser II]

Dan Sully blurted out:

> * dean blackketter <dean (AT) slimdevices (DOT) com> shaped the electrons to say...
>>Neat. Robert or Dan: Any idea what the performance impact would be
>>in moving to this system?

I've never used it, I've just skimmed some of the docs for it.

> I'm not sure yet. I haven't looked at the current template system in
> depth. But I suspect it's something like $template =~ s/TOKEN/$value/
> at the core level. Which depending on the number and size of the
> operation will likely be faster. I can do some benchmarks if needed.

It is somewhat like that, although it actually performs a list of s///
functions, one for each of our directives.

As for performance impact, the best test is to make yourself a nice huge
playlist (I've done around 7k items), set your itemsPerPage to be more
than the number of items in your list, then curl playlist.html from the
default skin. Note that you pretty much have to use curl, as no browser
I've tried has been able to handle the huge (~10MB for my 7k list) files
which are generated.

On my system the current method can spit it out in around 15 seconds
without interrupting the music. I'd say that the actual time to
generate isn't so important, as long as the music keeps flowing.

Doing the skins doesn't seem too hard, it has a built in a flow-down
path strategy (if the template isn't in the top path, it moves to the
next one in the list). Doing the skin override ability is a bit
trickier, but I think it would be doable with an extended
Template::Provider object.

[Dan Sully]

* Robert Moser II <rlmoser (AT) earthlink (DOT) net> shaped the electrons to say...

> It is somewhat like that, although it actually performs a list of s///
> functions, one for each of our directives.
>
> As for performance impact, the best test is to make yourself a nice huge
> playlist (I've done around 7k items), set your itemsPerPage to be more
> than the number of items in your list, then curl playlist.html from the
> default skin. Note that you pretty much have to use curl, as no browser
> I've tried has been able to handle the huge (~10MB for my 7k list) files
> which are generated.

Right - I'd want to a programatic benchmark though.

-D
--
Any technology sufficiently advanced is indistinguishable from a perl script.