Hi Dan,
Thanks for the kind words. Good to see the idea aligns well with the
project goals.
> * I see an isRequired() flag, but this doesn't seem to be
> extensible.
Can you give examples on what kind of extensibility is required? My intent
with proposed API is that the data backing the schema metadata objects is
produced wholesale, as a snapshot. It is really just a bunch of data
objects with no smarts, which don't change (the schema of the application
is fixed anyways). The code that produces the schema (an implementation of
SchemaManagement) decides how to mark a property as required and is
framework/implementation specific, so one can make it as smart as required
in the context of the implementation at-hand.
> * Related, I see an isEditable() method. Isis in contrast has three
> levels of checking: visibility, editabilty and then validation ("see it,
> use it, do it").
In Cloudfier (which is UML based) there is support for private
(non-visible) attributes as well, but since those are not visible from an
external viewpoint, they don't need to be exposed in the API whatsoever.
Does that make sense?
> In fact, this overlaps with the facets, that can optionally implement
HidingInteractionAdvisor,
> DisablingInteractionAdvisor and ValidatingInteractionAdvisor. So without
support for this in
> the API, none of Isis' behaviour here could be surfaced.
Right, I agree there is a gap to be bridged there. Are those features
schema-driven only, or an they take the state of the business object at
hand as well (then would be more of an instance management thing)?
> * in the API I see some methods (master/child table, [3]) that suggest a
very particular UI is in mind. Not sure about that.
Good point, they were from a previous project, I just deleted them. The
current viewer I have decides those things on its own, based on other more
neutral metadata already available in the API.
> And from a style viewpoint * equals/hashCode for an abstract class; not
sure
> Josh Bloch would condone that...
Hehe.... that's because the schema's object model has a bit of a hierarchy,
and I wanted to reuse the hashCode/equals logic from superclasses in the
subclasses. But I am not wed to the approach.
> * would it not make sense to make everything immutable? Isis' metamodel
isn't, and it pains me.
For practical/conventional purposes, they are immutable. A builder creates
and initializes them, everybody else just reads them. The setters make it
easier to write schema builders without requiring subclasses, or interfaces
or constructors etc. I love low tech APIs, and strove to have as little
abstractions as possible. I was even tempted to have just a bunch of public
fields, but that would make it hard to do things such as proxying, lazy
initialization, etc which seems something people may want to be able to do
(and I actually needed in the past).
> In terms of implementing this in Isis; well it's nowhere near the top of
my priority list
> (RO and the next-gen viewer are priorities).
I think having a RO-based viewer would be great. I could then just build RO
compatibility into Cloudfier (right now it has its own API style [1]). And
would help identify/isolate a simpler view from the Isis metamodel, which
would help with the kirra-api effort.
> But I'd be very happy to support you if you wanted to build an Isis
> implementation yourself. Perhaps others might be interested in helping.
I will be attending an upcoming hackathon on a local Google Developers user
group [2] this weekend and am planning to build an Android client (a.k.a.
viewer) that uses only the Kirra API at runtime to produce a generic UI for
Cloudfier apps (so far I have been using code generation). Let me see how
far I can go with that, and once that is running (at least in prototype
form), let's look into how the same can be achieved against an Isis-backed
implementation. I would love to have help from people in this group with
that.
> By the way, if you can get to Milan for our mini-conf in a few weeks
time,
> would be great to see you. (Offer open to all).
Thanks. That sounds awesome, were I in Europe (or had the budget to travel
there from Brazil) I would be really tempted to attend.
[1] http://doc.cloudfier.com/api/
[2]
http://codigo-google.blogspot.com/2014/04/hackathon-gdg-floripa-evento-inaugural.html
Cheers,
Rafael
