You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Barbara Baughman <ba...@utdallas.edu> on 2004/10/18 18:43:49 UTC
Defining iterator for #foreach
It looks like, for the first time, I am passing an object to a foreach
loop that that is not a Vector, HashMap, or Array.
I instead have a class that essentially wraps a Vector of a certain
type. It includes a method:
public Iterator iterator() {
return v.iterator(); // return iterator of the underlying Vector
}
I thought all classes with iterators would work with a #foreach loop
(even though I don't see that in the documentation. However, I get
the error message:
Mon Oct 18 11:22:49 CDT 2004 [warn] Could not determine type of
iterator in #foreach loop at [0,0] in template member/info/facstaff.vm
The template output only provides one blank line, even though the
size() method indicates there are 84 members.
Any hints or tips?
Barbara Baughman
X2157
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Defining iterator for #foreach
Posted by Shinobu Kawai <sh...@gmail.com>.
Hi Barbara,
> I don't reimplement any functions. I call on the function for the
> underlying object.
Of course. I was talking about the part making it "immutable".
BTW, is "immutable class" some kind of design pattern? I've heard of
ValueObjects.
Best regards,
-- Shinobu Kawai
--
Shinobu Kawai <sh...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Defining iterator for #foreach
Posted by Barbara Baughman <ba...@utdallas.edu>.
I don't reimplement any functions. I call on the function for the
underlying object.
Barbara Baughman
X2157
On Tue, 19 Oct 2004, Shinobu Kawai wrote:
> Hi Barbara,
>
> > Actually, I was trying to create a class that was immutable, which
> > means I wouldn't want to implement Collection. If I have the class
> > just implement Iterator would that do it?
> A bit off topic, but would one of the Collections#unmodifiable*
> methods work for you?
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collections.html
> I mean, you wouldn't want to re-implement a fully tested function
> already supplied in java, do you?
>
> Best regards,
> -- Shinobu Kawai
>
> --
> Shinobu Kawai <sh...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Defining iterator for #foreach
Posted by Barbara Baughman <ba...@utdallas.edu>.
Actually, as Shinobu pointed out, it only yields a warning message,
not an error message. Funny, I remembered it differently. A warning
not so bad.
So, when casting a session attribute to a collection with generics,
you get a warning message. You don't get a warning with other
objects, or even if you cast to just the collection without generics
(but you'll get warnings later when retrieving from the collection).
Really, I still have lots of classes that yield warning messages, and
they run just fine. If I hadn't been running with classes that
yielded so many warning messages on compile (so many the compiler
wouldn't print all of them), I don't know that I would have bothered
with the extra classes and substantial rewrite. I'd just add generics
here and there to programs as I found the time.
Barbara Baughman
X2157
On Mon, 18 Oct 2004, Mike Curwen wrote:
> So.. this is basically a problem with you loosing "generic" information
> when sticking information into an object that won't return anything but
> 'Object' ?
>
> I've been somewhat excited about generics, but then I realized how much time
> I spend with methods that look like:
>
> Object HttpSession.getAttribute(String var)
> Object ServletContext.getAttribute(String var)
>
> And (I wasn't sure, but you seem to have confirmed), you can't *cast* to a
> generic? Your lines about 'this is illegal', I'm thinking. Pity, that.
>
>
>
> > -----Original Message-----
> > From: Barbara Baughman [mailto:baughman@utdallas.edu]
> > Sent: Monday, October 18, 2004 7:46 PM
> > To: Velocity Users List; Shinobu Kawai
> > Subject: Re: Defining iterator for #foreach
> >
> >
> > An example of my problem with session attributes is as follows, using
> > tomcat 5.0:
> >
> > HashMap<String,String> hm=new HashMap<String,String>();
> > hm.put("lastname","Baughman");
> > hm.put("firstname","Barbara");
> > session.setAttribute("name",hm);
> >
> > This is NOT legal (generic information is not available at runtime):
> > HashMap<String,String> name=(HashMap<String,String>)
> > session.getAttribute("name");
> > String lastname=name.get("lastname");
> > String firstname=name.get("firstname");
> >
> > This IS legal:
> > HashMap name=(HashMap) session.getAttribute("name");
> > String lastname=(String) name.get("lastname");
> > String firstname=(String) name.get("firstname");
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Defining iterator for #foreach
Posted by Mike Curwen <g_...@globallyboundless.com>.
So.. this is basically a problem with you loosing "generic" information
when sticking information into an object that won't return anything but
'Object' ?
I've been somewhat excited about generics, but then I realized how much time
I spend with methods that look like:
Object HttpSession.getAttribute(String var)
Object ServletContext.getAttribute(String var)
And (I wasn't sure, but you seem to have confirmed), you can't *cast* to a
generic? Your lines about 'this is illegal', I'm thinking. Pity, that.
> -----Original Message-----
> From: Barbara Baughman [mailto:baughman@utdallas.edu]
> Sent: Monday, October 18, 2004 7:46 PM
> To: Velocity Users List; Shinobu Kawai
> Subject: Re: Defining iterator for #foreach
>
>
> An example of my problem with session attributes is as follows, using
> tomcat 5.0:
>
> HashMap<String,String> hm=new HashMap<String,String>();
> hm.put("lastname","Baughman");
> hm.put("firstname","Barbara");
> session.setAttribute("name",hm);
>
> This is NOT legal (generic information is not available at runtime):
> HashMap<String,String> name=(HashMap<String,String>)
> session.getAttribute("name");
> String lastname=name.get("lastname");
> String firstname=name.get("firstname");
>
> This IS legal:
> HashMap name=(HashMap) session.getAttribute("name");
> String lastname=(String) name.get("lastname");
> String firstname=(String) name.get("firstname");
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Defining iterator for #foreach
Posted by Barbara Baughman <ba...@utdallas.edu>.
Yes, Velocity 1.4 plays nicely with the java 1.5 compiler and tomcat
5.0 with no adjustments to any piece of the puzzle.
You're right about the Generics not making a difference in the
Velocity template. My problem was indirect, since in many cases I was
passing arrays of Collection objects to the Velocity context.
Unfortunately, JAVA 1.5 does not allow arrays of Generic-typed
objects, so I chose to find a workaround that would still give me the
advantage of a Generic-typed Collection without having to change all
of my templates. The MapList did that for me. Again, you can keep
the code you have and it will still work just fine with JAVA 1.5.
The above was a simple redesign that allowed me to take advantage of
Generics in the java (not template) coding and web session attributes
without changing the templates.
Immutable objects are Object classes whose underlying values cannot be
changed. The fields are set in the constructor, and there are no
methods that allow them to be changed. There are also no public,
non-final fields, and all public final fields are immutable classes.
These type of classes are always threadsafe, a good thing. Clearly,
it's not appropriate for every class, but it is preferable if it can
be done. So my wrapper class typically is constructed using the
underlying collection once I'm done creating it. The wrapper class
then doesn't have any methods that allow you to change it or get a
reference to the underlying collection (return a copy instead).
An example of my problem with session attributes is as follows, using
tomcat 5.0:
HashMap<String,String> hm=new HashMap<String,String>();
hm.put("lastname","Baughman");
hm.put("firstname","Barbara");
session.setAttribute("name",hm);
This is NOT legal (generic information is not available at runtime):
HashMap<String,String> name=(HashMap<String,String>)
session.getAttribute("name");
String lastname=name.get("lastname");
String firstname=name.get("firstname");
This IS legal:
HashMap name=(HashMap) session.getAttribute("name");
String lastname=(String) name.get("lastname");
String firstname=(String) name.get("firstname");
But the last two lines give a warning:unchecked message during
compilation. The code runs just fine, but I hate having a lot of
warning messages that must be ignored. Makes me get in the habit of
ignoring all warning messages.
So my wrapper class is:
import java.util.HashMap;
public class StringMap {
private HashMap<String,String> hm=new HashMap<String,String>();
public StringMap() {
}
public StringMap(HashMap<String,String> hm) {
this.hm=hm;
}
public String get(String key) {
return hm.get(key);
}
...
}
So this is legal, gives no warnings, and makes pretty code:
session.setAttribute("name", new StringMap(hm));
StringMap sm=(StringMap) session.getAttribute("name");
String lastname=sm.get("lastname");
String firstname=sm.get("firstname");
We're getting off-point with the Velocity list. Perhaps further
discussion should go off-list.
Barbara Baughman
X2157
On Tue, 19 Oct 2004, Shinobu Kawai wrote:
> Hi Barbara,
>
> Nice to know that Velocity is working with Java 5. ;)
>
> > I prefer immutable classes because they are threadsafe, can't be
> > changed by the template designer, and follow Joshua Bloch's advice in
> > the book Effective Java (an excellent read, BTW).
> I haven't read the book, so I don't know what's said in it, BUT you
> can make it thread safe by Collections.synchronized*. Say you have a
> List called list. You can get what you need by
> List listForTemplate =
> Collections.unmodifiableList(Collections.synchronizedList(list))
> Okay, so it's a bit annoying. ;)
>
> > A wrapper class (call it MapList<K,V>) for Vector<SimpleMap<K,V>> is a
> > lot handier that writing Vector<SimpleMap<K,V>> when I use this
> > particular formulation a lot and pass it to the template designers.
> Ah, you have a List of Map's. That makes it harder.
>
> > It is also easier for my template designers to use MapList<K,V> than
> > trying to understand the intricacies of Generics in JAVA when the
> > specification gets complicated.
> Actually, I don't think the template designers even care about
> Generics. All they need to know is, "What are the public methods I
> can use?". I put a sample at the end of this message. The Velocity
> template will look the same, using Generics or not.
>
> > I can also have methods that are more
> > straightforward and return objects that are automatically cast to the
> > proper class. VERY handy.
> Now that's a good reason. Readability for the template designers is
> something that needs good care of.
>
> > Even for commonly used, less complicated collections, using a wrapper
> > is sometimes nice. For example, I have a wrapper for HashMap<String,
> > String> that is immutable and comes in handy for storage as a web
> > session attribute. It's the only way I can retrieve something that
> > acts like HashMap<String,String> from a session attribute, since you
> > can't cast to a class-with-Generics in Java 1.5.
> Didn't know that. Can you give an example of when you can't cast it?
> I tried it, but the compiler gave me no errors (only "Unsafe type
> operation" warnings), and running it gave me no ClassCastException's.
>
> > In my case, it
> > avoids a lot of warning:unchecked compilation messages in my web
> > applications.
> Or is this what you are talking about?
>
> > Probably more than you wanted to know. Despite writing extra classes
> > (but not many) and a lot of frustration having to sort out what
> > Generics can and cannot do, in the end I think they are a BIG plus for
> > developers who can adapt.
> Of course, I'll bet such developers can adapt to Generics as well. ;)
>
> Well, here's the sample for Generics and Velocity:
> -- Java code
> VelocityContext context = new VelocityContext();
> List<Map<String, String>> list = new ArrayList<Map<String, String>>();
>
> Map<String, String> map1 = new HashMap<String, String>();
> map1.put("id", "1");
> map1.put("name", "Barbara Baughman");
> list.add(Collections.unmodifiableMap(Collections.synchronizedMap(map1)));
>
> Map<String, String> map2 = new HashMap<String, String>();
> map2.put("id", "2");
> map2.put("name", "Shinobu Kawai");
> list.add(Collections.unmodifiableMap(Collections.synchronizedMap(map2)));
>
> context.put("maplist",
> Collections.unmodifiableList(Collections.synchronizedList(list)));
>
> -- Velocity Template
> #foreach($map in $maplist)
> $map.id:$map.name
> #end
>
> -- Output
> 1:Barbara Baughman
> 2:Shinobu Kawai
>
> Nothing changes for the Template even if you remove the Generics. :)
>
> Best regards,
> -- Shinobu Kawai
>
> --
> Shinobu Kawai <sh...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Defining iterator for #foreach
Posted by Shinobu Kawai <sh...@gmail.com>.
Hi Barbara,
Nice to know that Velocity is working with Java 5. ;)
> I prefer immutable classes because they are threadsafe, can't be
> changed by the template designer, and follow Joshua Bloch's advice in
> the book Effective Java (an excellent read, BTW).
I haven't read the book, so I don't know what's said in it, BUT you
can make it thread safe by Collections.synchronized*. Say you have a
List called list. You can get what you need by
List listForTemplate =
Collections.unmodifiableList(Collections.synchronizedList(list))
Okay, so it's a bit annoying. ;)
> A wrapper class (call it MapList<K,V>) for Vector<SimpleMap<K,V>> is a
> lot handier that writing Vector<SimpleMap<K,V>> when I use this
> particular formulation a lot and pass it to the template designers.
Ah, you have a List of Map's. That makes it harder.
> It is also easier for my template designers to use MapList<K,V> than
> trying to understand the intricacies of Generics in JAVA when the
> specification gets complicated.
Actually, I don't think the template designers even care about
Generics. All they need to know is, "What are the public methods I
can use?". I put a sample at the end of this message. The Velocity
template will look the same, using Generics or not.
> I can also have methods that are more
> straightforward and return objects that are automatically cast to the
> proper class. VERY handy.
Now that's a good reason. Readability for the template designers is
something that needs good care of.
> Even for commonly used, less complicated collections, using a wrapper
> is sometimes nice. For example, I have a wrapper for HashMap<String,
> String> that is immutable and comes in handy for storage as a web
> session attribute. It's the only way I can retrieve something that
> acts like HashMap<String,String> from a session attribute, since you
> can't cast to a class-with-Generics in Java 1.5.
Didn't know that. Can you give an example of when you can't cast it?
I tried it, but the compiler gave me no errors (only "Unsafe type
operation" warnings), and running it gave me no ClassCastException's.
> In my case, it
> avoids a lot of warning:unchecked compilation messages in my web
> applications.
Or is this what you are talking about?
> Probably more than you wanted to know. Despite writing extra classes
> (but not many) and a lot of frustration having to sort out what
> Generics can and cannot do, in the end I think they are a BIG plus for
> developers who can adapt.
Of course, I'll bet such developers can adapt to Generics as well. ;)
Well, here's the sample for Generics and Velocity:
-- Java code
VelocityContext context = new VelocityContext();
List<Map<String, String>> list = new ArrayList<Map<String, String>>();
Map<String, String> map1 = new HashMap<String, String>();
map1.put("id", "1");
map1.put("name", "Barbara Baughman");
list.add(Collections.unmodifiableMap(Collections.synchronizedMap(map1)));
Map<String, String> map2 = new HashMap<String, String>();
map2.put("id", "2");
map2.put("name", "Shinobu Kawai");
list.add(Collections.unmodifiableMap(Collections.synchronizedMap(map2)));
context.put("maplist",
Collections.unmodifiableList(Collections.synchronizedList(list)));
-- Velocity Template
#foreach($map in $maplist)
$map.id:$map.name
#end
-- Output
1:Barbara Baughman
2:Shinobu Kawai
Nothing changes for the Template even if you remove the Generics. :)
Best regards,
-- Shinobu Kawai
--
Shinobu Kawai <sh...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Defining iterator for #foreach
Posted by Barbara Baughman <ba...@utdallas.edu>.
I prefer immutable classes because they are threadsafe, can't be
changed by the template designer, and follow Joshua Bloch's advice in
the book Effective Java (an excellent read, BTW).
I find myself creating wrapper classes for specific Generic types of
collections in Java 1.5. Those who have not tackled Generics in JAVA
1.5 (or JAVA 5.0) will not appreciate the following explanation very
much.
A wrapper class (call it MapList<K,V>) for Vector<SimpleMap<K,V>> is a
lot handier that writing Vector<SimpleMap<K,V>> when I use this
particular formulation a lot and pass it to the template designers.
It is also easier for my template designers to use MapList<K,V> than
trying to understand the intricacies of Generics in JAVA when the
specification gets complicated. I can also have methods that are more
straightforward and return objects that are automatically cast to the
proper class. VERY handy.
Even for commonly used, less complicated collections, using a wrapper
is sometimes nice. For example, I have a wrapper for HashMap<String,
String> that is immutable and comes in handy for storage as a web
session attribute. It's the only way I can retrieve something that
acts like HashMap<String,String> from a session attribute, since you
can't cast to a class-with-Generics in Java 1.5. In my case, it
avoids a lot of warning:unchecked compilation messages in my web
applications.
Probably more than you wanted to know. Despite writing extra classes
(but not many) and a lot of frustration having to sort out what
Generics can and cannot do, in the end I think they are a BIG plus for
developers who can adapt.
Barbara Baughman
X2157
On Tue, 19 Oct 2004, Shinobu Kawai wrote:
> Hi Barbara,
>
> > Actually, I was trying to create a class that was immutable, which
> > means I wouldn't want to implement Collection. If I have the class
> > just implement Iterator would that do it?
> A bit off topic, but would one of the Collections#unmodifiable*
> methods work for you?
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collections.html
> I mean, you wouldn't want to re-implement a fully tested function
> already supplied in java, do you?
>
> Best regards,
> -- Shinobu Kawai
>
> --
> Shinobu Kawai <sh...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Defining iterator for #foreach
Posted by Shinobu Kawai <sh...@gmail.com>.
Hi Barbara,
> Actually, I was trying to create a class that was immutable, which
> means I wouldn't want to implement Collection. If I have the class
> just implement Iterator would that do it?
A bit off topic, but would one of the Collections#unmodifiable*
methods work for you?
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collections.html
I mean, you wouldn't want to re-implement a fully tested function
already supplied in java, do you?
Best regards,
-- Shinobu Kawai
--
Shinobu Kawai <sh...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Defining iterator for #foreach
Posted by Barbara Baughman <ba...@utdallas.edu>.
Thanks to Simon for pointing me in the right direction.
Implementing all the methods in the Collection interface did the
trick.
Barbara Baughman
X2157
On Mon, 18 Oct 2004, Barbara Baughman wrote:
> Well, I think I answered my own question. It's NO.
>
> Barbara Baughman
> X2157
>
> On Mon, 18 Oct 2004, Barbara Baughman wrote:
>
> > Actually, I was trying to create a class that was immutable, which
> > means I wouldn't want to implement Collection. If I have the class
> > just implement Iterator would that do it?
> >
> > Barbara Baughman
> > X2157
> >
> > On Mon, 18 Oct 2004, Simon Christian wrote:
> >
> > > Hi Barbara,
> > >
> > > I believe that either your class will need to implement the Collection
> > > interface, or you'd need to call the iterator() method explicitly i.e.
> > >
> > > #foreach( $element in $myObj.iterator() )
> > >
> > > Of course Velocity will complain/warn you about the fact that the
> > > iterator is not reusable. However it sounds like you've all but
> > > implemented the Collection anyway - providing you're able to extend
> > > java.util.AbstractCollection (leaving only size() and iterator() to
> > > implement).
> > >
> > > - simon
> > >
> > >
> > > Barbara Baughman wrote:
> > > > It looks like, for the first time, I am passing an object to a foreach
> > > > loop that that is not a Vector, HashMap, or Array.
> > > >
> > > > I instead have a class that essentially wraps a Vector of a certain
> > > > type. It includes a method:
> > > >
> > > > public Iterator iterator() {
> > > > return v.iterator(); // return iterator of the underlying Vector
> > > > }
> > > >
> > > > I thought all classes with iterators would work with a #foreach loop
> > > > (even though I don't see that in the documentation. However, I get
> > > > the error message:
> > > >
> > > > Mon Oct 18 11:22:49 CDT 2004 [warn] Could not determine type of
> > > > iterator in #foreach loop at [0,0] in template member/info/facstaff.vm
> > > >
> > > > The template output only provides one blank line, even though the
> > > > size() method indicates there are 84 members.
> > > >
> > > > Any hints or tips?
> > > >
> > > > Barbara Baughman
> > > > X2157
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Defining iterator for #foreach
Posted by Barbara Baughman <ba...@utdallas.edu>.
Well, I think I answered my own question. It's NO.
Barbara Baughman
X2157
On Mon, 18 Oct 2004, Barbara Baughman wrote:
> Actually, I was trying to create a class that was immutable, which
> means I wouldn't want to implement Collection. If I have the class
> just implement Iterator would that do it?
>
> Barbara Baughman
> X2157
>
> On Mon, 18 Oct 2004, Simon Christian wrote:
>
> > Hi Barbara,
> >
> > I believe that either your class will need to implement the Collection
> > interface, or you'd need to call the iterator() method explicitly i.e.
> >
> > #foreach( $element in $myObj.iterator() )
> >
> > Of course Velocity will complain/warn you about the fact that the
> > iterator is not reusable. However it sounds like you've all but
> > implemented the Collection anyway - providing you're able to extend
> > java.util.AbstractCollection (leaving only size() and iterator() to
> > implement).
> >
> > - simon
> >
> >
> > Barbara Baughman wrote:
> > > It looks like, for the first time, I am passing an object to a foreach
> > > loop that that is not a Vector, HashMap, or Array.
> > >
> > > I instead have a class that essentially wraps a Vector of a certain
> > > type. It includes a method:
> > >
> > > public Iterator iterator() {
> > > return v.iterator(); // return iterator of the underlying Vector
> > > }
> > >
> > > I thought all classes with iterators would work with a #foreach loop
> > > (even though I don't see that in the documentation. However, I get
> > > the error message:
> > >
> > > Mon Oct 18 11:22:49 CDT 2004 [warn] Could not determine type of
> > > iterator in #foreach loop at [0,0] in template member/info/facstaff.vm
> > >
> > > The template output only provides one blank line, even though the
> > > size() method indicates there are 84 members.
> > >
> > > Any hints or tips?
> > >
> > > Barbara Baughman
> > > X2157
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Defining iterator for #foreach
Posted by Barbara Baughman <ba...@utdallas.edu>.
Actually, I was trying to create a class that was immutable, which
means I wouldn't want to implement Collection. If I have the class
just implement Iterator would that do it?
Barbara Baughman
X2157
On Mon, 18 Oct 2004, Simon Christian wrote:
> Hi Barbara,
>
> I believe that either your class will need to implement the Collection
> interface, or you'd need to call the iterator() method explicitly i.e.
>
> #foreach( $element in $myObj.iterator() )
>
> Of course Velocity will complain/warn you about the fact that the
> iterator is not reusable. However it sounds like you've all but
> implemented the Collection anyway - providing you're able to extend
> java.util.AbstractCollection (leaving only size() and iterator() to
> implement).
>
> - simon
>
>
> Barbara Baughman wrote:
> > It looks like, for the first time, I am passing an object to a foreach
> > loop that that is not a Vector, HashMap, or Array.
> >
> > I instead have a class that essentially wraps a Vector of a certain
> > type. It includes a method:
> >
> > public Iterator iterator() {
> > return v.iterator(); // return iterator of the underlying Vector
> > }
> >
> > I thought all classes with iterators would work with a #foreach loop
> > (even though I don't see that in the documentation. However, I get
> > the error message:
> >
> > Mon Oct 18 11:22:49 CDT 2004 [warn] Could not determine type of
> > iterator in #foreach loop at [0,0] in template member/info/facstaff.vm
> >
> > The template output only provides one blank line, even though the
> > size() method indicates there are 84 members.
> >
> > Any hints or tips?
> >
> > Barbara Baughman
> > X2157
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Defining iterator for #foreach
Posted by Simon Christian <si...@stoutstick.com>.
Hi Barbara,
I believe that either your class will need to implement the Collection
interface, or you'd need to call the iterator() method explicitly i.e.
#foreach( $element in $myObj.iterator() )
Of course Velocity will complain/warn you about the fact that the
iterator is not reusable. However it sounds like you've all but
implemented the Collection anyway - providing you're able to extend
java.util.AbstractCollection (leaving only size() and iterator() to
implement).
- simon
Barbara Baughman wrote:
> It looks like, for the first time, I am passing an object to a foreach
> loop that that is not a Vector, HashMap, or Array.
>
> I instead have a class that essentially wraps a Vector of a certain
> type. It includes a method:
>
> public Iterator iterator() {
> return v.iterator(); // return iterator of the underlying Vector
> }
>
> I thought all classes with iterators would work with a #foreach loop
> (even though I don't see that in the documentation. However, I get
> the error message:
>
> Mon Oct 18 11:22:49 CDT 2004 [warn] Could not determine type of
> iterator in #foreach loop at [0,0] in template member/info/facstaff.vm
>
> The template output only provides one blank line, even though the
> size() method indicates there are 84 members.
>
> Any hints or tips?
>
> Barbara Baughman
> X2157
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org