I use about the same architecture (rest/dci) and I'm using gwt for the webui so I don't have to write a single javascript line, everything is java. [1]
I'm quite happy with this and I'm looking forward reading more on the "custom library that interprets the contexts+interactions and generates the REST API". Sounds good to me as it's the only place where I still have plumbing code. So, +1 for promoting such code to qi4j-whatever ! BTW I think SpringRoo + GWT goes the static webui + rest way. Never tried it, only read some posts about it. Paul [1] Have you seen this ? :) http://jz10.java.no/java-4-ever-trailer.html Le mercredi 30 juin 2010 13:06:42, Rickard Öberg a écrit : > 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
