On 13 May 2014 16:15, Rafael Chaves <[email protected]> wrote:
> Hi Dan,
>
> Thanks for the kind words. Good to see the idea aligns well with the
> project goals.
>
>
apols for the reply here...
> > * I see an isRequired() flag, but this doesn't seem to be
> > extensible.
>
> Can you give examples on what kind of extensibility is required?
a property/field (or action/operation parameter) being required is just one
sort of validation. Others include @Regex, @MinLength, @MaxLength etc.
In fact, Isis has a @MustSatisfy(SomeSpecification.class), where
SomeSpecification is an implementation of Specification that can perform
arbitrary validation.
As I say, I think the extension object pattern is a good design for this
[3]. In Isis, the FacetType is used as the key to accessing the facet.
These facets/extensions are all ValidatingInteractionAdvisors.
> 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.
>
>
In Isis, the pattern is for these validations to return a string rather
than a boolean. The string is the reason why the value is invalid. This
is more flexible than returning a boolean, I think.
> > * 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 Isis visibility is computed dynamically. It might vary based upon the
state of the object (eg hide the "complete" action for a todo item that is
already complete), or it might vary based on the user's permissions.
As I mentioned, we have both visibility and disability.... So permissions
are implemented as just another sort of HidingInteractionAdvisor and
DisablingInteractionAdvisor.
>
> > 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)?
>
>
Both. For example, in our example ToDo quickstart app (as generated by the
quickstart archetype [4]) the ToDoItem#ownedBy property is always hidden:
@Hidden
public String getOwnedBy() { ... }
On the other hand, the disability of the "completed" action is computed for
the instance based on a supporting method (we use naming convention to
match):
public ToDoItem completed() { ... }
public String disableCompleted() {
return isComplete() ? "Already completed" : null;
}
>
>
> > 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.
>
>
That'd be great.
> > 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.
>
>
How did you get on?
> > 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.
>
>
So, some other time, I'm sure.
Cheers
Dan
> [1] http://doc.cloudfier.com/api/
> [2]
>
> http://codigo-google.blogspot.com/2014/04/hackathon-gdg-floripa-evento-inaugural.html
>
> Cheers,
>
> Rafael
>
[3]
http://www.mif.vu.lt/~plukas/resources/Extension%20Objects/ExtensionObjectsPattern%20Gamma96.pdf
[4] http://isis.apache.org/intro/getting-started/quickstart-archetype.html
