Another possibility is to provide a powerful viewing perspective on a
web app such as Confluence - for example, a navigator that can
provide a view(s) of the wiki unachievable via the Web. What those
views might be is an open question, but one idea is Craig's node
navigator, similar to the CNET news map ('The Big Picture') [1].
Editing could be introduced using Confluence's RPC interface (the
nice way to edit pages ;) ), but that could take a little bit of time
(ie I'm not sure how that will go with the Aug 21 deadline - not
saying it can't be done, just that there is doubt). Alternatively it
could load editing pages in a browser (internal or external). That
would emphasise the other advantage of ROP, as a way to supplement a
Web interface.
Doing updates via Confluence kind of goes against the goal of
demonstrating Cayenne graph management capabilities.
True. We could allow separate view annotations to be made in tables of
our own? A kind of behind-the-scenes annotation.
How about a program which displays a graph of the objects that
Cayenne has mapped, and browsing and editing of values? I guess that
could be done with regular Cayenne, but given that Cayenne's ROP is
easy to deploy (just add an ant task to build the classes into a WAR
and then deploy it to Tomcat) it might be a useful tool for
developers using Cayenne in web applications. After mapping the
database, a Cayenne developer would then be able to browse the
objects and their contents, and edit the database at an object level.
It seems achievable, unless I'm missing a major complexity issue, and
it is Cayenne focused. It would seem to be a useful tool on its own,
and at some point it could be incorporated into CM if it moved to
RCP. ROP functionality could be switched on and off without
difficulty, it is simply a matter of getting the context from a
different source. To me, that is the greatest advantage of Cayenne
ROP - a third tier can be introduced almost completely transparently
from the client's perspective. This kind of application would
emphasise that.
Correct about ROP transparency to the client app (as long as the code
is using ObjectContext interface without casting to DataContext or
CayenneContext). Still I don't see why would a developer ever bother
deploying a web service in these circumstances. In fact as a developer
I would rather use the ROP transparency advantage to do the opposite -
go to the DB directly when developing an ROP app, just to avoid the
hassle.
Agreed. The only situation of necessity I can think of is where database
access is strictly controlled for one reason or another. For example,
developing on a database behind a firewall or developing on a database
which only accepts localhost connections for security reasons.
Still I like the generic graph viewer/editor idea. With frameworks
like Piccolo you can really visualize your objects and their
relationships, providing usability that regular table/form UI can't.
So maybe we do the same app that you suggested, but "position" it
differently (I can't believe I am using marketing speak :-)). Not as a
development tool, but as a framework for building a multi-user visual
graph manager based on Cayenne model. It can have functionality
similar to this
Visual Graph Manager:
* A generic GUI application that connects to Cayenne web service
* A panel to select a mapped named query from the list and run it
against the server
* A panel to display a graph of objects that expands when
relationships are clicked.
* An ability to select a node on the graph, and edit its properties
(we can omit relationship editing in version 1.0)
* An ability to save the whole thing to the server
* Change notifications - propagate the changes made to objects in one
client to other clients viewing the same graph (this is the cool thing
about ROP - it does that for you automatically with XMPP)
* A sample Cayenne model that demonstrates the above capabilities
Your original criticism still remains unresolved: I don't see why would
a developer ever bother deploying a web service in these circumstances.
The only distinctly ROP element here is the XMPP notification, and that
is only relevant where the tool is going to be employed multi-user, and
the same mechanism could be achieved in other ways. Don't get me wrong,
I like the idea, but as you asked above: what makes it cayenne-rop
rather than cayenne?
However note that Piccolo doesn't work well with SWT (it "kind of
works"), so the client has to be Swing. IIRC Eclipse has its own graph
toolkits, although I know nothing about them and won't be able to help
if there are problems. Are you comfortable doing this with Swing (in
fact there won't be too much Swing as Piccolo does the rendering)?
I'm not as familiar with Swing as SWT, but as you point out the bulk of
the work would be in Piccolo (which I'm not familiar with either :P).
Not daunted by that however. Terrified would be the word. Fear is a good
motivator.
General comments?
Andrus
Here's the picture I've been left with of where ROP would actually be
employed in the Real World (TM). A servlet-powered web application needs
a more powerful tool for some aspects of its operation - most likely
administration or visualisation (say via Web Start). If you aren't
dealing with a web application in the first place, there is no reason to
use cayenne-rop over cayenne.
If it weren't for the way that Confluence works - as a complete system,
wrapping the database rather than separable from it - it would be a
perfect target: administration and visualisation are both relevant.
Given this discussion, I'm almost in favour of going back to Confluence
and writing an RPC plugin to force page refreshes. It isn't nice - I'm
sure the Atlassian folks would be bemused at the avoidance of their
carefully constructed RPC interface - but Confluence provides a much
better target for ROP than I originally appreciated; not ideal (ideal
would be for Confluence to be built as one window on the database, not
_the_ window) but quite good.
First thing I'll do is post to the Atlassian forums and ask if anyone
has any bright ideas in case I've overlooked something regarding
Confluence's refreshes. Then I'll sleep on it. There is time this week
for this discussion to continue (I have to study for an exam over the
weekend), but in a few days a decision will have to be made. If push
comes to shove, Andrus I'll ask you to simply make a decision one way or
the other so that I can get on with it, whatever it may be.
I should say that I appreciate the preparedness to toss ideas around -
both refreshing and empowering.
Regards,
Marcel
