Kees Jongenburger <[EMAIL PROTECTED]> wrote:
> >
> > '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).
Still sucks then.
> 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?
Virtual fields are kind of functions without argumetns. What is a 'on the
fly function'? AFAIK that it not possible right now either.
> should it be defined in de builder xml?
No.
>
> who will it work on cluster nodes?
Perhaps.
>
> 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?
It does not make sense to use the field-tag indeed. Therefore I'd like to
implement a function tag.
> 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?
This will not solve imnput problems. Imagine that the functiona ctually has
two arguments:
<mm:function name="url">
<mm:param name="type" value="ram" />
<mm:param name="connection" value="1500" />
</mm:function>
could perhaps send url(ram,1500) to the core.
But what should
<mm:function name="url">
<mm:param name="connection" value="1500" />
<mm:param name="type" value="ram" />
</mm:function>
do then?
There is no way to work with 'named' parameters, because I cannot find out
what parameters (with wich name) are to be set.
Specifying the type is not ofen necessary, because the type is known by
variables themselves.
<mm:param type="string" value="ram"/> is silly.
Leaving it to the order of parameters is not a nice way, if you have lots of
possibillities, and I don't like to make it like this now, because we would
never get rid of it.
Michiel
--
Michiel Meeuwissen
Mediapark C101 Hilversum
+31 (0)35 6772979
nl_NL eo_XX en_US
mihxil'
[] ()
