On 1/5/11 9:14 AM, David M. Lloyd wrote:
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.
This is true. The client can decide how to handle this themselves.
Simply returning PROPERTY_EXPRESSION from ModelNode.getType() is enough
to tell the client that the value needs to be resolved; they can decide
what to do with that information.
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.
I see what you've done with that in the latest jboss-dmr. That seems
fine. As long as we javadoc that resolve() is going to resolve using the
system properties in the local VM, which are likely meaningless on the
client, that covers it.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat