Quoting Rickard Öberg <[email protected]>:
On 2010-09-29 05.28, Stanislav Muhametsin wrote:
Hello people,
I've done quite a lot of refactoring to both sql-indexing, and
entitystore-sql. However, now these projects depend on on other two
projects, which are currently in line to be accepted into public Maven
Repo. So, after these two projects are in the repo, I will push my
changes to Qi4j repo.
The tickets for projects are
https://issues.sonatype.org/browse/OSSRH-826 and
https://issues.sonatype.org/browse/OSSRH-828 .
I had a look at the DCI one, since I'm writing DCI code in
Streamflow as well. One of the things about DCI that is important to
remember is that a context is supposed to map to a usecase, meaning
several interactions. Your code suggests that there is a 1-1
relationship between context-interaction, which is not a good idea.
Also, it is important that the context defines the roles that
objects participating in the interactions should play (which the
current DCI in Streamflow doesn't do, yet!).
Yes, the 1-1 relationship is a tradeoff I knowingly made, since it is
"light-weight" and "simple". Also, now that you mention it, I realize
I forgot to add this info to README file. :)
I know the things are quite different in LWDCI than in Streamflow, and
I think Streamflow is closer to "way to go", but I just needed a
really small, Qi4j-independent (!) framework, with some DCI-ish
properties.
In my own DCI work I'm now basically down to the following for a
context: it's a class, that takes the bound objects either as
constructor arguments or as injected fields, and then each method
corresponds to an interaction. Example:
public class SomeContext
{
interface SomeRole {...}
interface OtherRole {...}
SomeRole some;
OtherRole other;
public SomeContext(SomeRole some, OtherRole other)
{
this.some = some;
this.other = other;
}
public void fooInteraction(String anArg)
{
some.doStuff(other, anArg);
}
public void barInteraction()
{
other.moreStuff(some);
}
}
Yeah, I looked at streamflow code, and it seemed very good. However, I
have a question about RoleMap in Streamflow: you basically forbid the
same type of role to appear twice, is that right? I mean, if I have
two same-type objects, but I want them to be in different 'roles'
(let's say, artificially, that my context is two integers, and my
interaction is addition of integers), what do I do?
---
And that's all. One key point is that the context should correponds
to an object selection in the UI, and then the interactions match
whatever the user can do with them in the UI (through buttons,
context menus, app menus, key shortcuts, etc.). If the UI action
opens up a dialog for some extra info, then that info becomes an
argument to the interaction. If you just invoke an action in the UI
without getting more info, then just fire the interaction without
arguments. The mental models of the UI and the code should be the
same, and that's the point!
So, for a DCI framework there's not a whole lot of things you really
need. If you implement as above, you don't need anything for the
actual application code. Then you can (as I did) do the injection
using annotations. I do:
@Role SomeRole some;
@Role OtherRole other;
where @Role is a custom injection provider in Qi4j that looks up the
object from a RoleMap that I construct in my REST API. The REST API
needs some more frameworky stuff, but the actual DCI part doesn't
(IMO).
So.... simplify, simplify, simplify I guess is what I'm saying.
Thanks for advices, Rickard :) The DCI concepts are maybe a little
hard to fully understand in beginning. That is true, that LWDCI needs
a LOT of simplifying and streamlining, it is kinda clogged after
intense development sessions in other projects using it. I will look
into it later, when I have time.
Main point now is that SQL-generation uses only "Typeable" from LWDCI
API and its implementations (+ skeletons for mapping types to
interactions) from LWDCI SPI. So now I just wanna push these
frameworks to Maven repo, or OPS4J, so that I could finally push the
changes I made to Qi4j.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
