Passing data among nested tags

Question

Hey all,
Man, am I confused. Trying to put together a few simple tags to get some chunks of Java code out of existing jsps. I've read a good part of the Wrox book (Pro JSP?) and the custom tags trail/tutorial, I've got various bits of sample source code, and it's still not clicking. (Part of the problem is the source code is from fairly rich applications, and it's hard to see the forest for the trees.)
Anyway, to get a bit more specific, the general flow is:
1) Query a database to get a list of names of things, say "SELECT widge_group_id, widget_group_name FROM widget_group".
2) Assemble a little form with a dropdown whose elements are the "widget_group_name" from the query.
3) When the user selects an item from the dropdown, we will get a list of things corresponding to what was selected, say, "SELECT <a bunch of widget stuff> FROM widget WHERE widget_id = <widget_id corresponding to selected widget_name>" and pass this list on to a new page or frame that is the result of the form's submit or onChange.
What I thought I'd do for the tags--and yes, I know there are taglibs out there that will do this, and I may end up using one, but for now I've decided to do it this way because a) it will be instructive and b) what I have to do is so small, it seemed it might not justify the overhead of researching, obtaining and learning a 3rd party lib--anyway, what I thought I'd do was have one tag that generated the form with its dropdown, where the list of items to appear in the dropdown was provided from "somewhere else."
The "somewhere else" in this case would be another tag that queried the db and brought back the list of widget group names. As far as the form tag was concerned, the list of dropdown elemenst could come from anywhere.
I'd still need another mechanism (another tag? part of the form tag?) to then get the second list from the db for the next page, but I'm not that far yet.
Basic idea was something like this:
<mine:dropdown>
   <mine:query
      table="widget_group"
      display_column="widget_group_name">
   </mine:query>
</mine:dropdown>Now, yes, I know there's stuff missing--like tying the selection to the submit target. And I know it's not the most general design, but I'm not worried about that now--for me, this is a nice compromise between realistic and simple. That point aside however, I have a couple of questions:
1) Does this design make sense as far as how one tag interacts with the other--that is, the dropdown tag using the services of the query tag in this way? (again, keeping mind this is for instruction, not production.)
2) What's the best way to communicate the results of the query--basically a list of strings--from the inner tag to the outer? TEI? pageContext.getAttribute? ancestor.getThingamabob?
3) Where does all the work go? doStartTag? doEndTag? Elsewhere?
I've read a bunch of docs, looked at sample code, but some of the particulars are just not clicking. I imagine I can get something to work, but I could use a little guidance as far as best practices go.
Thanks!
Jeff

Answer 1

Excelent! At least I know I'm not totally missing the picture.
Ok, this is pretty good. However, I'd do it the other
way around. Use the query-tag as the outer tag and
allow as many dropdowns, textfields et ceteras INSIDE
of that.
Why? Because this way you can just run your query
once, cache the results and then use them for your
input tags. Understood. I think I want the results of the query only to be available to that list. In this case I'm using the query to get specific data needed to populate a specific list. Another list on the page may use the same query tag but with different table and column parameters.
I had considered flipping the nesting order, but for different reasons--namely I didn't know WTF was going on. I've got a fair amount of OO design experience, so where that applies in this arena, I think I'm pretty well covered. However, I'm acutely aware that my tool of choice is a hammer, so I'm wondering if sometimes I'm viewing all manners of problems as nails, when they aren't.
In this particular case, I was viewing my tag nesting as sort of the tag equivalent of
Dropdown dd = new Dropdown(new Query("widget_group", "widget_group_name"));that is, using the "return value" of the query to feed the dropdown.
The problem I have with this is that it appears that things have to be named. I wanted the dropdown and query tags to be completely independent of one another, where the only shared knowledge was that the query "returned" a List of String, and dropdown used a List of String. That works in the method calling analogy above, but in this case, it seems I have to force them to agree on a name. That goes against tens of thousands of lines of Java development experience :-)
2) What's the best way to communicate the resultsof
the query--basically a list of strings--from theinner
tag to the outer? TEI? pageContext.getAttribute?
ancestor.getThingamabob? Again, it depends entirely on you. If you are using
ancestor.getWhatEverAttribute(), this limits your
tags, so that they can only be nested in the order you
defined. Which I think is okay for my needs
Moreso, if you use pageContext, you can use
the results even after your tags, for example
displaying some text as a label outside your form or
whatever. With the ancestor -method, they'll only be
accessible inside the tag, which is fine if you really
want to control their lifecycle and be sure that they
won't "bleed" onto the outer page.Again, I think I want this. I mainly avoided pageContext for name collision avoidance, and because it seemed like a "global variable," which goes against my OO instincts.
Well, for your query tag, you'd definitely wan't to do
the query at the doStartTag() and store the results
somewhere. Then, if you need to iterate over the
resultset, you do that at the doEndTag().Hmm. Okay. First, which tag's start/end are we talking about? Second, why iterate in doEndTag?
Now, if nesting your tags like you suggested, you need
to generate the list at the doEndTag(), since the
query results won't be available during the execution
of the doStartTag() method.Again, whose start/end? I guess you must mean query's results aren't present for dropdown's start, yes?
Actually, now that you mention iteration, that reminds me of another question. I've looked a little bit at the iterate tag provided by struts, and from what I gather, it seems to be a common construct. I'm wondering if there's any reason I'd want such a beast in this situation. It seems simpler just to do the iteration in DropdownTag.java (in doEndTag, from what you say). If that's not the case, why not? And if it is the case, what would be a situation where it's better to use the iterate tag?
Thanks a ton for your help!
Now, one other question...
TagExtraInfo: Docs say it's for when the tag needs to validate something or other, which makes sense, but also to create/read/modify scripting variables. That left me a little confused. We've already got pageContext, so what are scripting variables? Are they things that show up in scriptlets? For instance, if your TEI set a "banana" variable, you could later do <%=banana> ?Thanks again!
Jeff