On 8/1/11 19:45 , Niclas Hedhman wrote:
For our purposes, the declaration of defaults on mixin type interfaces has been good enough. Allowing 'inheritance' of defaults would be even cooler, so that;public interface Abc { Property<Integer> abc(); } public interface Def extends Abc {} module.forMixin( Abc.class ).declareDefaults().abc().set( 25 ); module.forMixin( Def.class ).declareDefaults().abc().set( 100 ); would have a abc() default to 25 except if part of Def type in which case it would be 100. I don't think this exists now, but I think would be more than enough (since module is also involved).
The above should be possible. But, for the "normal case", i.e. I want a string to default to "" or an integer to 0, or a List to be new ArrayList(), it doesn't work as well. Now that Values can be defaulted as well, i.e. "@UseDefaults Property<SomeValue> foo()" will actually cause an instance to be created, that definitely cannot be done through assembly. So, @UseDefaults still has its place.
Really? Doesn't Onion prescribes that the "infra" is injected inwards? So, how would you use our system to declare the picture on http://jeffreypalermo.com/blog/the-onion-architecture-part-2/ ?? I agree that the reasons for "onion" are largely removed by our isolation of 'physical infrastructure' from 'logical/abstracted infrastructure', but since we are debating this issue, why not go the full mile and see what our conclusions are...
Right, true, that can't be done, since the EntityStore is resolved from the point of view of the Entity, which would have none available if pure onion is used. Hmm... what would the benefit be with using onion compared to the more hexagonal approach that we use now?
I'd like to have a simple blobstore, i.e. viewing the SQL database as a plain key-value store.In that case, that sounds incredibly simple to (naive) me... INSERT ... INTO store VALUES key, json SELECT json FROM store WHERE key='123' UPDATE store SET json='{...}' WHERE key='123' Is there any more to it?
That's pretty much it. Again, just using the infrastructure that is usually there, with replication and backups and admin stuff being easy to do. Inspection through e.g. DbVisualizer becomes possible as well.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
