From: Bartek W. <ba...@re...> - 2003-03-04 18:09:36
|
Quoting Przemyslaw Krzysztof Rekucki <pr1...@st...>: > > Currently we have following opened tasks: > > * GcEvn > * GcUtils > * GcObject Hierarchy > * GNUccess Application > > Good names, but what this means ? > > I will try to specify global architecture of planed system. > > .----------. > | Modules | > `----------' > > 1. Database Abstraction Layer (DAL) > Just an interesting link (you probably all know it but i think it's quite nice) http://www.python.org/topics/database/DatabaseAPI-2.0.html There are lots of modules allready conforming to that standard - so we can think of some kind of wrapper that would fit all of them - just a thought. > Posible features: > > - Visual Conection Constructor. Here's the place for my problem. I really know that this is not very difficult and there are thousands of ways to do it but I think that my idea is very nice and elegant. So what's my problem ? I think that we will often have a situation like this - user wants to create something in GUI. Let's say he wants a GcDataSource. (somehow I prefer to call it Data source instead of Connection - i think that we will have someday a nice XML internal datasource which is not "connected" to anything :) We could get all subclasses of GcDataSource from GcClasses and create a menu position for each. But i think tere's a much more elegent way to do this. I we could change the interface - so that Create() returns the object it has created. That would mean that our GcDataSource.Create() could have returned something different then "self" (off course self would be the most common value) Then we would have a very elegant way to create something. GcDataSource.Create() - would know what kind of subclasses it has and let you choose whhich you want. Then it could invoke this class create method and return it's value. what do you think ? OK - i'll try not to digress so often :P > > - Datatype abstraction. > > - Query syntax abstraction. ( Created queries should work i every > supported db engines) > > - Meta data access and modyfication support. (Adding column, > deleting column, adding checks, itd. ) [TODO] > > - Python objects persistance > Very nice. I like it - although we have to remember not to depart to far from the efficiency. > 2. Database Structure Editor/Creator > > Posible features: > > - Adding Tables, Colums, Indexes, Constraints, itd.. > > - ERD I think that fits into GcDataSOurce.edit() > > 3. Simple data editor. > > Displays databse data in list and allows change, add or delete table > row. > > 4. RAD for Python > > - Forms creator > > - Properties editing > > - Layout editing > > - Some wizards > > - Componet Editor with Source code editing (shell is not enough) > > [TODO] Looks like something to borrow from BOA. > > 5. Components Core (GcObject) > > my proposition: > > class GcObject: > __editors__ = { > 'Name': Editors.Text, > 'Description': Editors.Text > } > __serializable__ = [ 'Name', 'Position' ] > > def toXML(self): > xml = "<node class='"+self.__class__.__name__+"'...>" > for var in self.__class__.__serializable__ > xml = xml +GNUccess.serialize(var, > eval('self.'+var)) > ... > > def Icon(): > ... > > Filed __editors__ should declare inforamtion needed to generate > properties panel. > > Other example: > > class GcButton(GcWidget): > __editiors__ = { > "Label": Editor.Text, > "FrameColor": Editor.Color, > "FrameStyle": WidgetEditor.FrameStyle > } > __serializable__ = GcWidget.__serializable__ + [ "Label", > "FrameColor", "FrameStyle" ] > > ... I'm not sure if I understand all this, but I'm not sure if one method GNUccess.serialize will fit all the serializable properties. > > > Ofcourse component <-> wx connection is missing. > Thats the thing. I meant GcDataSource as a generalized version of connection - but i know that the usual name is connection. > Other modules: > [TODO] > PS. Please post from the address that is subscribed (i guess it will be sufficient to change from: header. Otherwise I have to accept your posts. -- regards Bartek Wilczyński |