[COLUG] RE: Open Source Application Development

Mark Erbaugh mark at microenh.com
Wed Jun 11 14:19:03 EDT 2008


On Wed, 2008-06-11 at 12:58 -0400, josh at globalherald.net wrote:
> Mark,
> 
> Have you taken a look at DialogBlocks?  Granted, it isn't open source, but
> it seems to make developing wxWidgets apps easier.
> 
> http://www.anthemion.co.uk/dialogblocks/
> 
> Adding an ORB makes things more fragile, as it's just another part to break.

Thanks for that comment.  One of the problem with developing in Python
is how much do you create and how much do you re-use other routines. I
like Python development and know I tend to reinvent some wheels.

> 
> You say that you have some fairly complex table manipulations.  How much
> of this work is done by the client side app?  The folks at OpenMFG,
> purveyors of the free xTuple ERP application [1], put all of their heavy
> lifting in Postgres itself as updateable views.  Then, they have a
> QT-based GUI that just calls the views.

Right now, almost all of the work is done by the client. I have
separated the GUI and the database code.  I am enforcing referential
integrity in the database.  I have separated the GUI and the database
access code in the client.  I'll have to think about moving this code to
the database. Right now, the GUI sees a Python object with all the
functionality of the business object.  The object has new() and get(id)
methods to create a new or retrieve an existing object.  The GUI uses
methods and properties of the object to modify it, then uses a put()
method to write the object to the database.

I guess I could move the database code to the server and marshal the
object to the client.


> 
> At one point, philosophically I was a database purist - keep the data in
> the DB, nothing else - but I've seen how much less work it can be to do
> things as the OpenMFG folks do.  A database with well-designed stored
> functionality is leaps and bounds more efficient (and less painful) than
> an ORB.

On a former project, I inherited an in-house corporate ERP system. It
was written in Borland Delphi and used MS SQL Server for the database.
Most of the database manipulation was done on the Delphi side and when I
first started maintenance, I continued to do that. As the project
progressed, I started using more and more stored procedures and a lot of
the added features were implemented on the SQL Server side.  For
example, originally reports would do simple queries of data, the process
the results in Delphi. Later reports did much of the work in a SQL
Stored Procedure just returning data to be formatted and printed by
Delphi.

Thanks for the other links.

Mark



More information about the colug432 mailing list