Hi,
Thanks for the support. Just to clarify, the generated UIs you saw in that
post were still server-side generated, from UML models (Cloudfier apps are
UML models).
I am reimplementing the mobile UI to be client-side "generated" based
exclusively on metadata that is available on the REST API (h
Hi all,
Just an update on this thread - I have been making some progress on
building Kirra as a platform-independent API for accessing domain objects
and services of a business application.
What has been done so far:
- progress on a REST API incarnation of the Kirra API using JAX-RS [1]
- progres
Hey,
On Wed, May 21, 2014 at 1:41 AM, Dan Haywood
wrote:
> > From what I read here, it seems that my goals with Kirra are more related
> > to RO than to Isis per se (as Isis design assumes client and provider are
> > in the same process and there is no latency), although I could still see
> it
>
Hi all,
> a property/field (or action/operation parameter) being required is just
> one sort of validation. Others include @Regex, @MinLength, @MaxLength etc.
Ah, got it. As I said before, I am aiming for a more
disconnected/snapshot-based approach (which is more friendly to a high
latency protoc
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 m
I'd like to see a lightweight generic technology-agnostic API that gave
access to the functionality of domain-driven applications.
Generic, because it would provide generic abstractions for doing CRUD and
invoking actions and queries, based on sufficient schema metadata.
Technology-agnostic becau
d to stand corrected, but it doesn't strike me as a particularly
> common use case. Maven, of course, builds the classpath by referring
> directory to the jars in the local ~/.m2 repo.
>
> Dan
>
>
> On 30 November 2012 16:23, Rafael Chaves wrote:
>
> > Dan,
>
and an artifactId also of
> com.verybigcorp.foo.bar. We decided that whoever chose that artifactId
> hadn't understood that the identity of the artifact is the combination of
> the both (plus version, plus classifier), and had chosen artifactIds based
> on its use as the JAR name.
>
> Dan
&g
The artifact id ends up by default being the jar name, right? If that is
true, I'd go with an artifact name with a common prefix across
all Isis artifacts (i.e. isis-dflt). Two benefits: people using Isis have
an easy way of identifying the Isis jars among all the other Jars their
application uses,
