Re: Overhead creating a Vector of objects to send to VTL ? ( Re: foreach)

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 5/4/02 4:12 PM, "Stephen Riek" <st...@yahoo.co.uk> wrote:

> 
> I work solely in the Web world. Probably the most common place where
> one would use #foreach is looping over a list of results from a query.
> For example, viewing a catalog, or viewing the results from a search
> engine. I have never found Velocity lacking, mainly because I've
> usually handled all the logic in the SQL before I return the list of
> results to Velocity.
> Consider sending the results of a SQL query to a velocity template.
> Each result represents an object (eg. an item in your catalog) for
> which you have a corresponding Javabean. At the moment I loop over
> the JDBC ResultSet within the Java code and create a Vector of
> catalogItem objects, which is sent to the Velocity Template.
> This contrasts greatly with the JSP way of handling the JDBC ResultSet
> directly. However, is my mechanism using too much Object creation
> (the Vector of Javabeans) which I understand is "expensive" overhead
> in Java ?I'm trying to optimize performance and scalability so is this a
> real concern ? 

If you are not accessing everything in the result set, this may be wasteful
(although java is getting efficient).

One solution is to access the data 'just in time'.  To do this, make a
little class that you put the result set into, and then that class into the
context. It might be a little  bit of a pain as you will need to let
Velocity iterator over something.  If you only will iterate over it once,
then you can just make it look like an Iterator.  I have no idea if the
following works, let alone compiles.  I am just making this up :)

 public class Foo implements java.util.Iterator {

    ResultSet myResultSet;
    MyMapper mapper;

    public Foo(ResultSet rs)
    {
        myResultSet = rs;
        mapper = new Mapper(myResultSet);
    }

     public boolean hasNext() {
       
        return rs.next();
     }

     public Object next() {
          return mapper;
     }
}

 public class MyMapper implements Map{
   ResultSet rs;

  public MyMapper(ResultSet rs)
  {
      this.rs = rs;
   }
  
   public Object get(String key)
   {
     return rs.getString(key);
   }

   ... Rest of Map methods
}


So the idea is that you wrap the result set in something that looks like a
java.util.Iterator, so Vel will iterate over it and put that into the
context.  No new objects yet.

Then, each item in the set will be a mapper that also wraps the result set
(so no new objects created).

Then, when you use it

  #foreach($item in $resultset)

      $item.foo

  #end

Will only access the result set creating a string for the column 'foo'.


> 
> I have never bought into the "most people working in the MVC View
> are not programmers" argument, which is the basis of Struts and a
> multitude of frameworks which seem to have been born in ivory towers.
> Sure, it's true there are more non-programmers in the View area, but I
> wouldn't expect any designer to be able to use VTL. No disrespect to
> any of them, but the hundreds of designers I've worked with just wouldn't
> want to know and prefer not to have the responsibility. Therefore,
> it's a non-issue for me.  Velocity Rocks.
> 
> Thank you for any feedback on the initial question.
> Stephen Riek.
> 
> 
> 
> 
> ---------------------------------
> Do You Yahoo!?
> Get personalised at My Yahoo!.
> 

-- 
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>