On Mon, Aug 1, 2011 at 11:16 AM, Rickard Öberg <[email protected]> wrote:
> In that case, it has to become easier to declare defaults I think. It's a
> bit messy right now, as the defaults are not clearly related to the
> composite that it should be applied to.
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).
> With the current Application/Layer/Module setup I think you can do both
> traditional pancake, onion and hexagonal architectures, which should be good
> enough. Is there anything in the current structure that you see do not
> support e.g. onion architectures?
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...
> 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?
>> Since my project at work is now cancelled, I will try and re-implement
>> some of the grid features that I put in place there;
>> * Trails - Command/Event sequences which recorded method calls and
>> log statements in a 'trail' so one could troubleshoot a single
>> 'invocation' (for instance a timer tick).
>>
>> * Commands - Command Objects are dispatched to the node where the
>> Aggregate Root resides and execute there to reduce network traffic.
>> Full recoverability in case of JVM or hardware failures.
>>
>> * Events - Many grid nodes subscribe to the same event at the same
>> location in the code. But most often one only wants one of the event
>> handlers to receive it, typically resulting in further processing.
>
> We already have an Event-library, which probably could be expanded to
> support the above. Adding a complementary Command-library for the incoming
> side should be possible, based on the same pattern.
I am not sure that it is completely suitable for clustered
environments. I would say "I'll take a look and suggest..." if there
are some doc describing the 'bigger picture'. ;-)
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
