You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Christopher Townson <c....@nature.com> on 2006/02/06 14:03:11 UTC
component based templates with Velocity (+ tools?)
Hi,
For a few months now, we at Nature have been throwing around the idea of
developing a whole bunch of Velocity Tools to enable us to develop a truly
component-based templating solution for our sites.
I noticed Nathan's comment
(http://www.theserverside.com/news/thread.tss?thread_id=20404#89523) about
this from 2003 and was wondering whether anyone out there has any experiences
of developing this kind of solution that they would like to share?
Our basic idea was this:
Outline:
We have multiple sites with many different views, but most reuse broadly
similar 'components' to construct these views. Through use of Velocity Tools,
we could make these components independent and reusable by making available
methods that, using a passed argument, knew how to retrieve the data they
required in any particular instance.
1. Sub-class VelocityViewServlet to initialize required contexts (e.g. global,
group, site etc) and populate with configuration data from files (file
retrieval based on convention / data being the basic stuff like names of
sites, values used throughout all sites or all of group etc)
2. Create a suite of Velocity Tools, each with an accompanying velocity
template ... or multiple templates - which template was used could be
determined by the presence or absence of vm files based upon convention?
for example: a "MenuTool" might have a template that looked like this:
#set ( $Menu.name = 'main menu' ) #* a string which identifies which type of
menu we're dealing with *#
#set ( $Menu.site = $Config.siteName ) #* so it knows where to get the correct
menu items *#
<ul>
#foreach ( $MenuItem in $Menu.items )
<li><a href="$MenuItem.getURL()">$MenuItem.getText()</a></li>
#end
</ul>
Through its interface with the Velocity Tool, this one 'main menu' template
file could then be used globally and multiple times in the same view.
Another way to do the same thing without the use of Velocity Tools is to
create extensive configuration files using standard *.vm files and #set
directives. However, in my experience, that solution is quite laborious to
maintain and prone to error when editing is done by inexperienced users.
Your comments and suggestions / experience would be most gratefully received.
Best wishes,
Chris
--
Christopher Townson
New Technology Developer
Nature Publishing Group
t. +44 (0)20 7843 4644
e. c.townson@nature.com
********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of Macmillan
Publishers Limited or its agents by means of e-mail communication. Macmillan
Publishers Limited Registered in England and Wales with registered number 785998
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************
Re: component based templates with Velocity (+ tools?)
Posted by Ahmed Mohombe <am...@yahoo.com>.
> For a few months now, we at Nature have been throwing around the idea of
> developing a whole bunch of Velocity Tools to enable us to develop a truly
> component-based templating solution for our sites.
This might be exactly what you look for:
http://click.sourceforge.net/
Not as Velocity Tools, but as a very very simple framework based on Velocity,
but based on components.
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: component based templates with Velocity (+ tools?)
Posted by Christopher Townson <c....@nature.com>.
On Tuesday 7 February 2006 2:04 pm, Robert Koberg wrote:
> I was just curious if this needs to be dynamic. Couldn't you pregenerate
> all these things? This is what we do for our CMS. CMS users select
> layouts for pages (or falls back to an ancestor that had a layout
> defined). Several content pieces or XML components can be assigned to
> defined regions on a page. CMS users can choose things at the folder
> level like should a snailtrail or paging information show. We use XML
> configuration, content and XSL to transform to a static file. That file
> can be a velocity page, just as much as possible is pregenerated.
>
> I guess in other words, it sounds like you want to build a CMS.
well, I think we would certainly like this to be a part of a broader CMS
project.
At present we do almost exactly what you do: we use XSL to transform XML -
first into 'xml snippets' (that roughly correspond to the content 'entities'
we would want to create Velocity Tools for), then into a static HTML files.
Subsequently, Velocity is used to pull these static HTML files in to various
points on a page.
What we want to do is use Velocity to overcome the problems inherent to this
approach; which are:
1. If the design or layout of things changes, or even if we just change the
content a little, we have to 're-rip' stuff (run through the XSLs). With the
amount of content we have, and the frequency of changes, this is a burden.
2. Authoring XSLs requires a certain expertise and knowledge of the XML
formats we use; authoring Velocity templates requires very little. We can
produce XHTML Velocity templates very quickly which produce
standards-compliant, accessible code. However, we hit a bottleneck (and a
significant source of errors) when parts (or all) of these templates need to
be written as XSLs.
3. As with most organisations, our design team is responsible for all the
HTML, CSS, Javascript etc that is used to display pages under normal
circumstances; and our development team is responsible for everything else.
The static-file approach you mention requires extensive interaction between
these departments that is a source of delays and errors.
What we need to do is get rid of the stage where XSLs are producing HTML. By
making Velocity Tools that retrieve data associated with content
'entities' (whether from 'xml snippets' or a database or wherever) and insert
this into the context in a standardised, pre-agreed manner, rebuilding, xsl
editing, and inter-departmental coopertation is not necessary every time
there is a change in the appearance of a site etc ...
So, yes - it is certainly related to content management, but Velocity Tools in
themselves would not be a CMS! :D
Chris
********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of Macmillan
Publishers Limited or its agents by means of e-mail communication. Macmillan
Publishers Limited Registered in England and Wales with registered number 785998
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: component based templates with Velocity (+ tools?)
Posted by Robert Koberg <ro...@koberg.com>.
Christopher Townson wrote:
> - a view here is considered equivalent to a 'page' (i.e. a URL identified
> resource which is requested by an end-user). A view itself would not have a
> 'template' as such - it would simply consist of a bunch of directives that
> specify things like 'I want these components with the following parameters',
> 'I want this layout', 'Put these components here and those ones there' etc...
>
> - views would be constructed from components organised into a layout.
>
> - Our design team would then be able to write just a single template for each
> component (i.e. it would be 'global' ... unless a template for the same
> component was found in a location specified by convention as being 'more
> specific'). There would only need to be a single *.vm template file
> (containing the HTML or whatever, written by our design team).
Hi,
I was just curious if this needs to be dynamic. Couldn't you pregenerate
all these things? This is what we do for our CMS. CMS users select
layouts for pages (or falls back to an ancestor that had a layout
defined). Several content pieces or XML components can be assigned to
defined regions on a page. CMS users can choose things at the folder
level like should a snailtrail or paging information show. We use XML
configuration, content and XSL to transform to a static file. That file
can be a velocity page, just as much as possible is pregenerated.
I guess in other words, it sounds like you want to build a CMS.
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: component based templates with Velocity (+ tools?)
Posted by Christopher Townson <c....@nature.com>.
On Monday 6 February 2006 4:49 pm, Nathan Bubna wrote:
> gosh, time flies... since that time, we really haven't pursued the
> Velocimacro library idea very thoroughly. we do have a start to it in
> our Wiki, but the contributions are thin and organization/formatting
> is uneven.
well, we were thinking that our approach would be to create some suitably
generic component tools which could be contributed to this and then extend
those to meet our more specific needs
> as far as doing compentized work, i agree that Click has probably gone
> furthest in supporting compenent-oriented web development with
> Velocity. before you do anything else, you should probably look into
> what they're doing first.
yes, it looks interesting ... I hadn't heard of it before so started
examining it yesterday afternoon.
My first impression is that we could use it, but that the Velocity Tools
approach might integrate more easily with what we currently have and the way
we do things. I could be wrong about that, of course ;D
> > 2. Create a suite of Velocity Tools, each with an accompanying velocity
> > template ... or multiple templates - which template was used could be
> > determined by the presence or absence of vm files based upon convention?
>
> conventions are good. would this be something like the MultiViewsTool?
possibly - I haven't played with that one yet (but it's on my list now! :D)
> > for example: a "MenuTool" might have a template that looked like this:
> >
> > #set ( $Menu.name = 'main menu' ) #* a string which identifies which type
> > of menu we're dealing with *#
> > #set ( $Menu.site = $Config.siteName ) #* so it knows where to get the
> > correct menu items *#
> > <ul>
> > #foreach ( $MenuItem in $Menu.items )
> > <li><a href="$MenuItem.getURL()">$MenuItem.getText()</a></li>
> > #end
> > </ul>
> >
> > Through its interface with the Velocity Tool, this one 'main menu'
> > template file could then be used globally and multiple times in the same
> > view.
>
> not sure i follow...
sorry - that's not a very clear description! Let me clarify:
- a view here is considered equivalent to a 'page' (i.e. a URL identified
resource which is requested by an end-user). A view itself would not have a
'template' as such - it would simply consist of a bunch of directives that
specify things like 'I want these components with the following parameters',
'I want this layout', 'Put these components here and those ones there' etc...
- views would be constructed from components organised into a layout.
- Our design team would then be able to write just a single template for each
component (i.e. it would be 'global' ... unless a template for the same
component was found in a location specified by convention as being 'more
specific'). There would only need to be a single *.vm template file
(containing the HTML or whatever, written by our design team).
Now, in theory, this is achievable using #parse and so on (aside from as the
view layer for Struts, this is the main way we use Velocity at present: as an
elaborate form of SSI - which I think is a waste of an excellent and
versatile tool!)
By rigorously conceiving of one's sites as being constructed from
'components', and making tools that define the properties and methods
available to them, it would be possible to store and retrieve data about
those things that aid management of the views.
For example: one feature request we have received from our design team is the
ability to define what stylesheets or javascripts a particular 'component'
depends upon and have these automatically loaded in the <head> section of a
document. Because accessibility and standards-compliance is a big issue, they
would also like to be able to do things like dynamically changing the heading
level of a particular template depending on where it was used (this is easily
achieved using VTL, but only in ways that are too prone to human error).
>From this perspective, what we are proposing is to use a suite of Velocity
Tools as a simple way of managing the complexities of the view layer. A
beneficial side-effect would be a clearer separation of display and logic in
a way that suits our organisational setup.
... that was a longer clarification than I intended it to be ... does it
clarify? ;D
Chris
********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of Macmillan
Publishers Limited or its agents by means of e-mail communication. Macmillan
Publishers Limited Registered in England and Wales with registered number 785998
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: component based templates with Velocity (+ tools?)
Posted by Nathan Bubna <nb...@gmail.com>.
On 2/6/06, Christopher Townson <c....@nature.com> wrote:
> Hi,
>
> For a few months now, we at Nature have been throwing around the idea of
> developing a whole bunch of Velocity Tools to enable us to develop a truly
> component-based templating solution for our sites.
>
> I noticed Nathan's comment
> (http://www.theserverside.com/news/thread.tss?thread_id=20404#89523) about
> this from 2003 and was wondering whether anyone out there has any experiences
> of developing this kind of solution that they would like to share?
gosh, time flies... since that time, we really haven't pursued the
Velocimacro library idea very thoroughly. we do have a start to it in
our Wiki, but the contributions are thin and organization/formatting
is uneven.
as far as doing compentized work, i agree that Click has probably gone
furthest in supporting compenent-oriented web development with
Velocity. before you do anything else, you should probably look into
what they're doing first.
> Our basic idea was this:
> Outline:
> We have multiple sites with many different views, but most reuse broadly
> similar 'components' to construct these views. Through use of Velocity Tools,
> we could make these components independent and reusable by making available
> methods that, using a passed argument, knew how to retrieve the data they
> required in any particular instance.
>
> 1. Sub-class VelocityViewServlet to initialize required contexts (e.g. global,
> group, site etc) and populate with configuration data from files (file
> retrieval based on convention / data being the basic stuff like names of
> sites, values used throughout all sites or all of group etc)
sounds good.
> 2. Create a suite of Velocity Tools, each with an accompanying velocity
> template ... or multiple templates - which template was used could be
> determined by the presence or absence of vm files based upon convention?
conventions are good. would this be something like the MultiViewsTool?
> for example: a "MenuTool" might have a template that looked like this:
>
> #set ( $Menu.name = 'main menu' ) #* a string which identifies which type of
> menu we're dealing with *#
> #set ( $Menu.site = $Config.siteName ) #* so it knows where to get the correct
> menu items *#
> <ul>
> #foreach ( $MenuItem in $Menu.items )
> <li><a href="$MenuItem.getURL()">$MenuItem.getText()</a></li>
> #end
> </ul>
>
> Through its interface with the Velocity Tool, this one 'main menu' template
> file could then be used globally and multiple times in the same view.
not sure i follow...
> Another way to do the same thing without the use of Velocity Tools is to
> create extensive configuration files using standard *.vm files and #set
> directives. However, in my experience, that solution is quite laborious to
> maintain and prone to error when editing is done by inexperienced users.
yeah, i would avoid doing configuration in your templates as much as
is reasonable. Velocity isn't really designed for that. of course,
neither was xml, and look how we've all been suckered into using that
to configure everything... :)
> Your comments and suggestions / experience would be most gratefully received.
>
> Best wishes,
>
> Chris
>
> --
> Christopher Townson
> New Technology Developer
> Nature Publishing Group
>
> t. +44 (0)20 7843 4644
> e. c.townson@nature.com
>
> ********************************************************************************
> DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
> not the original intended recipient. If you have received this e-mail in error
> please inform the sender and delete it from your mailbox or any other storage
> mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
> liability for any statements made which are clearly the sender's own and not
> expressly made on behalf of Macmillan Publishers Limited or one of its agents.
> Please note that neither Macmillan Publishers Limited nor any of its agents
> accept any responsibility for viruses that may be contained in this e-mail or
> its attachments and it is your responsibility to scan the e-mail and
> attachments (if any). No contracts may be concluded on behalf of Macmillan
> Publishers Limited or its agents by means of e-mail communication. Macmillan
> Publishers Limited Registered in England and Wales with registered number 785998
> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
> ********************************************************************************
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org