> Indeed. Then I will stick to my vote :-)
> 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. The advantage of by position is that the page author is required to write it always the same way. It is consistent and that makes it a firm base. But it is up to the function implementer how the error detection (preconditions) are handled. The advantage of by name is that the page author has written out what value should be mapped to what parameter. So it is made explicit instead of implicit. With the abstraction of functions some error detection could be separated from the function implementation which makes it easier for the function implementer. So the functions abstraction could reduce the bugs in the future. > 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 would prefer a taglib for ccsecurity if it implements some cc specific functionality. The cc taglib can be used in all application pages if the page author wants to do some cc security checking. A taglib makes things explicit. I only see the usefulness of function tags when something complicate has to be done which is hard in a jsp-scriplets or to delegate the responsibility to some other part of the system. > 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. So the implementation of the abstraction is not final yet and will be done in a project. I hope the dependencies don't make too much assumptions about how the final implementation will look like. Nico Klasens Finalist IT Group Java Specialists
