Nico Klasens <[EMAIL PROTECTED]> wrote: > 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. Indeed. > 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. Yes, but it also provides a way to access them by name, rather then by position. This can be desirable, especially if the number of parameters gets big, and certainly when there would be even no type checking. > 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. It it not targeted principally at reducing the number of tags, functions tags can be used to access functionallity for which there are no tags, for ad hoc things, for which no tags were anticipated. They can also be used to call functionallity genericly, a bit like reflection. I used for exmpample function tags for functionality like 'grant' in the cloud context security editors, because there is no 'mm:grant' tag available, and perhaps an 'mm:grant' tag could not even be made, because a security implementation independent 'grant' function could not be provided. The other option would have been a 'ccsecurity:grant' tag which also seems an overkill, because chances are that there will be no more cloud security editors implementations.. If people want to add custom-tags for specific functionality then that is of course still possible. > 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? To start with I'll add/update the function tags. There will also be added something to access the executeFunction functions, so a method 'getFunctionParameters' on MMObjectBuilder would come in very usefull. MMCI project can decide to add the same function on Node too. Later, we'll implement 'ModuleFunction' and 'NodeManagerFunction' (function project?), and decide how these should be instantiated. Daniel also has a functions impl. based on an XML, which also can give Function objects back. I suppose this will be available in 1.7.1 or so. Michiel -- Michiel Meeuwissen Mediapark C101 Hilversum +31 (0)35 6772979 nl_NL eo_XX en_US mihxil' [] ()
