ANN: Dabo 3-tier desktop framework for data-aware apps

[Paul McNett]

Hello Pythonistas,

Ed Leafe and I have been collaborating on a new 3-tier framework
for creating cross-platform data-aware applications. While it
is still quite alpha, we decided to go ahead and announce it to
get a feel for what level of interest it would gather.

The product's name is Dabo, and it will let you create
data-aware desktop apps for distribution to Mac, Linux, Unix,
and Windows computers. It is written in Python and wraps
the wxPython widgets, which is why we are announcing it here.

Attached is the text of the complete announcement, but it is
kind of long. Please visit us at:

http://dabodev.com

and if interested in Dabo, consider joining one or both of our
mailing lists:

http://leafe.com/mailman/listinfo/dabo-users
http://leafe.com/mailman/listinfo/dabo-dev

Only join the dev list if you think you want to participate in
dabo's development or monitor the daily source code commit
traffic and ensuing discussion.

Thanks!

---
May 11, 2004
Announcing Dabo 0.1

Dabo is a Python module that provides a true 3-tier desktop
application framework. It separates the three main parts of a
desktop app: database access, user interface and business
logic. You would typically use Dabo to develop graphical,
data-aware desktop applications.

Both the database layer and the UI layer can be used
independently from the rest of Dabo. In fact, we have
endeavored to make the Dabo classes much simpler to work with
than the underlying UI systems they are based on. But the real
strength comes with using Dabo as your entire framework,
complete with the dApp application object.

Dabo, since it is written in Python, runs on Unix, Linux, Mac OS
X, and Windows (all flavors).

Dabo is very early in its development, so the choices for
database and UI are limited at the moment. Currently, the only
supported database backend is MySQL, and the only supported
user interface library is wxPython. However, the system was
designed from the beginning to be able to support any database
or UI; all it will take is some time and effort. In the near
future, all popular databases will be supported, including
PostgreSQL, Oracle, Berkeley DB and MS-SQL. There is also no
reason that other that other UI libraries, such as PyQt,
TkInter, Curses, PyObjC, and even HTTP can work with Dabo.

One of the key factors in the evolution of Dabo will be the
contribution of the community. If you have a database or UI
library you'd like supported, we'd love to add your
contributions to the product! The key to any Open Source
project is the involvement and development of a community, and
Dabo is no different.

Dabo is a dual-licensed open source project. You may download it
and use it for free under the GPL, which would allow you to
distribute it for free with your GPL projects, or you may
purchase licenses for distribution with commercial or
proprietary applications for a reasonable fee. We are also
considering offering a FOSS (Free and Open Source Software)
Exception, which would keep your non-GPL'd projects from
falling under the GPL.

There is no warranty provided with Dabo, it is provided 'as-is'.
Dabo is currently in a pre-alpha state of development. There is
currently no official documentation, other than the source code
and the introductory bits on our website:

http://dabodev.com


The primary means of support is provided through the dabo-users
mailing list, to which you may subscribe by visiting:

http://leafe.com/mailman/listinfo/dabo-users


Dabo may be downloaded from the following link:

http://leafe.com/dls/dabo


We invite you to participate in the development of Dabo. The
source code is available from our Subversion repository, so
you'll need to install the Subversion client from
http://subversion.tigris.org. If you are familiar with CVS,
you'll love Subversion. The repository can then be downloaded
by issuing the following command:

svn checkout svn://paulmcnett.com/dabo/trunk dabo


There is a mailing list for developers, to which you may
subscribe by visiting:

http://leafe.com/mailman/listinfo/dabo-dev

All development conversations are had there, and commit
notifications are sent there. You may submit patches to that
address as a text attachment in svn diff format.


In addition to the main dabo project, there are three other
Dabo-related projects in various states of development:

svn checkout svn://paulmcnett.com/dabodemo/trunk dabodemo
svn co svn://paulmcnett.com/dabodesigner/trunk dabodesigner
svn checkout svn://paulmcnett.com/dabodoc/trunk dabodoc

The 'dabodemo' project seeks to develop one or more example
applications that can be used by developers learning Dabo as a
guideline and/or starting point for understanding how to go
about creating an application using Dabo. A frequent problem
with any new development tool is right after you get it
installed and say "OK, now what?". The dabodemo project's goal
is to provide some examples to get you going.

The 'dabodesigner' project is an attempt to create a visual form
design tool, analogous to the design surfaces in Visual Studio,
or the Form/Class designer in Visual FoxPro. While it is *very*
early in development and still needs a lot of work, it has a
lot of functionality in it already. There is also a 'wizard'
for creating basic database table maintenance applications.
Depending on user interest, this project may grow to include
other similar tools to make the visual side of app development
easier.

The 'dabodoc' project is designed to be a repository for
documentation. Like most projects that are the work of a small
group, the developers have been too busy developing to properly
document things. This is our acknowledgement of that fact, and
a place for those of you who want to contribute, to write
and/or Edit the Dabo documentation.


Please visit our website at:

http://dabodev.com


and contribute to the Dabo Wiki at:

http://dabodev.com/wiki

 

[francois lepoutre]

Hi Ed and Paul,

I've seen your announcement on comp.lang.*
Findind ex-vfpers working on python is nice,
on wxpython. This is a superb piece of news!

I was in Europython last year but found not
one european vfp-er among the folks there.
Engineering people mostly.

My feeling was: well i'm the only one with
the typical "business + db experience"
that vfp-ers have have for years.

Sure python offers the kind of smart
interpreter-based dev. environment that
the foxpro community has enjoyed for
years.

Possibly I made the wrong choice...
Your announcement may make a change
within the vfp community.

You're right. It's about time foxpro-ers
to commit to the python community
and even more important to the wxpython
user group.

A general feeling about community support
for vfp-ers, wikis are nice but mailing-lists are
a question of choice (i definitely dislike them)...

What about a forum or newsgroup kind
of support "à la UT" with personal pictures
and other community stuff ? and why not
a dabo annoucement on UT first?

François

 

[john fabiani]

Hi Ed and Paul,

I've seen your announcement on comp.lang.*
Findind ex-vfpers working on python is nice,
on wxpython. This is a superb piece of news!

I was in Europython last year but found not
one european vfp-er among the folks there.
Engineering people mostly.

My feeling was: well i'm the only one with
the typical "business + db experience"
that vfp-ers have have for years.

Sure python offers the kind of smart
interpreter-based dev. environment that
the foxpro community has enjoyed for
years.

Possibly I made the wrong choice...
Your announcement may make a change
within the vfp community.

You're right. It's about time foxpro-ers
to commit to the python community
and even more important to the wxpython
user group.

A general feeling about community support
for vfp-ers, wikis are nice but mailing-lists are
a question of choice (i definitely dislike them)...

What about a forum or newsgroup kind
of support "à la UT" with personal pictures
and other community stuff ? and why not
a dabo annoucement on UT first?

François

I'm a newbie in python but with 20 years in VFP. So I'm following this
project with great interest. Why recreate what UT already has? Just
add a new forum. UT supports java, C# and many other forum - why not
one for DaBo? BTW have you reviewed gnue?

I picked python because I believe it's a very close match to VFP in many
ways. I think the classes are a match, no typing is a match, and many
other items. Of course list, dictionary, tuples are not matches and
along with the biggy no direct access to data. But DBAPI 2.0 looks sort
of like SPT with one exception - transactions are handled by the
connection - so no begin transaction. Either commit or rollback.
Another interesting point is there is no buffering like VFP it's handled
by the DBM (I'm using postgres)

The thing I miss the most is creating a cursor from the data. Something
like "Select * from curreport where some_selection into cursor
curreport". Normally I'd make a general select and then refine the data
to meet my needs. but I'm still learning how to view the data at the
moment so maybe it will come.

I also have not discovered the way to print reports or any routines that
will generate the detail bands etc... But I have faith that they are
out there. I really hope that I don't have to hand code reports.

 

[John J. Lee]

I also have not discovered the way to print reports or any routines
that will generate the detail bands etc... But I have faith that they
are out there. I really hope that I don't have to hand code reports.

'Report' is a fairly broad concept. It sounds like 'report' means
something quite specific to a VFP-er, though. If so, what would that
be?


John

 

[john fabiani]

'Report' is a fairly broad concept. It sounds like 'report' means
something quite specific to a VFP-er, though. If so, what would that
be?


John

Big subject reports - in VFP we have a visual way to create printed
reports. Normally, the report is associated with data (a cursor). The
report form program loops thru the cursor and outputs the data to the
report form to be printed either to the screen or a printer. The visual
report editor allows the programmer to work with bands (detail,group,
title, summary and several others). If you have worked with other
report writers they generally work the same way. In a broad sense it's
sort like working with a forms editor (boa). The report information is
kept in a table and a report program reads the table to generate the
output to the printer (along with the data). I think this how pyQT
works to generate a window but pyQT uses a glade file (I think).
Anyway, at the moment I don't have a way to send data to a printer.

I'm guessing but I bet that simple text can be sent to a printer using
Python (looping of course). But in today's world most users want
graphics along with the data. Like an invoice with a logo, boxes around
the bill to and ship to, along with column lines. So I'm hoping that
someone has at least started a project to print reports.


John

 

[Peter Hansen]

I'm guessing but I bet that simple text can be sent to a printer using
Python (looping of course). But in today's world most users want
graphics along with the data. Like an invoice with a logo, boxes around
the bill to and ship to, along with column lines. So I'm hoping that
someone has at least started a project to print reports.

That would be "ReportLab", I would think... Google for it.

-Peter

 

[john fabiani]

That would be "ReportLab", I would think... Google for it.

-Peter

I book marked it - but it looks like a web solution??????

John

 

[Andrew Bennetts]

I book marked it - but it looks like a web solution??????

Not at all. It's a python library that can generate PDFs for you -- it's
very well suited to making things like pretty invoices. I've used it to do
exactly that in one of my past jobs.

-Andrew.

 

[Mark D]

Big subject reports - in VFP we have a visual way to create printed
reports. Normally, the report is associated with data (a cursor). The
report form program loops thru the cursor and outputs the data to the
report form to be printed either to the screen or a printer. The visual
report editor allows the programmer to work with bands (detail,group,
title, summary and several others). If you have worked with other
report writers they generally work the same way. In a broad sense it's
sort like working with a forms editor (boa). The report information is
kept in a table and a report program reads the table to generate the
output to the printer (along with the data). I think this how pyQT
works to generate a window but pyQT uses a glade file (I think).
Anyway, at the moment I don't have a way to send data to a printer.

I'm guessing but I bet that simple text can be sent to a printer using
Python (looping of course). But in today's world most users want
graphics along with the data. Like an invoice with a logo, boxes around
the bill to and ship to, along with column lines. So I'm hoping that
someone has at least started a project to print reports.


John

Regarding reporting.
I am new to python and have similar questions. I have briefly looked
at www.reportlab.org and found their "Platypus" module very
interesting and simple for creating PDF documents. A comprehnsive
document framework is offered. With just a few lines of code you are
able to generate professional reports. Handling tabular data via is
also very easy.
Have a look.

Mark
ps: first post (hope no blunders)

 

[john fabiani]

[...]


I also have not discovered the way to print reports or any routines
that will generate the detail bands etc... But I have faith that they
are out there. I really hope that I don't have to hand code reports.


'Report' is a fairly broad concept. It sounds like 'report' means
something quite specific to a VFP-er, though. If so, what would that
be?


John

Big subject reports - in VFP we have a visual way to create printed
reports. Normally, the report is associated with data (a cursor). The
report form program loops thru the cursor and outputs the data to the
report form to be printed either to the screen or a printer. The visual
report editor allows the programmer to work with bands (detail,group,
title, summary and several others). If you have worked with other
report writers they generally work the same way. In a broad sense it's
sort like working with a forms editor (boa). The report information is
kept in a table and a report program reads the table to generate the
output to the printer (along with the data). I think this how pyQT
works to generate a window but pyQT uses a glade file (I think).
Anyway, at the moment I don't have a way to send data to a printer.

I'm guessing but I bet that simple text can be sent to a printer using
Python (looping of course). But in today's world most users want
graphics along with the data. Like an invoice with a logo, boxes around
the bill to and ship to, along with column lines. So I'm hoping that
someone has at least started a project to print reports.


John

Regarding reporting.
I am new to python and have similar questions. I have briefly looked
at www.reportlab.org and found their "Platypus" module very
interesting and simple for creating PDF documents. A comprehnsive
document framework is offered. With just a few lines of code you are
able to generate professional reports. Handling tabular data via is
also very easy.
Have a look.

Mark
ps: first post (hope no blunders)

Thanks I have been reviewing the site and a few google messages. Looks
like this might work for what I want/need...
ohn

 

[francois lepoutre]

I'm a newbie in python but with 20 years in VFP. So I'm following this
project with great interest.

Ditto... well only 18 years on foxpro

Why recreate what UT already has? Just
add a new forum. UT supports java, C# and many other forum - why not
one for DaBo? BTW have you reviewed gnue?

Just received Ed feedback on the subject. I'll post an announcement
for DABO on UT to-day on Dabo team's behalf.

I picked python because I believe it's a very close match to VFP in many
ways. I think the classes are a match, no typing is a match, and many
other items. Of course list, dictionary, tuples are not matches and
along with the biggy no direct access to data. But DBAPI 2.0 looks sort
of like SPT with one exception - transactions are handled by the
connection - so no begin transaction. Either commit or rollback.
Another interesting point is there is no buffering like VFP it's handled
by the DBM (I'm using postgres)

I've come thru the the same experience. The recent addition of
decimal and datetime support will definitely help vfp-ers.
Thanks to the python developpers for this.

The thing I miss the most is creating a cursor from the data. Something
like "Select * from curreport where some_selection into cursor
curreport". Normally I'd make a general select and then refine the data
to meet my needs. but I'm still learning how to view the data at the
moment so maybe it will come.

The VFP db-aware UI side is missing. Let us hope Dabo will fill
part of the gap.

I also have not discovered the way to print reports or any routines that
will generate the detail bands etc... But I have faith that they are
out there. I really hope that I don't have to hand code reports.

Well ... "ReportLab" is a code-based reporting tool, not a db-aware
visual tool "à la crystal" . It clearly does fit the bill at this stage as
a replacement for the vfp report writer. A wx* visual report writer
would be a great addition to wxpython. I've not heard of any at
this stage.

François

 

[Peter Hansen]

I book marked it - but it looks like a web solution??????

I don't know quite what you mean by that, but it generates
PDF files, so I suppose it's at least broader than what
"web solution" implies to me.

-Peter

 

[David Fraser]

Hello Pythonistas,

Ed Leafe and I have been collaborating on a new 3-tier framework
for creating cross-platform data-aware applications. While it
is still quite alpha, we decided to go ahead and announce it to
get a feel for what level of interest it would gather.

The product's name is Dabo, and it will let you create
data-aware desktop apps for distribution to Mac, Linux, Unix,
and Windows computers. It is written in Python and wraps
the wxPython widgets, which is why we are announcing it here.

Attached is the text of the complete announcement, but it is
kind of long. Please visit us at:

http://dabodev.com

My gzip doesn't like your dabo unix source tar.gz files ... are they OK?
David

 

[Paul McNett]

My gzip doesn't like your dabo unix source tar.gz files ...
are they OK?

No they weren't. My Python upload script was converting them
from binary to ascii by adding the linefeeds for the
appropriate platform. This 'feature' has been fixed, with good
files uploaded. Sorry for the inconvenience.

 

[john fabiani]

I don't know quite what you mean by that, but it generates
PDF files, so I suppose it's at least broader than what
"web solution" implies to me.

-Peter

I answered to quickly. After review I'm sure that reportlab will work.
John

 

[David Fraser]

David Fraser writes:




No they weren't. My Python upload script was converting them
from binary to ascii by adding the linefeeds for the
appropriate platform. This 'feature' has been fixed, with good
files uploaded. Sorry for the inconvenience.

Thanks

David