>> 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
This archive was generated by hypermail 2.0.0 : Fri Jun 02 2006 - 11:13:31 EDT