Template::Toolkit::Session

[mitd]

I have just spent a delightful few days re-doing the mitd personal website with the Template::Toolkit/Apache::Template and MySQL. Finally a server-side technology I can learn to love.

I was little suprised when I found that there was no Session management plugin **??** available as of yet. So I decided to start building it myself. Andy's suggested method of package naming (Mitd::Template::Plugin::Session) but I believe that it belongs in the core plugings Template::Plugin::Session.

There have some differing opinions. One perly friend of mine offers up that TT is a content management tool and therefore session management doesn't belong in core deliverable. I disagree. What you folks think?

In any case Andy's plugin interface so simple and elegant that it begs for adding functionality that could include the kitchen sink :)

mitd-Made in the Dark
'Interactive! Paper tape is interactive!
If you don't believe me I can show you my paper cut scars!'

[ajt]

mitd,

I'm not a TT2 user, but it's NOT a Content Managment System. It's a Content Production System, and afaik it's a very good one.

See Re: Content management system recommendations? to see how I define a CMS. CMS space is very muddled and confused, with everything including a kitchen-sink claiming to be a CMS. To my mind, a CMS is something that manages content, not something that runs a web site.

My humble 2p.

[mitd]

ajt oh 'Goat Toes' you are of course correct. Twas I who mis-quoted my friend. ( A prank phone-call was duly received in revenge). And horsey chocolates, production and management don't even rhyme.

mitd-Made in the Dark
'Interactive! Paper tape is interactive!
If you don't believe me I can show you my paper cut scars!'

[lachoy]

This depends on how much work you want the template to do. It's one thing to create a session and provide it to the template. It's another to have the template do all the work.

FWIW, I tend strongly toward the first option. Decoupling the display of the data and the manipulation of the data will pay off in the long run. (perrin always has good arguments about this on the relevant mailing lists)

That said, the Apache::Template module is very straightforward and encourages this sort of action, since it's template-driven rather than code driven. Creating a session plugin would be fairly simple and wouldn't seem to affect much else. So I'd say go ahead and create it -- since it's independent it shouldn't be too much trouble to replace it later if you find it doesn't meet your needs.

Chris
M-x auto-bs-mode

[clemburg]

Do *you* think it makes sense to create this plugin? Do what *you* think is right. Do not let people stifle your creativity with hastily said comments. *You* must weight costs and benefits.

BTW, have a look at OpenInteract written by brother lachoy. Might give you some hints.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

[simon.proctor]

From what you have said, the Session plugin you have written affects the content displayed (if user has this.... if user has that... then display this...). If that assumption is correct then I would argue your module is affecting what is displayed and not how the core engine operates in creating that display.

If that assumption holds true then your plugin should, IMHO, follow the standard plugin structure that every other plugin follows.

I agree with the distinction made between content production and content management. I feel this distinction holds true to your plugins purpose (management not production).

Perhaps this plugin is something you could post into craft (or here) so we can see it?

But....thats just my opinion :) Have fun!

PS: I would argue that its equally as valid to instantiate your module as an object in your main code and pass it as a var in the template setup. But that really depends on the structure of your plugin.

[perrin]

As lachoy said, I think application logic like session handling should be done outside of TT. You should do this in your perl code and then call TT, passing in the data that you want it to display.

I'm kind of opposed to the existence of Apache::Template, since it leads people to try and shove all of their application logic into the templates instead of in perl code where it belongs. However, there is a better way to use Apache::Template that provides more separation. You can subclass it and add your application logic (in this case session handling) in your subclass. Take a look at TT2ServiceModule and the information there about subclassing.

[mattr]

Well, it's up to you but I for one can say I would very much like to see your code wherever you end up putting it. Not enough of this out there now. Even putting it just inside documentation would be acceptable to me, but an easy to instantiate solution would become pretty popular I'd imagine.