[prev in list] [next in list] [prev in thread] [next in thread] 

List:       velocity-user
Subject:    Re: vrs JSP vrs AppBuilder
From:       James Maes <jmaes () sportingnews ! com>
Date:       2001-04-19 3:55:14
[Download RAW message or body]



I see that I forgot how to spell macro, hum....

my bad


On Wednesday 18 April 2001 23:43, you wrote:
> James Maes wrote:
> > Thanks for the feed back.  I have been reading the site, I have two quick
> > questions.
> >
> > 1. What is the scope of objects?
> >         For example say I have a DTag or what you call a Marco?
>
> Marco.  Polo.  Marco. Polo.  Sorry. Getting punchy :)  It's 'macro'.
>
> >  that prints an
> > article.  It uses an instance of the Article bean that contains all the
> > article data.  For the most part this object will only be used once. 
> > However there will be many such objects of the article class in a day. 
> > How would this be handled?
>
> That's up to you.  You really own the lifecycle of the data objects.
> Velocity just accesses them when rendering the template.
>
> The basic velocity pattern is :
>
> 1) Make and fill a VelocityContext
> 2) Choose a template
> 3) Render
>
> If making the article objects is expensive, you could easily pool them
> and reuse.  Once the merge process is done (i.e. rendering a template),
> Velocity keeps no references to the data objects, so you can let go and
> have them GC'd, or hold on for reuse.
>
> There are some 'advanced' tricks in this area, such as taking advantage
> of the context chaining.  This allows you to keep a filled context ready
> for use :
>
> VelocityContext vc = new VelocityContext( readOnlyVC );
>
> so anything in readonlyVC is accessable through vc if nothing is placed
> in vc to cover it.
>
> > 2. Are marcos like what I refered to as DTags in my sample code below.
> >         Example, we split up everything into small peices of code.  A
> > template (App page in our current system) is built from calling 50-100
> > DTags.  Each tag doing something small (Printing the date, showing an
> > image, getting an article from the database, etc...)
>
> Yes, you can use macro's for this. (It's macro - don't know if I spelled
> them wrong...  short for 'Velocimacro')
>
> You could define the library of VMs (Velocimacros) separately from the
> templates.  That's one of the primary ways they are intended to be used.
>
> You can also use what we call 'context tools', little helper classes
> that do things like format and such.
>
> The thing to remember is that the Velocimacros can only do things that
> you can do in the template language wiht directives and references.
>
> You the programmer need to supply the template and Velocimacros with
> data and objects that can get data.
>
> So yes, you can write a macro to get an article from the DB, but it has
> to have access to a real Java object that will do the work.
>
> This is the enforcement of the separaration between control/model and
> view that I mentioned.  JSP, in contrast, lets you break this - you can
> just sprinkle Java wherever you want.  And it's been our experience, you
> don't want...
>
>
> geir
>
> > Thanks again
> >
> > On Wednesday 18 April 2001 23:02, you wrote:
> > > James Maes wrote:
> > > > Hey all,
> > > >         We are looking at replacing our current templating system
> > > > (Informix Appage Builder) with a "Better" solution.  The main problem
> > > > we have ran into at this point is scaling.  We run a pseudo dynamic
> > > > site where we publish the content from the backend to flat files on
> > > > the live sites.  We generate 35,000 to 50,000 pages a day of unique
> > > > content from 300+ templates.
> > >
> > > Do you do this in one shot?  I mean, run a batch job at some point in
> > > the day?
> > >
> > > > Other then performance, useable is a large issue.  The current system
> > > > meshes the HTML (view) and SQL/Logic (model/controller) together in
> > > > "Pages" and "DTags"
> > >
> > > You have come to right place.  No such nonsense here...  Velocity
> > > strictly enforces the separation between data and presentation.
> > >
> > > > Example, a template page might look like this
> > > > ++++++ START OF CODE +++++++
> > > > <?head>
> > > > <?top>
> > > >    <?left_nav>
> > > >       <?main_page_body>
> > > >    <?right_nav>
> > > > <?bottom>
> > > > ++++++ END OF CODE +++++++
> > > >
> > > > where main_page_body might look something like this
> > > >
> > > > ++++++ START OF CODE +++++++
> > > >
> > > > <?MIBLOCK COND=$(EQ,$var1,$var2)>
> > > >         <h4>Quick Little Html Tag Sample</h4>
> > > > <?/MIUBLOCK>
> > > >
> > > > <?MISQL SQL="SELECT something FROM somewhere WHERE this = that">
> > > >         something result from html query
> > > > <?/MISQL>
> > > >
> > > > ++++++ END OF CODE +++++++
> > > >
> > > > We are looking to replace this with JSP's and JavaBeans.
> > > >
> > > > I ran across this project from Google tonight, and thought I would
> > > > take a look.
> > > >
> > > > That all being said maybe you can help me with a couple of questions
> > > > 1. How does this (w/Turbine?) do under heavy loads.  (50,000 pages a
> > > > day from 300+ templates)
> > >
> > > I can't answer this question, as I am not a Turbine person : however, 
> > > I can't imagine that it would be a problem.
> > >
> > > 50,000 a day, spread over a day, is something like 1 every 2 seconds.
> > > No worries :)
> > >
> > > The real question is what is the peak, and do you divide the load over
> > > more than 1 machine through load balancing...
> > >
> > > > 2. Any support for EJB intergration? (for better intergration with
> > > > our PubSys Interfaces)
> > >
> > > Velocity is designed such that a template can access virtually any type
> > > of Java class with public methods.  This means that while you may have
> > > to write a wrapper class or two, you should be able to easily use
> > > data-providing code that you have now.  We follow the bean spec, with a
> > > few enhancements for ease of use, in our introspection.
> > >
> > > Our iterator support in the #foreach() directive will handle anything
> > > that looks like an Object[],  a Collection, a Map, an Iterator or an
> > > Enumeration, so you have some freedom there, too.
> > >
> > > > 3. Over all ease of use
> > >
> > > We think its very easy.  The template language was designed with the
> > > designer in mind. There are very few directives in the template
> > > language to learn.  They are basically constrainted to basic logic
> > >
> > > #if(  $ref == 1 )
> > >   do something
> > > #end
> > >
> > > looping
> > >
> > > #foreach( $i in $dataarray)
> > >   do someting
> > > #end
> > >
> > > setting new 'variables'
> > >
> > > #set($mycount = 1 )
> > >
> > > and of course accessing data
> > >
> > > $mystring
> > >
> > > $resultset.nextValue()
> > >
> > > $hashtable.thekey
> > >
> > > etc
> > >
> > >
> > > On the developer side, it's a very simple API to deal with.  Once basic
> > > setup is out of the way, which is easy as the runtime provides defaults
> > > internally for every setting, you simply load what we call 'the
> > > Context' (a glorified hashtable), choose a template (or create one
> > > dynamically) and have Velocity render the template and context into a
> > > writer.
> > >
> > > That's pretty much it.
> > >
> > > See the developer documentation on the website for an overview on
> > > programming w/ velocity.
> > >
> > > http://jakarta.apache.org/velocity/developer-guide.html
> > >
> > > We also provide a servlet base class that you can derive your servlet
> > > from, and it manages most of the harder stuff, leaving you to control
> > > logic, the data model, and choosing that pesky template. :)
> > >
> > > > 4. Over all application reliability
> > >
> > > So far, so good.  We are as fast as our competitors, have a released
> > > version, and are being used in production environments around the
> > > world.  That said, we are the 'new guy' in the block, so our 'customer
> > > base' isn't as large as others.  But it's growing rapidly.  Take a look
> > > at our mail lists on www.mail-archive.com to get the flavor of the
> > > problems we have been dealing with lately...
> > >
> > > > Any comments would be of great help.
> > > >
> > > > Also, if anyone else has come across similar migrations I would love
> > > > to hear form you.
> > >
> > > The migrations to Velocity have mostly been from WebMacro-based
> > > systems, as Velocity can trace its ancestry directly to WebMacro.  (We
> > > admit it
> > >
> > > :  we stole the idea, lock stock and barrel.)  The syntax is very, very
> > >
> > > similar, the programming pattern / model is almost identical, etc.  So
> > > it's a easy move from WM to Vel.
> > >
> > > Vel has a nifty 'macro' facility called Velocimacros that let your
> > > template authors compose parameterized macros of template code that
> > > they can reuse as if it was a built in directive.  it's a powerful
> > > feature, and sounds like something you would be able use effectively.
> > >
> > > Hope this gave you a little insight into what we are about, and we hope
> > > to see you using Velocity.  Please, don't hesitate with questions.
> > >
> > > geir
> > >
> > > > ------------------------------------
> > > >
> > > > || James Maes
> > > > || Senior Programmer
> > > > || jmaes@sportingnews.com
> > > > || The Sporting News
> > > > || www.sportingnews.com
> > > > || fantasy.sportingnews.com
> > > >
> > > > ------------------------------------
> > > >
> > > > "given enough time and resources we can accomplish anything"
> >
> > --
> >
> > ------------------------------------
> >
> > || James Maes
> > || Senior Programmer
> > || jmaes@sportingnews.com
> > || The Sporting News
> > || www.sportingnews.com
> > || fantasy.sportingnews.com
> >
> > ------------------------------------
> >
> > "given enough time and resources we can accomplish anything"

-- 
 
------------------------------------
|| James Maes        
|| Senior Programmer 
|| jmaes@sportingnews.com 
|| The Sporting News     
|| www.sportingnews.com 
|| fantasy.sportingnews.com
------------------------------------

"given enough time and resources we can accomplish anything"

[prev in list] [next in list] [prev in thread] [next in thread]