[
http://issues.ops4j.org/browse/QI-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607#action_13607
]
Stanislav Muhametsin commented on QI-272:
-----------------------------------------
As for 1. and 2., I think their behaviour should be identical (creating entity
- different methods, but must behave in same way!).
As for 3, by "overriding Property methods" I mean defining interface like
public interface A
{
public Property<String> prop();
}
and then, in mixin for A, implement method prop(). So maybe word 'override' was
a little poor choice there.
As for setting Identity property, the .set( ENTITY_ID ) was just quick code to
make test case test what I wanted. The code in other mixin does it a little
better. Of course, it would be blatantly wrong in any 'actual' implementation.
But, perhaps, the whole reason behind setting identity needs a little
clarifying.
Let's say we are making some role-playing game. Typically, the player character
in this game has various attributes, like hit points, skills, etc. The
character is also of certain race. In most classic cases, the race may be
Human, Dwarf, Elf, etc. Now, this transforms roughly into something like this,
in code:
public interface Creature
{
public enum Race { HUMAN, DWARF, ELF, ... }
public Property<Race> race();
}
This works fine for a while. Then, at some point, we want our game to be
customizable by players. We want players to be able to create their own maps,
items, and, most importantly for this example, their own races. But the race
pool is currently statically fixed, and may not be extended. So, we refine a
little:
public interface CreatureRace extends EntityComposite
{
public Property<String> raceID();
public Property<String> raceName();
}
and the Creature becomes
public interface Creature
{
@Immutable
public Association<CreatureRace> race();
}
So now the race-pool may be easily extended by player mods - simply add a new
CreatureRace to entity store. However, it would be nice to take care about data
integrity - we don't want may races with same raceID in there. The most simple,
straightforward, and most efficient way is to make the identity for race to
reflect the enum-behaviour of the CreatureRace. Let the core constraints of
entity stores take care of this - as they should.
Also, we want this logic into CreatureRace code, and not client code, as it
would be repetetive (always pass identity constructed in same way to
EntityBuilder), and would expose this logic to clients. So, we add a Lifecycle
hook:
public abstract class CreatureRaceLifecycleHook implements CreatureRace,
Lifecycle
{
@This EntityComposite _meAsEntity;
@This CreatureRace _meAsRace;
public void create()
{
// Make instance of this race unique in its type, based on race-id
this._meAsEntity.identity().set(this._meAsEntity.type().getName + "[" +
this._meAsRace.raceID().get() + "]");
}
...
}
Now, the client code may create as many CreatureRaces as it wants, and it does
not need to always specify a custom entity ID for EntityBuilder. And our
lifecycle-hook should take care that there are never two CreatureRaces with
same ID in entitystore. Simple and elegant, IMO.
> Changing properties in Lifecycle sometimes doesn't work
> -------------------------------------------------------
>
> Key: QI-272
> URL: http://issues.ops4j.org/browse/QI-272
> Project: Qi4j
> Issue Type: Bug
> Components: Core Runtime
> Affects Versions: 1.2
> Environment: Qi4j.
> Reporter: Stanislav Muhametsin
> Assignee: Rickard Öberg
> Fix For: 1.3
>
> Attachments: lifecycle_test.zip
>
>
> If a mixin implementing Lifecycle method tries to change state of entities,
> the behaviour splits in three parts.
> 1. If entity is created via UnitOfWork's newEntity method, the constraints
> are checked. This might result in ConstraintViolationException being thrown.
> 2. If entity is created via EntityBuilder's newInstance method, the
> constraints are not checked. IMHO this is the desired behaviour.
> 3. If mixin overrides Property<...> methods, and is created via
> EntityBuilder's newInstance method, the property values are set incorrectly.
> The test case is attached. For case nr 3, my educated guess is that in
> JSONEntityState, the stateName.name() is used instead of stateName.toString()
> when setting properties. Additionally, the identity -property is outside the
> normal properties-object, which means that if user changes the identity()
> property for entity prototype, it won't get updated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.ops4j.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
