On Tue, 15 Oct 2002, James Cook wrote:
> I wonder why the unnecessary complication here? If they are going to
> use reflection anyway, why subject the users to creating these extra
> xml fragments. A nickname hardly seems worth it, and adding another
> point where a slight syntax problem in an XML document can cause
> additional time deploying and debugging seems pointless.
>
> I hope they see the light and allow EL to invoke _any_ method
> (including non-static) on beans that are exposed in a scoped context,
> ala Velocity, et al
The definition of functions instead of methods was the subject of a lot of
debate. While you're right to point out that it's a little more
complicated for the developer who's defining the functions, the hope was
that it would ultimately be easier for page authors and that it would
facilitate good application design. Functions can abstract data types,
while allowing method calls from the EL specifically avoids this
abstraction. If you have pages that use expressions like
${myList.size()}
then you can't easily change the data type of 'myList' from, say, a List
to an array. However, if we provide a standard 'size' function, then page
authors can write
${size(myList)}
without worrying how 'myList' is implemented.
Moreover, it would be poor practice to encourage the use of methods with
side effects; if we allowed all method calls, we'd simply be reintroducing
scriptlets with a different syntax.
Still, the topic is not one on which everyone agrees; functions do seem
safest for the moment, however.
--
Shawn Bayern
"JSTL in Action" http://www.jstlbook.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
