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!).
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);
}
}
---
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.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
