Hi Stephen, Thanks for sharing this analysis. Per REST, NetKernel is one of those technologies that I keep meaning to look at. I have no informatino on it other than I met the main guy at a conference a few years back and he seemed like a pretty smart fellow.
Also on the topic of REST, there is of course Isis' implementation of Restful Objects. I suspect this has very little overlap with REST as implemented by NetKernel, but I believe that it's a natural extension of the original naked objects pattern (as does Richard Pawson, I think). Anyway, glad to have you on the list Cheers Dan On 21 May 2013 02:57, Stephen Cameron <[email protected]> wrote: > 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 > > > > > > > > > >
