On 01/05/2011 08:54 AM, Brian Stansberry wrote:
On 1/5/11 8:17 AM, David M. Lloyd wrote:
>> 2) If there is significant benefit, how can we model this using the
>> simpler type system?
>
> Easy - I can add a PROPERTY_EXPRESSION type which attempts to resolve
> the expression when you call asString()/asInt()/etc. (toString() would
> return the expression).
>
This would need to be done on the server side and the calculated result
shipped to the client.
I'm not sure this is really necessary. I'd think we'd have runtime
operations available to query the actual values in use for these kinds
of things; I think for regular model queries the user would want to read
back the expressions only.
Or maybe the read operation request parameters could contain a flag to
resolve expressions?
I suspect that we'd want to take active steps to prevent the user from
resolving a node in the wrong place though. Maybe an explicit
.resolve() method which copies the current node with all values
resolved? That way the user won't be bitten by a doing .asString() and
suddenly getting a different value than is on the server.
--
- DML