tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Kettering <>
Subject Re: Google Search Tag
Date Wed, 21 Aug 2002 17:27:09 GMT

Yes, this does make sense.  I forgot about the fact that JSTL is going to be
a standard and supposedly included with all JSP containers in the future, so
it'd make sense to make it use JSTL at the time being.

I'll start wrapping the ResultElement and Result objects in a bean.  That
should be relatively simple.

However, where would be a good place (source code) to look at to get ideas
how to implement JSTL within my tags?  Preferably something not so complex.

I also received this post from the Google API team on the public newsgroups
after announcing my tag there.  I know its a far cry from a 100% legal
endorsement, but they at least seem to be supportive of the idea.

From: Google Web APIs Team (
Subject: Re: ANN: Google Search Tags
Newsgroups: google.public.web-apis
View this article only
Date: 2002-08-20 14:33:26 PST

Thanks for sharing your JSP tag library with us. Looks great! If
people build interesting web sites that make use of this, we'd love to
see them.


> I would recommend going with JSTL dependence. You'd be leading edge, but
> it would be good learning and would save a port in 6 months.
> Wrapping the ResultElement with a bean seems a good idea to me. In a long
> term world, you'd find yourself improving the google taglib to handle
> other search-engines as they release their APIs.
> Have grabbed the taglib and will look at over next day or two.
> I think the interest shown already is good evidence that a taglib would be
> viable. The biggest issue is probably the licencing.
> Hen
> On Tue, 20 Aug 2002, Tim Kettering wrote:
>> I actually thought about this, but theres a few things I wasn't sure about
>> (I'm still new to coding custom tags).
>> 1) If I wanted to use EL, I would have to require the use of the taglibs
>> standard library with the google tag - and I wasn¹t sure if I wanted to
>> increase the requirements to run this library.
>> 2) I would have liked to eliminate the need for the resultelement tag, and
>> instead call the values directly, but the problem is that the
>> GoogleSearchResultElement isn't a JavaBean, as far as I can tell, so that
>> means I wouldn¹t be able to use EL to call the values directly?  Or am I
>> mistaken.
>> I could write a wrapper for the GoogleSearchResultElement that would put a
>> layer of Bean functionality on top, to allow for introspection... Thoughts?
>> I realize that its somewhat complex, and that¹s why I was soliciting
>> feedback on it from this list.
>> -tim
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

Tim Kettering

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message