On 2010-06-29 15.08, Marc Grue wrote:
I agree!! +1
I couldn't find source code for the Wicket Objects project - is it
closed source, or does someone know where to find the source code? It
could serve as architectural inspiration for doing our own Wicket Qi4j
project...
Is there any chance that the Command-Query/Event-sourcing implementation
found in Streamflow could be used in a way that would eliminate the
serialization problems with Wicket integration that Niclas mentioned
earlier?
I think it would be awesome to have a Qi4j-Wicket framework using DCI,
CQS and Event Sourcing (or even better if those buzz concepts could make
their way into the Qi4j ext/lib so that they could be used in any
framework build on top of Qi4j).
Alright, so I've been doing a lot of thinking and experimentation with
this in Streamflow, and my conclusions are as follows.
For web UI I have finally succumbed to AJAX (I was against it for a long
time due to browser inconsistencies and government regulations, as I did
a lot of work with them), and what we are doing in Streamflow now is
pretty awesome as a development model (IMHO).
Basically, we develop the domain model using Qi4j/mixins. The Data in
DCI. Then we create roles and contexts in the application layer, which
adds state-less role mixins to the entities. These roles can be added to
the core entity for ease-of-use, or you can create sub-entities for
cleanliness. I.e. for a particular entity you will have one declaration
in the domain layer with just Data mixins, and then the application
layer extend it and add the roles you need for the interactions. This
largely replaces the "stateless session facades" in traditional EJB designs.
The interactions and contexts are then exposed more or less directly as
the REST API. One context = one path segment in the URL. One interaction
= one "document" in the URL. Example: /context/interaction (or
/context/interaction.html for content type specific URL's). This has
TONS of advantages, mainly because the interactions do NOT have to look
up the objects it needs to use, instead it asks the context for it.
Usually a lot of the web code will be "take the id for the URL and look
up the object" which now disappears into one single place (the context
creation). All the validation of that id, security checks and so on, is
removed from your core application logic.
With this, you have a solid REST API but which is not your web UI.
What you then do is to create your actual application using one HTML
document with named divs, one CSS stylesheet with the look&feel, and one
JavaScript file with all the logic. The JS (using e.g. jQuery) will load
the data from the REST API, get the HTML snippet for a particular
view/component from the HTML file, and then merge them together and
insert into the DOM. Interacting with the browser will trigger JS events
that "does stuff", like invoke commands or load new data+HTML.
Basically, it "feels" like a thick client, but it's all loaded on
demand. Since the HTML+CSS+JS are three static files they can be heavily
cached (infinitely if you go hardcore and use version nr's in the file
names).
We have been trying this style out in Streamflow for our web UI, and it
really rocks so far.
For the web UI itself you don't need much apart from jQuery and some
templating utilities (merge templated HTML and JSON data from the REST
API). The HTML+CSS you can do with a text editor. For the REST API we
have a custom library that interprets the contexts+interactions and
generates the REST API.
It's all available in Streamflow source already, and now that it seems
reasonably stable we could simply promote it to either qi4j-sandbox or
directly to qi4j-libraries, to make it generally available.
This, I think, is the Really Cool Way to get the most out of it. If you
want to do event sourcing on top, you can, but it's not dependent on it.
Does that sound reasonable? Does anyone know of other frameworks going
this way? (static HTML/CSS/JS + framework for REST API)
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
