Hi Jeroen, Thanks very much for sharing your experience.
I too have come to a conclusion that 'coding in XML' is not that sensible a thing to do. In fact I have a general feeling that is a big part of the problem of XForms uptake. I now see XML as a very flexible resource representation means and that you should make use of tools that use XML as a means of persisting state. I've have built a few demo UIs using XSLTForms to explore this. A simple <http://www.collinta.com.au/xsltforms/designer_simple.xml> and more complex <http://www.collinta.com.au/xsltforms/designer.xml>(unfinished) schema design and XForm generation tools. An XML editor <http://www.collinta.com.au/xsltforms/xml.edit.xml> tool. This change of perspective came about through working on the complex schema design tool, and reading more about REST and also the 'Resource Oriented Computing' (ROC) "paradigm" of NetKernel <http://www.1060research.com/>. I came across Naked Objects and Isis not through frustration with XML but with UML (more specifically MDA). TheMDA design by modelling approach always seemed attractive but not that widely used. I always thought this was due to the problems of keeping a model and code in sync and the expense of tools that could do 'round-trip' synchronisation automatically. I've now changed my ideas about that as well, and am very keen to try the Naked Objects 'behaviourally complete' objects approach (for prototyping at the least). So, the thing that is very interesting to me now is to define the "sweetspot" of XRX more clearly, with both this new view of XML and also, I agree, with the view that where system behaviour is the issue, OO coding is much better (and perhaps Naked Objects is the best!:)). My work for the past few years has mainly been data management systems for science. I see XRX as having great promise in this arena, for building RESTful systems very cost effectively, and potentially letting the users do most of it via declarative system configuration. Here we are mainly interested in data modelling, data entry UIs, data validation (types and constraints) and to add meta-data easily and consistently. XML and XRX provides all this well I think. In contrast, in another area of science, system modelling, there is a need to add complex behaviour to the picture, with data as an input. This I think is the origins of OO via Simula language, that was the model for C++. As you say, if adding "complex business rules" this 'behavioural' aspect is the main thing to build and XQuery isn't very suitable. Yet there is a declarative approach to this as well via rules-engines and business-process design tools, that potentially could be used in an non-OO XML based system. That, (I think) is the basis of the (ROC) approach of "construct, compose, constrain", (see the nCode tool for example). As explained in the original Naked Objects book, alot of OO code that is written is does not take advantage of the key features of OO languages. This seems particularly relevant to me now as I want to take a "the code is the design" point of view and do my system modelling in code (possibly creating UML diagrams as a documentation artifact at the end) and adopt domain driven design. The picture that is forming for me is that there are two main types of systems that we might want to build, but that these are two poles of a continuum. These are 'behavioural' systems and 'actional' systems in my terminology, OO seems best for the former and XRX a good option for the later. An actional system is usually going to be framework based and have functionality (actions) that are triggered by events. XForms is a good example, there is an engine (the framework) that binds the model to the view and which triggers actions in response to data events (e.g. to apply constraints defined in binds) and to UI events (e.g the xf:toggle action). Naked object is somewhat similar I see but the viewer frameworks are actually a proxy for the objects, to their properties and methods). Other examples of actional systems are XML pipelines (where the events are SAX events usually) and REST systems where a URL is bound to a procedure, rather than to a static resource or to an object method. One such example the 'active' scheme in NetKernel. So, my interest is to better understand this contrast and the trade-offs in choosing one approach or the other. [Code is generated all the time from schemas via various approaches, what is different for Isis that would make this impossible, up to a CRUD level at least]. I'm not sure that further discussion of this is suitable for the Isis users list but I'm happy to hear views. Thanks again for your interest. On Mon, May 20, 2013 at 9:35 PM, Jeroen van der Wal <[email protected]>wrote: > Hi Steve, > > A few years back I developed an XRX application using eXistDB as a backend > and betterFORM as a frontend. That worked pretty well up to a CRUD level > but when we had to enrich the domain and add complex business rules the > architecture flawed. This is why I moved (back) to Java and more > specifically Apache Isis. > > IMHO there is no such thing as a no-code solution. Expressing your logic in > XML is also coding and I would never do that in XML again, too much pain. > However XRX can be the right architecture when your application is in it's > sweetspot. > > As Dan mentioned you can make Isis work with an XML store but I can't see > how you can generate Isis code from an XML schema without writing a parser > to do that. > > If you provide more details about your application I'm happy to provide > more guidance. > > Regards, > Jeroen > > > > > > On Mon, May 20, 2013 at 11:58 AM, Dan Haywood > <[email protected]>wrote: > > > Hi Steve, > > Thanks for your interest in Apache Isis. > > > > This is definitely do-able, and is not actually that far removed from one > > of Isis' original goals, to have pluggable support for its components. > > > > In fact, there is an Isis XML objectstore - though not yet formally > > released - which you could use as a starting point. It works by saving > > separate files in a folder, but I imagine it'd be easy to fork it and > write > > it so that it stores all the files in a single big XML file. > > > > As an alternative (and, actually, one I'd recommend instead), you could > use > > the JDO/DataNucleus objectstore, but then exploit DataNucleus's own > > pluggable DataStore API. > > > > There are a number of implementations; not just RDBMS, as you can see > here > > [1]. And there is one that persists to XML [2], so you could explore > that. > > > > I don't know how many people are actually using this DataNucleus API, but > > it is at least implemented and supported, so probably is a lower risk > > approach than rolling your own based on the Isis API. > > > > Let us know which approach you decide to take; happy to support you if > > possible. > > > > Cheers > > Dan > > > > PS: this enquiry probably lives better on the [email protected] list. > > > > [1] http://www.datanucleus.org/extensions/store_manager.html > > [2] http://www.datanucleus.org/products/datanucleus/datastores/xml.html > > > > > > > > On 20 May 2013 05:40, Stephen Cameron <[email protected]> > wrote: > > > > > Hi > > > > > > I am starting a project looking at how best to auto-generate a simple > > data > > > gathering application. > > > > > > I'd like to drive it off an XML Schema document, I've made something > > > reasonably good for a web interface using XForms and soon an XML > database > > > as a back-end, the so-called 'XRX architecture'. > > > > > > I've been reading the Naked Objects books and am interested to see > what I > > > can do in a similar way with Apache ISIS, both for the ISIS web and > > native > > > Java viewers. > > > > > > One question I have is: can I make use of an XML database as the > > > persistence layer easily? The idea here being that the application > > > generates one big XML file, or an archive with multiple files, at the > end > > > of a period, and that gets submitted to a central XML database. > > > > > > I guess that the history of ISIS would suggest that this is a strange > > thing > > > to do, as opposed to using a relational database. However, the method > in > > my > > > madness is that I'm effectively building a no-code solution, asI'm > hoping > > > all the ISIS java code can be generated. > > > > > > Thanks for your feedback > > > > > > Regards > > > Steve Cameron > > > > > >
