Hi, Dan. As I explained on previous emails, we have a "custom viewer" made over Wavemaker technology [1], that we have adapted to Apache Isis (close source, but if anybody is interested on creating an open one, we would share the specific code needed). That allows our users to have a development studio on the web for customizing the User Interface, etc.
The point is that we looked at a given moment at the Wicket viewer code for determining how the Isis session and transaction management was done (it's stateful), but we are experiencing some problems and needs to be rebuilt. We've also see that a recent commit has been made for the session management on the Restful Objects viewer, which is stateless. I'm sure there are going to be more people interested on knowing how to integrate an Apache Isis domain with their own web applications based on Java (directly, not through the Restful Objects API as been made with the Javascript or Android viewers). All our interaction with the Apache Isis domain entities is made: - through a "custom-made" IsisDomainRepository, which contains "generic" finders (by tenant, etc.). - through a "custom-made" infrastructure layer that interacts with Apache Isis ObjectAdapters, etc. for invoking actions. So, at first, we are capable of working with the domain without a reference to the user's context (stateless). So, prior to advance in one direction or another, we have some questions about current design: 1.- Stateful (Wicket) vs Stateless (RestFul Objects): why the Wicket viewer needs to hold the state, from an Apache Isis perspective? Just to hold the current user "context information"? Why to choose for other webapps integrating with Isis the stateful design, instead of the - more scalable - stateless design? 2.- Is there any class we can inherit from for stateless or stateful clients, that will be maintained in the future, as Apache Isis evolve, that takes care of web session handling, security (shiro) session, transaction management, etc. ? Perhaps we can inherit from classes currently existing on the Wicket viewer (or the Restful Objects viewer). 3.- Is there any other point we must take into account with this approach - the "custom viewer" interacting with the Apache Isis domain - ? Thanks, Oscar [1] http://www.wavemaker.com
