>>>>> "Wendy" == Wendy Smoak <[EMAIL PROTECTED]> writes:
Wendy> I have a DTO that contains a List of objects. Since you can add any Object
Wendy> to a List, I would rather not have a
Wendy> setAssistants( List asst );
Wendy> method that would allow someone to add a list of inappropriate object types.
Wendy> Instead, I want to only have:
Wendy> public List getAssistants();
Wendy> public void addAssistant( PersonView p);
Wendy> I know that having two 'set' methods with the same name but different
Wendy> parameters *really* confuses the introspection/reflection/whatever magic
Wendy> happens with JavaBeans. Learned that one the hard way. :(
Wendy> But what about a 'missing' set method? It _seems_ to be working:
Wendy> <c:forEach items="${trackDto.assistants}" var="asst">
Wendy> <c:out value="${asst.assistant.preferredName}"/> <c:out
Wendy> value="${asst.assistedDate}"/>
Wendy> </c:forEach>
Wendy> I gather that JSTL uses the 'get' method to determine the type of the
Wendy> object, because I'm not specifying that here and it's having no problems.
Wendy> Please stop me now if I'm doing something that's going to cause problems
Wendy> later!
>From a non-authoritative point of view, I can't see how that could be a
problem. You could sort of verify this yourself, by writing some code using
Introspector and BeanInfo. If you get the PropertyDescriptors for the class
and you find that the "assistants" property has a read method but a null write
method, and it did all this without bombing, then the EL will probably be fine
with it.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED] ; SCJP; SCWCD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
