I am taking a look at Eclipse RAP right now... http://www.eclipse.org/rap/getting-started/ "Single Sourcing" Eclipse RCP + AJAX.
Phil On Wed, Jun 30, 2010 at 1:06 PM, Rickard Öberg <[email protected]>wrote: > 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 >
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
