————————————–
http://www.dasofte.com

I’ve now posted a new blog on Workflow.

In answer to your second original question … the idea of needing multiple visual representations of an object is not at all incompatible with the concept of Naked Objects. You can already see this in a very simple form on the current Drag and Drop user interface. If you right click on the title bar of a window displaying a view of an object, you get a ‘view menu’ which shows you generic view options such as ‘View as Form, View as List, View as Table’. The specific view options available depend upon the characteristics of the object you are looking at: whether, for example, on whether you are looking at a single object or a collection.

This principle can easily be extended to provide the option to view any collection of objects that contain dates in the form of a calendar view, or any collection of objects that contain Lattitude and Longitude coordinates on a Map viewer. Quite early on we used the latter when we built a prototype energy trading system (http://www.nakedobjects.org/book/section52.html). The NakedRCP viewer (http://sourceforge.net/projects/nakedrcp/), which is still experimental, but demonstrable, also supports this idea of plug-in viewers.

The design principle that we follow, though, is that the viewers should be as generic as possible, with minimal coupling. Thus, for your example of viewing, say, a 3-D representation of a molecular structure, you might define a (Java) interface called HasMolecularStructure, which defined a method something like:

String getStructure()

That returns a standardised string representation of molecular structure (I’m not a chemist!). Any object that implemented this interface, would, when viewed via Naked Objects, present the user with one or more alternative viewers for that object. The point is that this might be implemented not just by objects that represent molecules, but by objects that contain representations of molecules e.g. Drug.

1. It would prevent any object (other than the ‘root’) from holding a persistent reference to an @Aggregated object (i.e. one that formed part of another object). In terms of the DND UI, for example, the user would not be able to drop an @Aggregated object into a field on another object, though they would be able to drop it into a parameter on a dialog.

2. Per your idea, when the root object was destroyed, any aggregated objects would be destroyed.

We did not consider the idea that the UI could render the fields of any @Aggregated object ‘in-line’ within the root object. I agree that this would be possible, but my own experience would suggest that you’d end up with object views that were too large. Also, this would tend to make the aggregated object look less like an object i.e. that the user could invoke actions upon in its own right. I see that as pretty important.

One option would be to have a parameter within the @Aggregated object indicating that the UI should (or should not) render it in-line so to speak.

We’ll look at this again in due course. To be honest, our development agenda is pretty full at the moment, so it isn’t imminent.

BTW, since this discussion is no longer really connected to the original blog article, you might like to consider posting within the Help forum, which is a bit more active: http://sourceforge.net/forum/forum.php?forum_id=544072

Richard

regarding you HTML rant: i agree to a considerable degree – and what you are saying is one reason (the others being esthetics and simple opportunism) why everybody is going cracy about web 2.0 and rich internet applications. looking forward to that Flex UI for NO…

regarding my question 1 on the UI for master-detail relationships: to be honest, i was expecting a different answer: i was expecting you to tell me that the kind of relationship (association vs. composition) between objects of a class is a feature of the object model and hence must be captured there – it’s not really a feature of the UI. which is the reason why UML allows us to express association and composition in class diagrams. i was expecting you to tell me that NO has a @Composition annotation that turns a plain Java reference (or collection thereof) from an association (the default in the absence of that annotation) into a composition and that the reflective UI reads that annotation and displays all “detail” objects together with the “master” objects. Nothing keeps me from contributing this, i know

i tend to think that composition also influences other aspects of the domain objects: hibernate cascade settings, for instance (typically “all, delete-orphan” for a composition). and if you automatically generate an audit log of changes to your entities than the change to a “detail” object is usually also a change to it’s “master” object. these are just 2 other aspects of the system (in addition to the UI) that could benefit by a distinction between association and composition in the domain model.

kind regards,
gerald

Interesting points. I’ll answer the first one here. The other two require more detailed answers, so I’ll use them as the prompt for another blog – possibly later on today.

So on the first point, my response is that on the default Naked Objects user interface (the ‘drag and drop’ UI) when you open a view of an object you can see its component objects (i.e. referenced in its properties). All you see initially is the icon and title for each. So if the state of a component object is likely to be seen as of direct interest to the viewer of the parent object, then the component object’s title should reflect that state. The user always has the option of then opening up a separate view of the component object if they need more detail. Again, on the drag and drop UI, double clicking will open up that view as a separate window.

Of course the latter works much less well on the pure HTML UI, because that only has a single window. Which leads me to another rant The growth of HTML user interfaces, even for internally-accessed systems has done enormous damage to our understanding of systems design. HTML is fine for systems to be used by the public, which must be very tightly scripted and aesthetically pleasing. (These are what Alan Cooper called ‘transient systems’). But it is totally unsuited for what he called ’sovereign systems’ which is what Naked Objects is designed for.

Richard

I would be interested to learn your view on 3 related issues (which must be very common questions, i suppose):
1. when visualising the state of a “master” object one sometimes needs to include the state of related “detail” objects (because it is a composition-type relationship and viewing the “master” object alone would be incomplete or inefficient). and in other cases this is not at all the case. how do you distinguish these cases without having views that can be fine-tuned?
2. what if a class has several valid visual representations (such as a Molecule containing Atoms) that are appropriate depending on context: sometimes i want to see the ball-and-stick drawing of the Molecule and all its Atoms; sometimes only the “heavy” Atoms; sometimes i want to manipulate the numbers (the object’s properties) directly…
3. and finally the issue of wizards/workflow/business process: a wizard is a pure GUI concept, with no equivalent in the domain model; a business process/workflow has elements of business logic (orchestrating other (”service”) objects) but it also has an element of user interaction, namely the notion of a “work item” and the “next thing to do” for the user. and a workflow may also restrict what a user may do at a particular point in the process (suggesting that not all of an object’s state is accessible at all times).

kind regards,
gerald

Since the viewer is Eclipse based, new views of objects can be written by implementing the appropriate extension point. To prove the concept I’ve already done simple spikes of a calendar and a google maps mashup.

You can see screenshots of the generic viewer (without the extensions) at http://sourceforge.net/project/screenshots.php?group_id=167340 and download the code at http://sourceforge.net/svn/?group_id=167340 .

Dan