You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Vitaly Repetenko <vi...@mtu.ru> on 2001/11/06 17:09:28 UTC
About DataSourceResourceLoader
Good day!
May be it will be useful to revise method init in
DataSourceResourceLoader class and example configuration in JavaDoc,
because current version of DataSourceResourceLoader does not work
correctly with configuration.
Perhaps something like this:
init method:
public void init( ExtendedProperties configuration)
{
dataSourceName = configuration.getString("datasource");
tableName = configuration.getString("table");
keyColumn = configuration.getString("keycolumn");
templateColumn = configuration.getString("templatecolumn");
timestampColumn = configuration.getString("timestampcolumn");
Runtime.info("Resources Loaded From: " + dataSourceName + "/" +
tableName);
Runtime.info( "Resource Loader using columns: " + keyColumn +
", "
+ templateColumn + " and " + timestampColumn);
Runtime.info("Resource Loader Initalized.");
}
Example configuration snippet for velocity.properties:
resource.loader = datasource
datasource.resource.loader.description = Velocity DataSource Resource
Loader
datasource.resource.loader.class =
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader
datasource.resource.loader.datasource = jdbc/testDS
datasource.resource.loader.table = template_table
datasource.resource.loader.keycolumn = template_id
datasource.resource.loader.templatecolumn = template_definition
datasource.resource.loader.timestampcolumn = template_timestamp
datasource.resource.loader.cache = false
datasource.resource.loader.modificationCheckInterval = 60
Thanks in advance,
Vitaly
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: OT: DataSourceResourceLoader and versioning
Posted by Nick Bauman <ni...@cortexity.com>.
[edit]
> However, version control of those database rows doesn't appear easy to
> me. Even with the protection afforded by three separate environments
> for DEV/QA/Production, rollback would likely be problematic after
> somebody in Marketing and Marketing-QA writes, approves, QA's, pushes
> to prod, and then says, "DOH! We can't have 'Our Woogie Foozels!' -
> we'll get sued! Help us revert back, Mr. IT Guy!!!"
This is an audience question, not a technical one. If the business people
want to be able to change templates themselves, without involving a web
developer or myself then the templates go in the DB and they don't get
version control, they get an web-based editor for uploading new templates in
the database. Period. If they screw it up, they fix it themselves.
Think about it: if marketing and sales had version control they wouldn't
know what to do with it anyway. (Give a caveman a machine gun and they'll
club you over the head with it). OTH, if someone in technology, someone who
knows and understands CVS, is making the template changes, then the
templates stay on the filesystem, get checked into CVS when changed, etc
etc, since we have other more pressing things to do than write WYSIWYG
editors for Velocity templates that web developers would just find irritating.
> Obviously a custom DB front end could be written that would save
> revisions of the templates, allow for DIFFs, rollbacks, build
> tagging/labelling - starting to sound like recreating CVS with a DB
> backend, eh?
>
> Has anybody invented that wheel?
>
> Thanks folks - I appreciate your time and collective knowledge :-) Timo
My position is "Don't rewrite CVS in SQL."
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: OT: DataSourceResourceLoader and versioning
Posted by Jim Seach <jw...@yahoo.com>.
Tim,
I haven't solved the problem you are encountering, but I do have a few
ideas.
You must have already developed routines to load the templates into the
database from the edited files, so you could wrap that in an ANT task,
set up a separate CVS repository for templates, and set up an ANT
target to checkout the templates from CVS and load them into the
database. That way, you have version control plus an easy way to
deploy.
Another option would be to skip the database repository for the
templates entirely, and instead create a CVSResourceLoader that will
load templates directly from CVS based on a version label. You could
create an administrative page in your application to update the label
and flush the template cache.
What do you think?
Jim Seach
--- Tim Colson <tc...@cisco.com> wrote:
> This is slightly related to the thread regarding the
> DataResourceLoader, but
> certainly not a Velocity specific question. Please, stop now if
> you're not
> interested in loading your templates from a database.
>
> ---
> Templates in a filestore is easy to version control. CVS. Done.
>
> However, making updates requires a build of the application (in our
> environment) from CVS.
>
> For making those all-important changes like "Our Woogie blips!" to
> "Our
> Woogie Rocks!" - it's painful (to the developers) to go through a
> full
> build, QA, migrate cycle - especially considering the fine MVC
> separation
> which means the developer written/tested code didn't change. :-)
>
> Templates in a database make it easy to affect changes to production
> output.
> (Ha - from a src viewpoint this is true separation of V from C
> <grin>)
>
> However, version control of those database rows doesn't appear easy
> to me.
> Even with the protection afforded by three separate environments for
> DEV/QA/Production, rollback would likely be problematic after
> somebody in
> Marketing and Marketing-QA writes, approves, QA's, pushes to prod,
> and then
> says, "DOH! We can't have 'Our Woogie Foozels!' - we'll get sued!
> Help us
> revert back, Mr. IT Guy!!!"
>
> Obviously a custom DB front end could be written that would save
> revisions
> of the templates, allow for DIFFs, rollbacks, build tagging/labelling
> -
> starting to sound like recreating CVS with a DB backend, eh?
>
> Has anybody invented that wheel?
>
> Thanks folks - I appreciate your time and collective knowledge :-)
> Timo
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: OT: DataSourceResourceLoader and versioning
Posted by Brian Lloyd-Newberry <ne...@yahoo.com>.
--- Tim Colson <tc...@cisco.com> wrote:
> However, making updates requires a build of the application (in our
> environment) from CVS.
Why don't you seperate out the template distro from the application
distro so that you can redeploy the templates seperate from the
application. We actually do this while the application is running in
emergency cases (although I will be the first to admit that it is not
my wish/desire to do so).
I seems to me that a database implementation won't really help you to
do what you want any more than seperation of the MC from the V at the
deployment level.
Just my 2c,
Brian
=====
Brian S. Lloyd-Newberry
Vertical Learning Curve Solutions
newbeb@yahoo.com
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
OT: DataSourceResourceLoader and versioning
Posted by Tim Colson <tc...@cisco.com>.
This is slightly related to the thread regarding the DataResourceLoader, but
certainly not a Velocity specific question. Please, stop now if you're not
interested in loading your templates from a database.
---
Templates in a filestore is easy to version control. CVS. Done.
However, making updates requires a build of the application (in our
environment) from CVS.
For making those all-important changes like "Our Woogie blips!" to "Our
Woogie Rocks!" - it's painful (to the developers) to go through a full
build, QA, migrate cycle - especially considering the fine MVC separation
which means the developer written/tested code didn't change. :-)
Templates in a database make it easy to affect changes to production output.
(Ha - from a src viewpoint this is true separation of V from C <grin>)
However, version control of those database rows doesn't appear easy to me.
Even with the protection afforded by three separate environments for
DEV/QA/Production, rollback would likely be problematic after somebody in
Marketing and Marketing-QA writes, approves, QA's, pushes to prod, and then
says, "DOH! We can't have 'Our Woogie Foozels!' - we'll get sued! Help us
revert back, Mr. IT Guy!!!"
Obviously a custom DB front end could be written that would save revisions
of the templates, allow for DIFFs, rollbacks, build tagging/labelling -
starting to sound like recreating CVS with a DB backend, eh?
Has anybody invented that wheel?
Thanks folks - I appreciate your time and collective knowledge :-)
Timo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: About DataSourceResourceLoader
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 11/6/01 11:09 AM, "Vitaly Repetenko" <vi...@mtu.ru> wrote:
> Good day!
>
> May be it will be useful to revise method init in
> DataSourceResourceLoader class and example configuration in JavaDoc,
> because current version of DataSourceResourceLoader does not work
> correctly with configuration.
>
Yep - that was the solution :)
> Perhaps something like this:
>
> init method:
> public void init( ExtendedProperties configuration)
> {
> dataSourceName = configuration.getString("datasource");
> tableName = configuration.getString("table");
> keyColumn = configuration.getString("keycolumn");
> templateColumn = configuration.getString("templatecolumn");
> timestampColumn = configuration.getString("timestampcolumn");
>
> Runtime.info("Resources Loaded From: " + dataSourceName + "/" +
> tableName);
> Runtime.info( "Resource Loader using columns: " + keyColumn +
> ", "
> + templateColumn + " and " + timestampColumn);
> Runtime.info("Resource Loader Initalized.");
> }
>
> Example configuration snippet for velocity.properties:
>
> resource.loader = datasource
> datasource.resource.loader.description = Velocity DataSource Resource
> Loader
> datasource.resource.loader.class =
> org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader
> datasource.resource.loader.datasource = jdbc/testDS
> datasource.resource.loader.table = template_table
> datasource.resource.loader.keycolumn = template_id
> datasource.resource.loader.templatecolumn = template_definition
> datasource.resource.loader.timestampcolumn = template_timestamp
> datasource.resource.loader.cache = false
> datasource.resource.loader.modificationCheckInterval = 60
>
>
>
> Thanks in advance,
> Vitaly
I will start with this code you contributed :)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>