You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Terry Steichen <te...@net-frame.com> on 2002/05/06 16:06:15 UTC
The Role of Templates
Many of the issues on this list involve questions of whether a given capability is appropriate for inclusion in a template, or whether it should reside in the underlying, driving business logic. Yesterday, Geir offered the following comments/thoughts:
"To me, the difference between templating and scripting is fundamentally the
difference between 'uses' and 'is used by'."
"With templating, the designer creates an entity (the template) that will be
used by 'something else' to render or output data in a format or pattern
dictated by the template. Also, I think personally that the templating
system should be as simple as possible, not because designers are 'stupid'
or anything, but because you are forcing them to work in a system for which
skills therein are of secondary importance to the skills of the primary
activity, the organization and presentation of information. Of course,
programmers also use the templating system, and there lies the rub, I
believe."
"I see scripting as more of a general purpose 'control' system where the use
is completely general - you can use it to output and format data, you can
use it to control other subsystems, etc. The feature set therefore has to
be richer, as the intended usage is general."
I'd like to take this opportunity to expand on this with some of my own thoughts (which others will hopefully expand on too). I believe this is important because it is at the core of so many issues we discuss.
The importance of using templates comes from the ability they provide to allow the layout and presentation logic to be created and maintained independent of the underlying programming logic. This separation allows each discipline (presentation designer and business logic programmer) to focus more sharply on their aspect of the application with less risk of either inadvertently creating errors in the other aspect.
Though their role lies in layout and presentation, templates must have a certain programmatic capability to handle tasks like (1) handling a variable number of rows/records, and (2) hiding/displaying menu choices for different users.
The 'grey' areas (as to whether a function is best implemented by the template or business logic) include tasks like (1) formating numbers, (2) skipping rows, and (3) implementing decision logic involving dates, float/decimal numbers, etc. The tradeoff is basically more template complexity versus reusability of business logic. In some cases if the business logic is kept more generic, it can be used with multiple templates (as long as the templates have enough 'smarts' to do the refined processing). In other cases, it is far more efficient to embed this logic in the business logic modules themselves.
Template systems like Velocity also allow very rapid development practices, primarily because of their ability to expose business logic objects to the template, where the template has a decent set of built-in directives and macro capability. This option is driven by the really big advantage - no compilation required. With Velocity in particular (since it is the one I know best), you have the option to easily migrate the business logic back to the programming module when the initial development has been completed - a wonderful option, to be sure.
As I see them, scripts generally replace the program module plus template. Scripts tend to employ higher-level languages (compared to the programming module). They too help in rapid development, because they usually do not require a compilation step. But they do not provide the separate focus for designers and programmers.
Just my $0.02.
Regards,
Terry Steichen
Re: The Role of Templates
Posted by Peter Sojan <il...@gmx.net>.
On Mon, May 06, 2002 at 10:06:15AM -0400, Terry Steichen wrote:
I just want to add my two cents here.
I think the term "business logic" is not being used correctly here.
>From a multi-tiered architecture point of view business logic
should *never ever* interact with templating mechanisms on the
presentation tier, because the business logic is neutral with
regards to User Interfaces. That is, business logic is (or should) not
be aware of whether the user interface is a web client or a terminal
or something else.
However, it is a common misconception that there should be no "logic" at the
presentation tier -> as practice shows this is not true. When we take
a Web-frontend there's plenty of logic we must take care of, for example session
management (due to stateless nature of HTTP), processing of user
input (validation of form input), view building etc. All this is located
at the presentation tier because it's frontend specific. Template engines
such as Velocity are "just another component" at the presenation tier,
which is responsible for a specific task namely something what I call
"markup generation".
So, in my opinion we have at the presentation tier a part which handles
all those programmatic things ("logic") and we have Velocity for markup
generation (which has its own "mini-language" for handling "markup-logic".)
Since both parts are responsible for "presentational things" is is perfectly
valid that they interact if necessary (e.g. template calls a method for
converting dates). This is where most people see a problem, because they think
they mix business-logic with presentational things, but remember that the
"business-tier" is still far away in this scenario, all this happens at the
presentation tier ...
any comments !?
Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Role of Templates
Posted by Terry Steichen <te...@net-frame.com>.
Please see my 2 comments (==>TS) below.
Regards,
Terry
On 5/7/02 10:39 PM, "Geir Magnusson Jr." <ge...@adeptra.com> wrote:
<stuff snipped>
> > The 'grey' areas (as to whether a function is best implemented by the
template
> > or business logic) include tasks like (1) formating numbers, (2)
skipping
> > rows, and (3) implementing decision logic involving dates, float/decimal
> > numbers, etc. The tradeoff is basically more template complexity versus
> > reusability of business logic. In some cases if the business logic is
kept
> > more generic, it can be used with multiple templates (as long as the
templates
> > have enough 'smarts' to do the refined processing). In other cases, it
is far
> > more efficient to embed this logic in the business logic modules
themselves.
>
> Once business logic crosses into the template, I think you are asking for
> problems.
==>TS: This 'rule' should not be absolute. For example, let's say that your
business logic generates a list of user accounts. Template A needs to show
only certain attributes of all users. Template B wants to show all
attributes but only for users having a specific characteristic B. Template
C wants to show only certain attributes of users having characteristic C. A
'pure' separation approach would call for three business logic modules, each
linked to the three templates. But if you make the templates sufficiently
intelligent, one business module can drive all three. Go a step further and
you might be able to end up with one business logic module and one template.
The decision on where to put the discriminating logic depends not only on a
philosophical view of where it 'should' belong, but on the potential for
reusing the business logic (and of course, the performance penalty that
might be involed). And, of course, you need to keep in mind that if you
make the templates too 'smart' they will be harder to maintain (particularly
be designers rather than programmers).
<stuff snipped>
> > Template systems like Velocity also allow very rapid development
practices,
> > primarily because of their ability to expose business logic objects to
the
> > template, where the template has a decent set of built-in directives and
macro
> > capability. This option is driven by the really big advantage - no
compilation
> > required. With Velocity in particular (since it is the one I know
best), you
> > have the option to easily migrate the business logic back to the
programming
> > module when the initial development has been completed - a wonderful
option,
> > to be sure.
>
> And this is an area we are are lacking, I believe. It's harder in
Velocity
> to slap together a set of objects in a page for the most part - you need
> some kind of servlet that populates the context from an external list or
> something, or provide enough that you can bootstrap the rest - some kind
of
> class factory.
==>TS: I *am* using a servlet dispatcher (It happens to be Enhydra, but it
could be any). For each received request, the dispatcher instantiates the
appropriate action module (called a presentation object in the Enhydra
architecture), which in turn manages the associated Velocity template. In
this context, I see nothing lacking at all. (Is Geir getting overly humble
one me??) That's the essence of my point - by having the action module
manage the Velocity template, I am free to move the business logic smoothly
and easily back and forth (through the context) as is appropriate for the
development mode I'm in (fast prototyping or long-term production).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Role of Templates
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/8/02 10:28 AM, "Nathan Bubna" <na...@esha.com> wrote:
> Geir said:
>> Terry said:
>>> Template systems like Velocity also allow very rapid development
> practices,
>>> primarily because of their ability to expose business logic objects to
> the
>>> template, where the template has a decent set of built-in directives and
> macro
>>> capability. This option is driven by the really big advantage - no
> compilation
>>> required. With Velocity in particular (since it is the one I know
> best), you
>>> have the option to easily migrate the business logic back to the
> programming
>>> module when the initial development has been completed - a wonderful
> option,
>>> to be sure.
>>
>> And this is an area we are are lacking, I believe. It's harder in
> Velocity
>> to slap together a set of objects in a page for the most part - you need
>> some kind of servlet that populates the context from an external list or
>> something, or provide enough that you can bootstrap the rest - some kind
> of
>> class factory.
>>
>> #set($thing = $tool.make("java.util.ArrayList"))
>
> it's probably true that velocity is still lacking here, but a good bit of
> progress on this has been made recently in the velocity-tools subproject.
> the XMLToolboxManager i just submitted (not in the repository yet) is a
> strong step toward meeting this need, and if you want to go with the servlet
> option, then try out VelocityViewServlet.
I am certainly hoping that one of the things we can build around VVS is a
prototyping framework, to remove that criticism of the templating
approach...
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Role of Templates
Posted by Nathan Bubna <na...@esha.com>.
Geir said:
> Terry said:
> > Template systems like Velocity also allow very rapid development
practices,
> > primarily because of their ability to expose business logic objects to
the
> > template, where the template has a decent set of built-in directives and
macro
> > capability. This option is driven by the really big advantage - no
compilation
> > required. With Velocity in particular (since it is the one I know
best), you
> > have the option to easily migrate the business logic back to the
programming
> > module when the initial development has been completed - a wonderful
option,
> > to be sure.
>
> And this is an area we are are lacking, I believe. It's harder in
Velocity
> to slap together a set of objects in a page for the most part - you need
> some kind of servlet that populates the context from an external list or
> something, or provide enough that you can bootstrap the rest - some kind
of
> class factory.
>
> #set($thing = $tool.make("java.util.ArrayList"))
it's probably true that velocity is still lacking here, but a good bit of
progress on this has been made recently in the velocity-tools subproject.
the XMLToolboxManager i just submitted (not in the repository yet) is a
strong step toward meeting this need, and if you want to go with the servlet
option, then try out VelocityViewServlet.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Role of Templates
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/6/02 10:06 AM, "Terry Steichen" <te...@net-frame.com> wrote:
> Many of the issues on this list involve questions of whether a given
> capability is appropriate for inclusion in a template, or whether it should
> reside in the underlying, driving business logic. Yesterday, Geir offered the
> following comments/thoughts:
>
> "To me, the difference between templating and scripting is fundamentally the
> difference between 'uses' and 'is used by'."
>
> "With templating, the designer creates an entity (the template) that will be
> used by 'something else' to render or output data in a format or pattern
> dictated by the template. Also, I think personally that the templating
> system should be as simple as possible, not because designers are 'stupid'
> or anything, but because you are forcing them to work in a system for which
> skills therein are of secondary importance to the skills of the primary
> activity, the organization and presentation of information. Of course,
> programmers also use the templating system, and there lies the rub, I
> believe."
>
> "I see scripting as more of a general purpose 'control' system where the use
> is completely general - you can use it to output and format data, you can
> use it to control other subsystems, etc. The feature set therefore has to
> be richer, as the intended usage is general."
>
> I'd like to take this opportunity to expand on this with some of my own
> thoughts (which others will hopefully expand on too). I believe this is
> important because it is at the core of so many issues we discuss.
>
> The importance of using templates comes from the ability they provide to allow
> the layout and presentation logic to be created and maintained independent of
> the underlying programming logic. This separation allows each discipline
> (presentation designer and business logic programmer) to focus more sharply on
> their aspect of the application with less risk of either inadvertently
> creating errors in the other aspect.
>
> Though their role lies in layout and presentation, templates must have a
> certain programmatic capability to handle tasks like (1) handling a variable
> number of rows/records, and (2) hiding/displaying menu choices for different
> users.
Yes - and this is certainly in the realm of the designer. You need to be
able to count rows, count columns, whatever, and do basic math to keep
track.
>
> The 'grey' areas (as to whether a function is best implemented by the template
> or business logic) include tasks like (1) formating numbers, (2) skipping
> rows, and (3) implementing decision logic involving dates, float/decimal
> numbers, etc. The tradeoff is basically more template complexity versus
> reusability of business logic. In some cases if the business logic is kept
> more generic, it can be used with multiple templates (as long as the templates
> have enough 'smarts' to do the refined processing). In other cases, it is far
> more efficient to embed this logic in the business logic modules themselves.
Once business logic crosses into the template, I think you are asking for
problems. I know nothing is perfect, and there are no absolutes, but its
good to try :)
I mean, keeping the business logic outside of the template means that the
designer doesn't need domain knowledge of the business problem ("If not a
manager, then can't show department salary list, unless team lead of > 10
years experience") to present the information.
>
> Template systems like Velocity also allow very rapid development practices,
> primarily because of their ability to expose business logic objects to the
> template, where the template has a decent set of built-in directives and macro
> capability. This option is driven by the really big advantage - no compilation
> required. With Velocity in particular (since it is the one I know best), you
> have the option to easily migrate the business logic back to the programming
> module when the initial development has been completed - a wonderful option,
> to be sure.
And this is an area we are are lacking, I believe. It's harder in Velocity
to slap together a set of objects in a page for the most part - you need
some kind of servlet that populates the context from an external list or
something, or provide enough that you can bootstrap the rest - some kind of
class factory.
#set($thing = $tool.make("java.util.ArrayList"))
>
> As I see them, scripts generally replace the program module plus template.
Yes - they are the, or a part of, the program module. They can be the
template, but they can just use a template as well.
> Scripts tend to employ higher-level languages (compared to the programming
> module). They too help in rapid development, because they usually do not
> require a compilation step. But they do not provide the separate focus for
> designers and programmers.
>
I agree - that "higher-level" functionality usually adds some complexity to
the use....
geir
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>