I’m getting sick of these tag attributes!
You’re right. This solution sucks. And it’s tons of code to keep up with. Worse, what if we want to create a suite of custom tags to augment other HTML tags?!
The tag handler class must implement a setter method for each of the tag attributes declared in the TLD. But these setter methods aren’t really doing anything interesting. The values of these attributes are simply passed on to the output generated for the HTML <select> tag.
We could apply an design principle: “Encapsulate that which varies.”[9] In this case the set of optional HTML tag attributes is the thing that varies in this tag handler. One solution would be to put all of the attributes into a hashtable. This generalizes the tag object’s storage of attributes, but what about all these setter methods? We can’t get rid of them unless there’s a way to tell the JSP engine to set the tag attributes using a generic interface.
Relax
You will not be tested on the method signature and definitely not on the purpose of the uri parameter.
Hell, we don’t even know what it’s for.
[9] This design principle ...
Get Head First Servlets and JSP, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
