> [X] org.mmbase.functions
> [ ] org.mmbase.bridge.functions
> [ ] org.mmbase.core.functions
> [ ] org.mmbase.module.core.functions

>  [X] +1 (YEA) 

Well, here are my two cents on the subject.
As I understand from the postings, the speeltuin has code which can be
divided into two categories.
1: the abstraction of functions consisting the classes Function, Paramaters,
Paramater and ReturnType
2: the implementation examples of the abstraction in use.
And the vote is only about 1, right? The rest of the stuff in the postings
is about how 1 could be used in different parts of MMBase.
When I read the other postings I had the feeling that the question asked is
"Do we really need it?".

1 is a good starting point to make the executeFunction in the builders less
hardcoded. This will clean up the builder code. On the other hand, it could
be a too heavy framework to call builder (node field) functions just to get
it type-safe. IOW it provides a way to do error detection on the passed
parameters.

Examining the examples jsp's, it looks like that the function-tags are
replacing other tags to reduce the number of tags in the taglib. By doing
this, it becomes a lot harder to read the jsp's. The taglib is targeted at
page authors. One of the main difficulties a page author is faced with is
the need to use a scripting language to manipulate the dynamic data within a
JSP page. Unfortunately, page authors often see scripting languages as
complex (This is one of the reasons the JSTL was made). By reducing the tags
it will become more complex.

I like the idea of an mm:function with the mm:param to call functions, but
the question again is that this might be a too heavy approach to get it
type-safe (Page author error detection).

So I don't mind that the abstraction of functions is added to the release.
It could be an improvement. 
What confuses me is that the abstraction alone has no dependencies with the
other source code. Which places of the source code will be modified to have
dependencies with the functions abstraction?

Nico Klasens

Finalist IT Group
Java Specialists


Reply via email to