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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
