----- Original Message -----
From: "Wendy Smoak" <[EMAIL PROTECTED]>
Subject: RE: Please respond, I am at a roadblock, Tomcat cannot find sette r
method
> Jim wrote:
> > Furthermore I have received a reply from another user that he
encountered
> > the same problem with an attribute "class" which he had to rename to
> "clasz"
> > order to get it to work.
>
> That's entirely different -- 'class' is a java keyword.
> Something like:
> String class = "abc";
> will not compile.
I have to assume that the person who gave me that example did not name the
member "class", but just wanted to use an attribute "class". But I only
give that as an example that I am not the only person who is having this
problem.
>
> One thing that bothered me, looking at the code for the base class
> (QueryTag):
>
> public void setLang( String lang ) { ... }
> public int getLang() { ... }
>
> Can you mix types like that? I'm just scanning through the JavaBeans spec
> and all of the examples I see have matching types:
>
> public void setThing ( SomeType var )
> public SomeType getThing ( )
>
> Perhaps someone more familiar with the spec can comment, but I would try
> changing the 'get' to a String.
>
> Is it possible that the system "sees" the 'int' signature of the getter
> method, and is looking for exactly:
> public void setLang ( int lang)
> which it cannot find?
I will grant you that. However I don't see anyplace where it is actually
stated that the tag class actually has to be a bean. Of course I have not
yet found the section in the JSP spec where it actually describes how JSP
supports attributes on custom tags. That is despite searching for all
occurrences of "attribute" and "setter" in the spec. I am therefore limited
to the discussion of this in Marty Hall's book. If getLang returned a
String then every place where the attribute is used I would have to
translate it to an int. I have no places in the code where I need to know
the original String value entered by the user. The getLangCode method
returns a case normalized representation. The same is true for MaxRows. At
the bottom beans were created, originally, to support graphical IDEs, and
for that purpose having input and output methods returning strings is only
natural.
I will keep on experimenting.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
