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

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?