Re: [jboss-as7-dev] Expressions (Detyped API document feedback)

On 01/05/2011 08:10 AM, Brian Stansberry wrote: > On 1/4/11 11:02 AM, David M. Lloyd wrote: >> >> MetaValues >> >> I agree with some of these types but not others: >> >> * SimpleValue >> + String - yes >> + primitives - some; maybe just boolean/int/long/float/double but >> not byte/short/char for example >> + Date - no, let's use long for now, and revisit once JSR-310 is >> done. Date is basically worthless. >> + BigDecimal/BigInteger - yes >> * CollectionValue/ArrayValue - No, I'd rather see byte[] added to the >> above list and otherwise have a list value type, each element of which >> can be whatever type >> * MapValue - No, we don't need any map key type other than strings >> * CompositeValue - too much work, why not just use a simple map of >> Strings to values? By making the type dependent on the key it's >> basically impossible to use without metatype info >> * TableMetaValue - too complex >> >> I'd rather do something more dynamic where you can start with a node and >> just build up whatever you want from it: >> >> node = new ModelNode(); >> node.get("operation").set("change-bind-port"); // string >> node.get("address").add("base, "domain"); // a list >> node.get("address").add("profile", "web"); >> node.get("address").add("subsystem", "web"); >> node.get("address").add("connector", "ssl"); >> node.get("bind-port").set(8433); // int >> result = connection.execute(node); // goes over remoting >> System.out.println("Result is: " + result); >> // nicely formatted, JSON-style (but with more possible types) >> >> I wipped up a demo of this style of API at: >> https://github.com/dmlloyd/jboss-dmr >> >> Notice there's only one public class and one type enum. (The Validation >> class isn't anything, just an experiment.) >> > > Something I want to work through with this is how is how to handle > values that are really expressions or variable references (e.g. > ${pool.size:10}) that should be resolved on the server. > > Using something like the old jboss-meta library that has different value > types (SimpleValue, CollectionValue, CompositeValue etc), it's fairly > straightforward to handle these. We could add a new value type > ExpressionValue (or modify SimpleValue) and have it expose a few extra > properties: > > String getExpression() > String getDefaultValue() > boolean isResolved() > > plus the standard getValue() > > When a user is reading the domain or host level model, isResolved() > would return false. If the user is reading a server level model, it > would return true, and getValue() would return the resolved value. But > the underlying ${pool.size:10} would still be available, helping users > to understand where the resolved value came from. > > With the simpler type system David proposes, this kind of thing isn't so > easily doable. So, a couple questions to discuss: > > 1) The only place where something like ExpressionValue adds anything is > when reading a server level model, where the resolved value is available > *and* the unresolved value is available. Is there significant benefit in > providing the unresolved value? >

> 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).

Or, I can add asResolved*() which does resolution instead, with asString() returning the expression.