Re^3: RFC: Templating without a System

Additional Modules, which I am supposed to package, additionally, to my own stuff. Make sure they work on the target system. Dependecies beyond the perl core.

sorry, but you say you do "Templating without a System". What is a "system" for you?

HTML::Template (or HTML::Template::Compiled, to mention my own module) are just a couple of files containing perl-code (also called pure-perl modules). You don't want to be dependant on these, but you write your own Servlet.pm? (and you consider the mentioned modules "systems", but not your Servlet.pm?)

I can't see what the above mentioned modules couldn't do for you. Only parameter passing is a bit more work, but I consider it to be more clean to pass parameters explicitly than to refer to real perl variables in a template.

Comment on Re^3: RFC: Templating without a System

Replies are listed 'Best First'.
Re^4: RFC: Templating without a System by shmem (Chancellor) on Jun 18, 2006 at 15:01 UTC
I can't see what the above mentioned modules couldn't do for you. What can those modules do for you what Servlet.pm can't? The answer probably makes up the reason why I call HTML::Template a templating system. You don't want to be dependant on these, but you write your own Servlet.pm? I wrote that module, lumped it to the other files of that app and done. It did what I wanted. I guess it was - as often - laziness at the wrong subject, and reading the manual pages of the various templating systems or toolkits or whatever to understand how they do their basics (and how I can get at them quickly) and see if they fit my needs probably would have saved my day and I would have chosen one. Only parameter passing is a bit more work, but I consider it to be more clean to pass parameters explicitly than to refer to real perl variables in a template. Servlet.pm does that. By default you have to pass it's parameters explicitly. It does `use strict;` which causes death at compile time if the variables in the servlet aren't passed in via the `args` argument at servlet creation. (~~It would die at runtime if it is called without the right parameter list if I prototyped the sub on creation.~~ <--(update) nope, prototype check only at compile time) merlyn pointed out the two reasons why a mini-language or an additional abstraction layer for variables makes sense. For other cases it is just overhead, I guess. greetings, --shmem	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: RFC: Templating without a System
by shmem (Chancellor) on Jun 18, 2006 at 15:01 UTC

I can't see what the above mentioned modules couldn't do for you.

What can those modules do for you what Servlet.pm can't? The answer probably makes up the reason why I call HTML::Template a templating system.

You don't want to be dependant on these, but you write your own Servlet.pm?

I wrote that module, lumped it to the other files of that app and done. It did what I wanted. I guess it was - as often - laziness at the wrong subject, and reading the manual pages of the various templating systems or toolkits or whatever to understand how they do their basics (and how I can get at them quickly) and see if they fit my needs probably would have saved my day and I would have chosen one.

Only parameter passing is a bit more work, but I consider it to be more clean to pass parameters explicitly than to refer to real perl variables in a template.

Servlet.pm does that. By default you have to pass it's parameters explicitly. It does use strict; which causes death at compile time if the variables in the servlet aren't passed in via the args argument at servlet creation. (~~It would die at runtime if it is called without the right parameter list if I prototyped the sub on creation.~~ <--(update) nope, prototype check only at compile time)

merlyn pointed out the two reasons why a mini-language or an additional abstraction layer for variables makes sense. For other cases it is just overhead, I guess.

greetings,
--shmem

[reply]
[d/l]
[select]