Hi again folks,
In the spirit of revisiting old design decisions, here's another that
I've just spiked: a Property can currently only be declared using a
method in an interface. After some checking and testing I have found
that it is actually fine for Properties to be declared by fields as
well, which solves a problem that I've been having with them, which is
that they are hard to hide.
Here's what I'd have to do currently:
@Mixins(Describable.Mixin.class)
interface Describable
{
void updateDescription(String newDescription);
interface Data
{
Property<String> description();
}
class Mixin
implements Describable
{
@This Data data;
void updateDescription(String newDescription)
{
data.description().set(newDescription);
}
}
}
---
And my Entity would then extend Describable, but not Data.
If instead the Property could be declared as a field, you get this:
@Mixins(Describable.Mixin.class)
interface Describable
{
void updateDescription(String newDescription);
class Mixin
implements Describable
{
@State Property<String> description;
void updateDescription(String newDescription)
{
description.set(newDescription);
}
}
}
---
Which is a whole lot easier. I've tested this (basically changing the
accessor of a Property from Method to AccessibleObject in the model),
and it works great.
The main drawback from this could be that the Query API would be harder
to use. However I have sort of fixed that as well, to some extent at
least. IF the field is declared as public (which is fine since it's
hidden behind a composite proxy anyway), you can do this:
Describable.Mixin mixin = templateFor( Describable.Mixin.class);
Query<PetEntity> query = qb.where( eq( mixin.description, "Rex is a
great dog" ) ).newQuery( Network.pets() );
---
The templateFor method instantiates the mixin and injects fake
properties for all @State Property fields, which act as references that
can be used. I have verified that this works too.
So, since this seems to work, and simplifies state management quite a
bit, I'm going to do the same for associations/manyassociations.
For persistence, if you have existing data it will actually be fine with
the default EntityStores if you replace the interface with the fields,
since they don't store the qualified names in the JSON anyway.
Pretty neat :-)
regards, Rickard
ps. All of this stuff is still only on my local machine. Niclas, let me
know how you want to do with branching/releasing of 1.3
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
