On Tue, Feb 10, 2009 at 3:10 PM, Rickard Öberg <[email protected]> wrote:
> The idea here is that you start either from scratch and just set initial > values and do newInstance(), or you start with an existing value, which > you then copy into this builder by doing copyOf(oldValue). Then the > builder instantiates a *mutable* copy on value(), which the user can > mutate and do Swing binding on, and so on, and the final instance is > created by doing newInstance() which creates an immutable instance with > the configured state. > > This should make it trivial to both view and edit values, and then write > back the new state to the entity. > > What do you think? Does this make sense? yes, better than what I just suggested. But, why would it be <T extends ValueComposite>, since we don't have that restriction elsewhere? Same algorithm could be applied. Now, question is how we handle this along a timeline; 0.6 --> I wanted that out soonish. Better Value support --> in this release or 0.7?? Cheers Niclas -- http://www.qi4j.org - New Energy for Java _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
