On Friday 28 November 2003 10:42 am, Michiel Meeuwissen wrote:
> I want to extend the hack.
>
> I'd like to give it another go to explain the situation.
>
> In taglib we obviously need some way to call extra functionality. On nodes
> that can be done already if you use 'functions on fields' like this:
>
> <mm:field id="source" name="url(ram)" write="false" />
>
> This is quite ugly and rather inflexible because:
> - string parsing needed
> - no way to check the parameters in an early stage ('could 'ram' actually be
> a valid argumetn for the url function')
> - no way to leave parameters unfilled, so if a function might need a lot of
> parameters/settings, things get quickly rather messy.
> (url(ram,,,,broadband)?). Practicly it is impossible to feed more than 3 or
> 4 things into a function now.
> - no way to specify parameters of other type then String
>
> So, the hack should perhaps be limited to:
>
> 'Do you agree that a function object (see code in speeltuin) would be a nice
> way to solve this'.
I don't see what this will change , if it's is still possible to call <mm:field
id="source" name="url(ram)" write="false" />
the input is still a string (garbadge in garbage out).
does it also mean that it's not possible any more to create "on the fly function"?
and what's the difference with virtual fields?
should it be defined in de builder xml?
who will it work on cluster nodes?
The worst of the current functions are the parameters (is ram a field of of the
builder?) and if not why use the field tag?
>
> If I can use this Function object (and related Parameters object) I have a
> tool to solve all of the above problems (I actually have most tags ready
> here).
You are now talking about a function tag witch is fine by me(your are leader of the
taglibs project and if you want
to add tags thats your choice (a good one))
If there is a function tag it will solve the input problems
<mm:function name="url">
<mm:param type="string" value="ram"/>
</mm:function>
whats the purpose of the hack?
