struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yee, Richard K,,DMDCWEST" <Ye...@osd.pentagon.mil>
Subject RE: Conventions for indexed properties
Date Tue, 03 Feb 2004 19:48:08 GMT
Sunil,
The LazyList class in the commmons-collections.jar file does this already
for you.

Rgds,

Richard


java.lang.Object
  |
  +--org.apache.commons.collections.collection.AbstractCollectionDecorator
        |
        +--org.apache.commons.collections.list.AbstractListDecorator
              |
              +--org.apache.commons.collections.list.LazyList
All Implemented Interfaces: 
java.util.Collection, java.util.List 

----------------------------------------------------------------------------
----

public class LazyList
extends AbstractListDecorator
Decorates another List to create objects in the list on demand. 

When the get(int) method is called with an index greater than the size of
the list, the list will automatically grow in size and return a new object
from the specified factory. The gaps will be filled by null. If a get method
call encounters a null, it will be replaced with a new object from the
factory. Thus this list is unsuitable for storing null objects. 

-----Original Message-----
From: Sunil Dmonte [mailto:Sunil.Dmonte@tavant.com] 
Sent: Monday, February 02, 2004 10:33 PM
To: ^Struts Users Mailing List (E-mail)
Cc: Imran Ali
Subject: RE: Conventions for indexed properties


I Thought I'd reply to my own message with our solution to this issue.
Feedback is most welcome.

Here are the changes we made:

1) We have an indexed getter and setter exactly as per the JavaBean spec
2) A non-indexed "List" getter and setter as supported by BeanUtils
3) Using our own "ExpandableArrayList" class instead of a normal ArrayList. 

The code for this class is given below (minus documentation):

*******************************************************************
import java.util.ArrayList;
import java.util.RandomAccess;
import java.util.List;
import java.io.Serializable;

public class ExpandableArrayList extends ArrayList implements List,
    RandomAccess, Cloneable, Serializable
{
  private Class beanClass;

  public ExpandableArrayList(Class classType)
  {
    super();
    beanClass = classType;
  }

  public Object set(int index, Object element)
  {
    resizeIfNecessary(index);
    return super.set(index, element);
  }

  public Object get(int index)
  {
    resizeIfNecessary(index);
    return super.get(index);
  }

  private void resizeIfNecessary(int index)
  {
    // Extend the size of the list as needed.
    if (index >= size())
    {
      int missingElements = index - size() + 1;
      for (int i = 0; i < missingElements; i++)
      {
        try
        {
          add(beanClass.newInstance());
        }
        catch (InstantiationException e)
        {
          // log and...
          throw new RuntimeException(e);
        }
        catch (IllegalAccessException e)
        {
          // log and...
          throw new RuntimeException(e);
        }
      }
    }
  }
}
*******************************************************************

> -----Original Message-----
> From: Sunil Dmonte [mailto:Sunil.Dmonte@tavant.com]
> Sent: Friday, January 23, 2004 11:38
> To: 'Struts Users Mailing List'
> Subject: RE: Conventions for indexed properties
> 
> 
> Thanks for the responses guys. Does that mean the following
> getter (given at
> http://jakarta.apache.org/struts/faqs/indexedprops.html) is 
> incorrect? It
> doesn't seem to follow the javabean spec for indexed properties:
> 
> public java.util.List getStringIndexed(int index) { 
>         return java.util.Arrays.asList(strAry);
> }
> 
> (If it's taking an index as a parameter, why would it return
> the whole list?
> Is this some additional functionality that BeanUtils provides?)
> 
> Regarding the 2 variants for getters and setters - which one
> should I use?
> Both? If I use the "whole list" variant, then I can't do any 
> index checking
> to prevent an indexing exception (unless I decide to subclass 
> ArrayList and
> override the set(index, object) method). But when I introduce 
> the "indexed"
> variant, I start getting bean-related JspExceptions like 
> "JspException: No
> getter method for property .." even though the property name 
> matches up with
> the getter and setter.
> 
> Thanks for your help!
> sunil
> 
> 
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > Sent: Friday, January 23, 2004 11:13
> > To: Struts Users Mailing List; John D. Hume
> > Cc: Struts Users Mailing List
> > Subject: Re: Conventions for indexed properties
> > 
> > 
> > Quoting "John D. Hume" <john@subres.net>:
> > 
> > > I don't have a definitive guide, but here are some examples
> > that could
> > > be helpful.
> > > 
> > 
> > The definitive guide starts with the JavaBeans Specification:
> > 
> >   http://java.sun.com/products/javabeans/reference/api/index.html
> > 
> > you'll see that there are two variants for indexed properties
> > -- one that has
> > the getter and setter methods taking an array, and one that 
> > has the getter and
> > setter methods taking an additional argument for the index.
> > 
> > There's lots of other useful info about what it means to be a
> > JavaBean here as
> > well.  Just as one example, did you know that you can 
> > actually use any method
> > names you want (getFoo/setFoo is not required) if you're 
> > willing to build a
> > BeanInfo associated with your bean class?  Or that you can 
> > "hide" properties
> > from Struts (well, really from commons-beanutils) by creating 
> > a BeanInfo that
> > does not include them?
> > 
> > Craig
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message