Re: Confluence for SoC

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Mon Jun 05 2006 - 09:34:00 EDT

  • Next message: Gentry, Michael \(Contractor\): "RE: Cayenne 1.2 Release Candidate is available"

    On Jun 5, 2006, at 4:08 PM, Marcel wrote:

    > I envisage the application working upon a Cayenne Modeler XML file.
    > This will load the queries and the objects involved. When a query
    > is selected it will be run to get back the initial objects. The
    > whole graph will be shown in the application, but the instance data
    > won't be loaded for any particular object until it is selected. The
    > records returned from the query should be able to be scrolled
    > through, and the data edited and saved back to the DB. Is that what
    > you had in mind?

    I am confused about showing the "whole graph" part. Showing *all*
    object graph means showing the entire database. This is certainly NOT
    how you want to do it. So let me reiterate: You'd start with a list
    of objects fetched for a given query (i.e. a small subset of a db),
    and then expand the graph on demand as the user clicks on a
    relationships of a specific objects. Cayenne yields itself extremely
    well to this type of navigation, lazily resolving relationships
    behind the scenes (so instead of "instance data won't be loaded" you
    may say "relationship data won't be loaded").

    E.g. in response to a query a user may get a list of artists (a1,
    a2, ... an). (S)he clicks on some artist's "paintings" relationships,
    this would expand a list of paintings for this artist only, and so on.

    For version 1.1, we may also take query "prefetching" into account to
    show more than one kind of objects on the initial graph.

    > Can you point me in the right direction for Cayenne's XML file
    > parsing code please? Does Cayenne maintain an accessible (to the
    > ROP client) model of the object graph, or will I have to build one
    > based upon the XML file?

    Cayenne provides all the metadata to you, on the client as well as on
    the server. And you don't need to parse any XML.
    ObjectContext.getEntityResolver() is what you are looking for.

    > The third is to build it under a graphical editor framework such as
    > Eclipse's GEF [3]. I am tending towards the latter - it builds in
    > editing and visualisation, and I am a fan of Eclipse. There's good
    > documentation and good examples - some of which look promisingly
    > like what I had in mind for the final application [4]. Moreover it
    > can be deployed as a plugin or standalone via RCP.

    Sure. GEF/EMF looks ok (and seems to even work on Mac), although I
    don't know any of the internals of course.

    BTW, looks like a substantial part of the project will be graph
    layout - something that can be rather non-trivial [1]. I wonder if
    Eclipse tools include auto-layout algorithms (Sugiyama, etc.)? If
    this part becomes a problem, you can prototype the whole system using
    the UI similar to Apple Finder [2] (or Eclipse class browser), that
    should simplify the coding.

    [1] http://csbi.sourceforge.net/images/gal.jpg
    [2] http://dev.objectstyle.org/~andrus/browser-ui.jpg

    Andrus



    This archive was generated by hypermail 2.0.0 : Mon Jun 05 2006 - 09:34:27 EDT