oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

Sergio,

Apologies,

I missed this before.  Likely due to moving in etc. and thinking it was
part of the Glade discussion.....anyway.

This seems to be a pretty serious limitation of 
http://jdoinstruments.sourceforge.net/help/userguide.htm 

"5. Collections of SCO objects are not supported: For example collection
of String, collection of Long, etc. are not supported,..."
 
If you cannot store mixed collections then you cannot store a single
archetype much less an entire contribution.  Maybe I'm misunderstanding
something?

Also, what would be the plan for object publication over the web?

Your points about MyOODB http://www.myoodb.org/documentation.html are
well taken.  However, Thomas Hazel is no lightweight;
http://www.linkedin.com/in/thomashazel and this is how open source
works.  Some starts a project.  Other people get interested in using it
and chip in to help out.  So we build on what he has developed and maybe
add to it a bit here and there molding it to our own needs along the
way.  At least it is a complete framework. 

--Tim


On Sat, 2009-11-21 at 19:41 -0200, Sergio Freire wrote:
> MyOODB seems to be a one-guy project for small applications. No
> documentation yet, it is kind of learning by examples and/or reading
> the source code. 
> It seems to me that dbfo (another java oodb) seems more reliable. It
> has a company behind it, has some documentation and it seems that I
> don't need to modify my classes in order to use it. Although it is not
> embedded in an application server like zodb, it doesn´t seem hard to
> use. I will start experimenting with it.
> 
> Sergio
> 
> On Tue, Nov 17, 2009 at 7:19 AM, Tim Cook
> <timothywayne.cook@xxxxxxxxx> wrote:
>         Hi All,
>         
>         I wanted to share the very encouraging response I received
>         from the
>         Glade list.  Sergio, I hope your investigation of MyOODB is
>         going as
>         well.
>         
>         Cheers,
>         Tim
>         
>         
>         -------- Forwarded Message --------
>         From: Tristan Van Berkom <tristan.van.berkom@xxxxxxxxx>
>         Reply-to: tristan.van.berkom@xxxxxxxxx
>         To: timothywayne.cook@xxxxxxxxx
>         Cc: Glade Users <glade-users@xxxxxxxxxxxxxxxx>
>         Subject: Re: [Glade-users] Abusing Glade? :-)
>         Date: Tue, 17 Nov 2009 00:22:23 -0200
>         
>         On Mon, Nov 16, 2009 at 12:53 PM, Tim Cook
>         <timothywayne.cook@xxxxxxxxx> wrote:
>         > Hi All,
>         >
>         > For those that may have built their own widgets and added
>         them to Glade
>         > I'd like to ask a question.
>         >
>         > I want to use the Glade machinery to allow users to build
>         what I call
>         > constraint definitions against a well defined reference
>         model.  There
>         > will only be about 30 or so widgets and most of them are
>         simply
>         > adaptations of existing widgets.  Containers, trees, lists,
>         text boxes,
>         > etc. but of course all the properties/constraints are
>         different
>         > (actually simpler than in Glade).
>         >
>         > So I would like to hide/remove the existing Glade widgets
>         and leave only
>         > my two libraries visible.  Then in the XML I will write the
>         names of the
>         > classes from the reference model as well as modify all the
>         property
>         > settings according to each class as needed.
>         >
>         > So why do this?  Well, it gives me a great starting point
>         for people
>         > without knowledge of a complex system to be able to put
>         components
>         > together in a way that makes sense to them in their domain.
>          Gives me a
>         > generic XML output that I can use to build classes for a
>         variety of
>         > programming languages that can be executed against this
>         reference model
>         > in each of those languages.
>         >
>         > Here is a (non-sensical) modified XML file just showing how
>         I envision
>         > the object (class) names being changed to match the
>         reference model.  I
>         > didn't bother with the property names but you can imaging
>         that they will
>         > be modified extensively as well.
>         >
>         > I would appreciate any thoughts/commets/feedback on this
>         approach.
>         
>         Hi,
>            First of all, everything you want to do should be quite
>         simple and require
>         no modifications to Glade, except hiding the existing
>         catalogs.
>         
>         Glade installs usually with at least the GTK+ catalog - and
>         while practically
>         speaking, you dont need to display this catalog in the
>         palette, you do need
>         the GTK+ catalog to be installed to do useful things with GTK+
>         derived objects.
>         
>         Basically, if you havent yet looked into the reference docs,
>         the idea is that
>         every catalog provides an adaptor class for any object that
>         the catalog wants
>         to introduce to the Glade runtime - so for instance, to
>         leverage the code
>         that does Drag/Resize in the GtkTable widget, you will want to
>         derive from
>         the GladeWidgetAdaptor that was subclassed for GtkTable.
>         
>         So I would suggest you start by creating your catalog with
>         your GTK+ derived
>         widgets and depend on the 'gtk+' catalog - when you are
>         finished that part,
>         which may only imply declaring the object types and
>         disableing/hiding some
>         properties, or could imply providing some of your own custom
>         editing widgets
>         (i.e. the property editor is subclassable and allows you to
>         present
>         the information
>         differently than just flat properties, the class adaptor
>         provides a mechanism
>         to create an editor on behalf of the class)...
>         
>         Anyway that would be the juice of your work, hiding the
>         installed GTK+ catalog
>         from the palette could be a feature you maintain as a
>         downstream hack/patch
>         against Glade, or if its of any real use to others we could
>         even develop some
>         mechanism in Glade to hide widgets from catalog dependencies.
>         
>         Actually, you could even probably just remove the
>         <glade-widget-class-ref> entries
>         and <glade-widget-group> entries in the GTK+ catalog, which
>         would result in the
>         types getting properly introduced into the runtime, but no
>         references
>         to the widgets
>         from the palette.
>         
>         Have fun :)
>         
>         Cheers,
>                -Tristan
>         
>         
>         --
>         ***************************************************************
>         Timothy Cook, MSc
>         
>         LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
>         Skype ID == (upon request)
>         Academic.Edu Profile: http://uff.academia.edu/TimothyCook
>         
>         You may get my Public GPG key from  popular keyservers or
>         from this link http://timothywayne.cook.googlepages.com/home
>         
> 


-- 
***************************************************************
Timothy Cook, MSc

LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
Skype ID == (upon request)
Academic.Edu Profile: http://uff.academia.edu/TimothyCook

You may get my Public GPG key from  popular keyservers or    
from this link http://timothywayne.cook.googlepages.com/home

Attachment: signature.asc
Description: This is a digitally signed message part