Get naked everyone!
beders
Eitan just pointed me to this new effort of a model driven,
fast-prototyping, behavioural-complete application framework. Now I
know where Eitan has been hiding all the time ;)
First let me introduce myself: My name is Jochen Bedersdorfer, I'm
working at Xtramind Technologies on communication managemement
applications and in my spare time I developed the first swing based
viewing mechanism for the original nakedobjects framework (a looong
time ago, it seems. The code is still up there at
http://sourceforge.net/projects/nom-swinggui)
So I'm pretty well aware of how hard it is to create a well-functioning
and good looking viewing mechanism from presentation metadata, let
alone a full framework. Well: It is hard ;)
I just got my feet wet with jMatter and wanted to discuss some
observations of mine.
First of all: Congrats to this massive effort! I'm looking forward to
convert my old NO prototypes
to JMatter. It seems JMatter is a step in the right direction and
hopefully many wonderful applications will arise from this.
Concerning annotations:
Pretty please, yes.
I'm fine with expressing model constraints using naming conventions,
but these could also
benefit from using annotations.
Anway, I'd like to see all presentation-specific metadata as
annotations.
(fieldOrder, for example, is clearly a presentation-specific metadatum)
Also, it should be possible to configure this metadata without
recompiling.
(We have customers, for example, who complain about the order of
buttons in toolbars. )
Of course, care must be taken that configuration of presentation
metadata is not jeopardizing the business model logic.
Section 5.6 (of your documentation, which is a REALLY nice
documentation, btw!)
static { TimeEO.setFormat("m:ss"); } // is an example for a
presentation specific metadatum.
How about:
@presentAsDate("m:ss")
private final TimeEO _duration = new TimeEO(); // or maybe specify the
annotation at the accessor
Using an annotation also leaves room for proper i18n of the date
format.
Something like firePropertyChange is needed for sure, but I still don't
like to specify the
"property" using strings.
Maybe objectChanged(); (a la NO) could be enough.
Let the view figure out what part needs to be updated.
If objectChanged() would be enough, we could do away with this line and
use @changesState for the method.
If we assume that most methods will change the state of an object.
@noStateChange on the method level could be an optimization. (State
here is defined as the set of values of all attributes)
Concerning State-specific behaviour:
The current solution seems a little bit too complicated.
Here's an alternative take.
interface Stateful {
String getState();
}
Let all classes that want to restrict usage of their interface in
certain states implement Stateful.
Then you could use something like this:
@Command
@activeInState("accepted")
public void Fix(CommandInfo cmdInfo,
@Param("Fix") StringEO fix,
@Param("Description") TextEO description)
The annotation @activeInState then refers to the string returned on
getState.
(Note that I removed the At-Suffix for the known annotations.
@ParamAt sounds like AtParamAt, which contains too much redundancy for
my taste :)
The solution above also avoids implementing non-static inner classes.
I'm not really in favor of the State pattern using static inner
classes.
If your class needs this kind of mechanism, it is time to revisit the
design IMHO ;)
Section 7.5.3
This is where I realized that you have explicit ready & edit states.
I propose to get rid of these states, because they really are a
presentational issue.
The edit state is only in effect for value-like objects, it seems. For
example I can happily drop
a Role instance on the role slot of User without having to press "Edit"
first.
Still, from the user's point of view, I changed the object indeed.
Also, an edit, save, cancel cycle is not a natural metaphor IMHO.
In the words of Yoda: "Do, or do not. There is no try." Of course, this
implies having an undo capability.
I'd prefer "click-to-edit" for each editable field.
Clicking on an editable field gives you an input cursor or a way to
edit the field.
If you get rid of these states, the code in Section 7.5.3 for the
association will look like this:
public void associateAssignedTo(User user) {
setAssignedTo(user);
transition(ASSIGNED, makeLog("Assigned to " + assignedTo);
}
Concerning the initial edit state:
If an object is created, its created. It may be in a transient state
until it is valid and can't
be associated with persistent object if the state is invalid.
Creation thus happens with the default ctor and implementations must
make sure this leads to
a valid state wrt the object functioning in the application.
In an extreme form, we could express this as: Any state for an object
is valid, as long as you
limit the available methods accordingly. (Associating this object with
another one is also considered a method here)
Section 7.6
Instead of having to deal with the query to return the PagedList,
I'd prefer this:
private final InverseRelation _notes = new InverseRelation(Issue.class,
"category");
public PagedList getNotes() {
}
this lets you switch between storing references directly in a list
(only workable for smaller collections)and having an implicit
collection using foreign keys, loading only those objects needed,
without having to touch other code and is much shorter.
I should not be bothered with queries for this common relationship.
(I think this has already been discussed on the mailing list to a
certain extent)
Thanks for reading this far :)
JMatter is really cool, I'm impressed.
If there is an official way to contribute, we could make it even cooler
:=)
Cheers,
Jochen
eitan
wow, you come up to speed quickly. thanks for the detailed feedback.
i think you're ready to start coding. :-)
here are some thoughts:
[a] on annotations: i think @Command and @Param is a better naming
choice compared to the current @CommandAt and @ParamAt. indeed,
i believe all metadata should move to be specified this way.
[b] letting users control the metadata: i started out with a
metamodel
that wasn't naked and then retrofitted it to be naked. that's why
you
can actually view type, command, and field information in the gui.
with a little more work, what i want to do is make this metamodel
more
completely naked, from the point of view that you'll be able to edit
the metamodel directly from the ui and specify things like:
Field: name (read-only)
mnemonic (editable)
caption (editable)
required (editable)
default (editable)
likewise for type:
name (read-only) (e.g. Person)
fieldorder (editable)
default search field (e.g. first name)
etc..
so that the defaults for the meta info is specified in the
code using annotations, but it becomes just a bootstrap thing.
then, layering authorization on top of it all would prohibit
a typical users from wrecking havoc (i.e. change rules that
should be immutable: e.g. can't get around "field x is required")
[c] regarding the read-edit finite state machine, i wanted a more
"conservative" gui, something that was more like what people are
used to. i think it's important to support fsm's and it's nice
that jmatter
does. however, i too am not completely satisfied with the
implementation as it
stands. the specification could be made much simpler, and cleaner.
the good
thing is that it works, it's not a work in progress. personally, i
like the
inner class business. it's akin to the state pattern and i like the
state pattern. :-)
however, i equally like your suggestion of @activeInState. after i
actually
try it, i might grow to prefer it.
the
@presentAsDate("m:ss")
example you give is perfect. it can be a pplied in a number of
circumstances.
..about contributing..i started setting up trac. i'm not all the way
there
yet and it probably won't be until next week that svn and trac will be
up
and running.
you don't have to wait until then. if you do some work to improve
things,
i'll gladly review it, test it, and integrate enhancements.
thanks, eitan
eitan
issues, maybe we can switch to the jmatter-dev mailing list
(also on google groups).
/ eitan