> 1) We can add function classes that extend an interface to invoke the > function calls (the interface should implement some things like the > executeFunction method that is already present in MMObjectBuilder). We
> can specify in object.xml which function classes can be used by a > specific builder to evaluate functions. Defining the function class in > object.xml will of course enable the function class for all builders. > > 2) At irc, Daniel was talking about working the other way around. To > define in the function classes to which builders the functions should > apply. In this case you can add function classes and without modifying > your builder configurations the functions can be used. There is already > some thing like function sets in MMBase (1.7), but i don' t know how > they work. But maybe it's possible to provide the functions as function > sets. I think both are correct. we can create a PlugableBuilder (that is confidured via builder.xml properties) That uses the function framework. This all relates to the field type project that aims a creating "field types:)". I hope the field type project wil make it -easyer to create new field types (timestamp etc). -add field validation logic ( 2 < x < 20) Still if we look at the html() pml() functions those will be uses by multiple field types so they should be implemented else where(also in the taglib). the xml configuration daniel uses (I haven't seen it) sounds like the way to go. If we look at images we have yet a new problem images use a few fields to store the data (handle/type/size?) and has a few functions (convert / get cached node etc) that depend on a few fields to be avaiable in the builder (handle/itype). so (builder.java and builder.xml depend no each other) Since we do not support multiple inheritance when you want to create a "PublishingImageBuilder" your is trouble. Im' in favour of delegating functionality of builder to separate classes (PublishingImageBuilder) (and now in xml in code) <builder name="publishableimages" implements="images,publishable" extends="object"/> This aporach requires us to think in a other way about functions. I think we are creating a few solutions that "bite each other a bit" -functions -fieldtypes -richtext (a field with relations -> a field is an Object?) -Builder "field" functions (convert,html,pml) -Builder fuctions (gui())
<<winmail.dat>>
