CALL FOR: Functions Framework
Called by: Michiel Meeuwissen Total tally on this call : +5
YEA (6) : Pierre van Rooden, Daniel Ockeloen, Eduard Witteveen, Gerard van Enk, Kees Jongenburger, Nico Klasens
ABSTAIN (3) : Jaco de Groot, Rob Vermeulen, Rico Jansen
NAY (1) : Rob van Maris
VETO (0) :
No votes, assumed abstained (5): Marcel Maatkamp, David van Zeventer, Johannes Verelst, Mark Huijser, Vincent van der Locht
Vote passed, code can be added.
Pierre van Rooden wrote:
CALL FOR: functions-framework CALLED By: Michhiel Meeuwissen
This call has been extended to wednesday 16/12/2003 12:00, due to too few (or unclear) votes.
Previous votes: YEA (4) : Pierre van Rooden, Daniel Ockeloen, Eduard Witteveen, Gerard van Enk ABSTAIN (2) : Rob Vermeulen (assumed), Rob van Maris (assumed) NAY (2) : Kees Jongenburger, Rico Jansen
Changes to the previous call: Michiel has provided a more extensive explanation of his hack. See his email of 12/11/2003 17:19
Please review your previous votes, or vote if you haven't voted yet. If this votes makes it, the code will be added to 1.7. If you do not wish it to be added to this release (but do want to have it added in a future one) indicate so in your post.
Michiel Meeuwissen wrote: > Hello, > > Since MMBase 1.6 the MMBase bridge has had an 'getFunctionValue' method on > Node, which worked together with the 'executeFunction' method of the core's > MMObjectBuilder and its extensions. In the bridge can be found also other > methods wich do look like this, like the getInfo, getList and process on > Module and NodeManager. > > Some of this functionality can be called in a rather ad-hoc way in the > taglib (e.g. <mm:nodeinfo type="gui" />). A generic way to call the > 'getFunctionValue' of Node via Taglib was not existing, and it was planned > to solve this in 1.7. > > The thing is that you want like to have a way to check which parameters are > available on certain functions. Also because getFunctionValue wants a list > of parameters, while in taglib you obviously would want to set parameters by > name rather then by position, which can readily by solved if only you can > know wich parameters actually are possible on given function. > > Of course, it is usefull to know the parameters of a function anyway, > because you can check them then, and give useful error messages if something > looks odd. > > To solve this genericly we want to lay down a simple framework around a > 'Function' object, which contains the meta-information about a piece of > functionality (parameters, return type, descriptions), and a way to execute > itself (given values for the parameters). > > Specializations of the Function object can then perform tasks as finding the > parameters, and the actual execution. > > For taglib, things would be limited to providing to a 'function factory' the > right arguments (e.g. a Node object (or perhaps a NodeManager object) should > be given if it is looking for a function on a node). After that, everything > could be the same, it does not matter anymore where and how the function was > defined and implemented. > > This hack proposes to add this frame-work to MMBase 1.7. It is closely > related to taglib, mmci and apps2 but since it will be implemented next to > it, and perhaps will define the way how to work with extra functionality in > MMBase in the future, we felt that a vote is required. > > We also will add a Function implementation for functions which are more or > less stand alone (plus a way in taglib to call them). These functions are > defined in XMLs (in config/functions) , and can call any java functionality > (using reflection). They can be grouped in 'sets' (like namespaces). Think > of e.g. a 'forum' set of functions like 'removeThread', 'addForum' etc... > > As a second example of a Function we've implemented NodeFunction which will > use reflection to find a java-constant in the MMObjectBuilder extension > which should define the parameters of the functions of 'executeFunction' (if > you check the current taglib use in 1.7 e.g. in the cloud context security > editors, you see that as a temporary solution I simply specified this > constant directly, which is very ugly). > > Of course, the precise way of how to define a function on a Node can be > different too, as long there is a simple way to ask 'I want a Function > object for this Node and a function with this name', it does hardly matter > how it is implemented. (I can imagine that executeFunction itself may be > based on reflection too, and that simply an extra method will be added to > receive the arguments) So, the decision on what it the 'preferred way' can > be postponed, but for the moment we need _a_ way, otherwise taglib of 1.7 > will not be forward-compatible. > > As of yet, we don't have a working implementation for functions on > Nodemanagers or Modules, but these could simply be added as soon as the > frame-work itself is agreed upon. > > > We want to have your vote about this hack, and also your opionion about the > package of the framework: > [ ] org.mmbase.util.functions (currently the implementation is here, and can be > found in > speeltuin/mihxil/functions, if you want to actually get the thing working, > send me a message, and I'll send you an MMBase patched on the right > places (e.g. I renamed the already existing (but new) > 'org.mmbase.util.Argument' to > org.mmbase.util.functions.Parameter)) > > [ ] org.mmbase.functions > [ ] org.mmbase.bridge.functions > [ ] org.mmbase.core.functions > [ ] org.mmbase.module.core.functions > [ ] something else: > > > START OF CALL: 2003-11-24 > END OF CALL: 2003-11-27 > > [_] +1 (YES) > [_] +0 (ABSTAIN ) > [_] -1 (NO), because : > [_] VETO, because:
-- Pierre van Rooden Mediapark, C 107 tel. +31 (0)35 6772815 "Never summon anything bigger than your head."
