OK, I finally read/worked through the tutorial, and I'm pretty impressed.
Definitely easy to use!
I don't yet see how to store data in a SQL database (generally an absolute
requirement for my apps), or how to close one top-level panel and open another
(command buttons, menu's, etc.). That said, for a calculator-type app as in the
tutorial project it's a pretty fast way to build an app and manage the various
layers.
Here's hoping it continues to grow!
John
OK, I finally read/worked through the tutorial, and I'm pretty
impressed. Definitely easy to use!
Great!
I don't yet see how to store data in a SQL database (generally an
absolute requirement for my apps), ...
Unfortunately Mindwrapper does not provide relational support, so
this requirement may keep it from being of use to you. In the
beginning, I had thought I would map the domain data-model to
relational tables for this purpose, but the so called impedance
mismatch became too great so I abandoned that idea. Structured
document persistence has turned out to be effective for the kinds
of data we need to store and retrieve, and Python's pickler is
perfect for serializing the data object tree. I modified
__getstate__ so that only independent values are saved. Dependent
variables and design-time data constraints are not stored. My
guess is that it would not take much to make Mindwrapper compatible
with Zope, but making it compatible with SQL seems overwhelming.
Apologies.
... or how to close one top-level
panel and open another (command buttons, menu's, etc.). That
said, for a calculator-type app as in the tutorial project it's
a pretty fast way to build an app and manage the various layers.
The current (prelimary) demo does not show how to do this, but the
mw.Button presenter has a method you can override to carry out a
command. The mw.Menu presenter will do the same, although that
implementation is not part of the current release.
Here's hoping it continues to grow!
Thanks.
Regards,
--- John Hopkins <john@hopkinsit.com> wrote:
=====
Donnal Walter
Arkansas Children's Hospital
Webware's MiddleKit maps a Pythonic object model onto a SQL database. I
have already used the object model to generate HTML forms and views.
There's no reason the same couldn't be done for the GUI.
I recall one of the early MiddleKit users was doing a GUI, not a WUI,
but I don't remember what GUI framework he was using.
http://webware.colorstudy.com/twiki/bin/view/Webware/?topic=MiddleKit
http://webware.sourceforge.net/Webware-0.7/MiddleKit/Docs/Intro.html
On Friday 28 March 2003 06:54 am, Donnal Walter wrote:
Unfortunately Mindwrapper does not provide relational support, so
this requirement may keep it from being of use to you. In the
beginning, I had thought I would map the domain data-model to
relational tables for this purpose, but the so called impedance
mismatch became too great so I abandoned that idea. Structured
document persistence has turned out to be effective for the kinds
of data we need to store and retrieve, and Python's pickler is
perfect for serializing the data object tree. I modified
__getstate__ so that only independent values are saved. Dependent
variables and design-time data constraints are not stored. My
guess is that it would not take much to make Mindwrapper compatible
with Zope, but making it compatible with SQL seems overwhelming.
Apologies.
--
Chuck
http://ChuckEsterbrook.com
Webware's MiddleKit maps a Pythonic object model onto a SQL
database.
If I understand correctly, this statement is not quite accurate.
MiddleKit maps its own middle tier syntax onto a compatible
Pythonic object model and SQL database. Unless I have
misunderstood, it will NOT take an arbitrary object tree in Python
and map it to SQL.
I have already used the object model to generate HTML
forms and views. There's no reason the same couldn't be done for
the GUI.
I recall one of the early MiddleKit users was doing a GUI, not a
WUI, but I don't remember what GUI framework he was using.
If you want to write your own GUI framework (using wxPython, for
example), Webware/MiddleKit would be one way to provide SQL
support. MiddleKit uses its own "middle tier" syntax from which to
generate SQL CREATE statements and to define Python objects with
which "to bootstrap your project." IOW, Middlekit is a good tool if
you are building your own RDBMS framework, but unfortunately it is
not compatible with the Mindwrapper model-view-presenter
architecture.
--- Chuck Esterbrook <ChuckEsterbrook@yahoo.com> wrote:
=====
Donnal Walter
Arkansas Children's Hospital
This is a must in my opinion. (We're moving to SQL now,
and I'm certainly not going back on that. I consider that
more important than the Python vs Excel issue, regardless
of how much I loathe Excel...)
I can understand that it's convenient to make a "canned"
solution, where you can create all from GUI to storage in
one place, but I think it's important to be able to work
in layers as well, separating presentation from logic and
storage.
I didn't understand that Mindwrapper had this goal to provide
much more than a GUI. If that's enforced, it'll obviously rule
it out as a generic high level API for wxPython.
Anyway, I really think you will regret locking out SQL, Donnal.
There is *nothing* today that compares to relational databases
in providing the ability to handle shared data of the type we
discuss here. Relational databases provide a big array of
features such as concurrent multi user updates, safe transactions,
on-line backups, reporting tools, aggregating statistics, ad hoq
queries etc etc. It's also a well established technology, and
most sites will have existing relational databases used for
exisising systems that you might want to replace or integrate
with. Relational databases are also a very close fit for the kind
of data values and structures that we work with in these types
of applications. There are also small embedded SQL systems such
as SQLite as well as free but capable databases such as PostgreSQL,
SAP DB and Firebird.
This will also provide a smoother transition from legacy solutions
built in Access or with other SQL databases.
I think the easiest way would be to use a wrapper such as Ian Bicking's
SQLObject. That makes it fairly easy to connect a python object model to
an SQL database. See http://www.colorstudy.com/software/SQLObject/
(I'm not sure how SQLObject handles legacy databases though? Can it
handle primary keys composed of several columns? As far as I understand,
there must be a column called 'id' which is the primary key.)
At 06:54 2003-03-28 -0800, Donnal Walter wrote:
Unfortunately Mindwrapper does not provide relational support, so
this requirement may keep it from being of use to you.
...
making it compatible with SQL seems overwhelming.
--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se
Hi Magnus,
If you are looking for a thin layer, similar to SQLObjects, you might want to look at Diedrich Vorberg's ORM (Wiki), I recently started to work with Diedrich to create a Firebird adapter for ORM.
See you
Werner
Magnus Lycka wrote:
At 06:54 2003-03-28 -0800, Donnal Walter wrote:
Unfortunately Mindwrapper does not provide relational support, so
this requirement may keep it from being of use to you.
...
making it compatible with SQL seems overwhelming.
and I'm certainly not going back on that. I consider that
more important than the Python vs Excel issue, regardless
of how much I loathe Excel...)I can understand that it's convenient to make a "canned"
solution, where you can create all from GUI to storage in
one place, but I think it's important to be able to work
in layers as well, separating presentation from logic and
storage.I didn't understand that Mindwrapper had this goal to provide
much more than a GUI. If that's enforced, it'll obviously rule
it out as a generic high level API for wxPython.Anyway, I really think you will regret locking out SQL, Donnal.
There is *nothing* today that compares to relational databases
in providing the ability to handle shared data of the type we
discuss here. Relational databases provide a big array of
features such as concurrent multi user updates, safe transactions,
on-line backups, reporting tools, aggregating statistics, ad hoq
queries etc etc. It's also a well established technology, and
most sites will have existing relational databases used for
exisising systems that you might want to replace or integrate
with. Relational databases are also a very close fit for the kind
of data values and structures that we work with in these types
of applications. There are also small embedded SQL systems such
as SQLite as well as free but capable databases such as PostgreSQL,
SAP DB and Firebird.This will also provide a smoother transition from legacy solutions
built in Access or with other SQL databases.I think the easiest way would be to use a wrapper such as Ian Bicking's
SQLObject. That makes it fairly easy to connect a python object model to
an SQL database. See http://www.colorstudy.com/software/SQLObject/(I'm not sure how SQLObject handles legacy databases though? Can it
handle primary keys composed of several columns? As far as I understand,
there must be a column called 'id' which is the primary key.)
Magnus Lycka:
Donnal Walter:
>Unfortunately Mindwrapper does not provide relational support,
>so this requirement may keep it from being of use to you.
>...
>making it compatible with SQL seems overwhelming.
and I'm certainly not going back on that. I consider that
more important than the Python vs Excel issue, regardless
of how much I loathe Excel...)
... and VBA? <wink>
I can understand that it's convenient to make a "canned"
solution, where you can create all from GUI to storage in
one place, but I think it's important to be able to work
in layers as well, separating presentation from logic and
storage.
Mindwrapper does use separate layers, the presentation is distinct
from the abstraction layer, and for that matter, the document class
allows different types of storage. But see below re: RDBMS.
I didn't understand that Mindwrapper had this goal to provide
much more than a GUI. If that's enforced, it'll obviously rule
it out as a generic high level API for wxPython.Anyway, I really think you will regret locking out SQL, Donnal.
I wouldn't say that I am "locking out" SQL as much as I "gave up"
trying to make it compatible. I guess I would still be open to
figuring out how to make the mapping work. The problem is that if
you really take advantage of hierarchical structuring, the tables
become difficult to construct automatically.
There is *nothing* today that compares to relational databases
in providing the ability to handle shared data of the type we
discuss here. Relational databases provide a big array of
features such as concurrent multi user updates, safe
transactions, on-line backups, reporting tools, aggregating
statistics, ad hoq queries etc etc.
Yes, I have to agree that concurrent multi-user updates, ACID
transactions, on-line backups, and so on would be great.
It's also a well established technology, and
most sites will have existing relational databases used for
exisising systems that you might want to replace or integrate
with. Relational databases are also a very close fit for the kind
of data values and structures that we work with in these types
of applications. There are also small embedded SQL systems such
as SQLite as well as free but capable databases such as
PostgreSQL, SAP DB and Firebird.
Lack of available SQL systems is not my reason for avoiding the
relational option. I know that there are plenty of good systems
available. The problem I had/have is figuring out how to map the
domain object model to relational tables without doing it all by
hand. Translation to Zope's ZODB, for example, would be much easier
and more logical.
"For many tasks, relational databases are clearly a good
solution, but sometimes relational databases don't fit well
with your object model. If you have lots of different kinds
of interconnected objects with complex relationships, and
changing schemas then ZODB might be worth giving a try."
http://www.zope.org/Documentation/Articles/ZODB1
Right now I would classify the Mindwrapper persistence mechanism as
a kind of ZODB-lite, and the component-binding and -naming scheme
as a kind of PEAK-lite.
This will also provide a smoother transition from legacy
solutions built in Access or with other SQL databases.I think the easiest way would be to use a wrapper such as Ian
Bicking's SQLObject. That makes it fairly easy to connect a
python object model to an SQL database. See
http://www.colorstudy.com/software/SQLObject/
I will certainly take a look. I would like nothing better than to
find a way to make Mindwrapper more generally useful.
(I'm not sure how SQLObject handles legacy databases though? Can
it handle primary keys composed of several columns? As far as I
understand, there must be a column called 'id' which is the
primary key.)
Thanks
=====
Donnal Walter
Arkansas Children's Hospital
Magnus Lycka:
... the easiest way would be to use a wrapper such as Ian
Bicking's SQLObject. That makes it fairly easy to connect a
python object model to an SQL database.
See http://sqlobject.org/
Werner F. Bruhin:
If you are looking for a thin layer, similar to SQLObjects, you
might want to look at Diedrich Vorberg's ORM
(Wiki). I recently started to work
with Diedrich to create a Firebird adapter for ORM.
Although I have not yet had time to download and experiment with
these packages, I have read the introductory online documentation
for both. If I understand correctly, both products take a set of
RDBMS tables as the *starting point*, and then they translate the
table rows into corresponding Python objects. AFAIK there is no
mapping that starts with a Python object tree and translates it
into relational tables (which is a more complicated process).
BTW Webware's MiddleKit starts with a middle tier that is mapped in
both directions, but it creates its own Python objects as well.
IMHO the value of Mindwrapper's abstraction layer includes: (1) the
ability to define a complex hierarchical domain model with multiple
interactions, and (2) underlying support for the MVP architecture,
which makes it a breeze to connect the GUI (presentation layer) to
the domain model (abstraction layer).
If I could figure out a way of mapping an object tree created with
the existing Mindwrapper abstraction layer to relational tables, I
would be ecstatic, but mapping relational tables to some kind of
MVP or MVC framework is an entirely different project (worthwhile,
but different).
Regards,
=====
Donnal Walter
Arkansas Children's Hospital
I guess this is getting a bit off-topic for wxPython, even if
it's about the wxPython product Mindwrapper, but there seems to
be several interested people. I'd be happy to move to another
forum if that's desired.
Magnus Lycka:
> ... the easiest way would be to use a wrapper such as Ian
> Bicking's SQLObject.
Werner F. Bruhin:
> you might want to look at Diedrich Vorberg's ORMAlthough I have not yet had time to download and experiment with
these packages, I have read the introductory online documentation
for both. If I understand correctly, both products take a set of
RDBMS tables as the *starting point*, and then they translate the
table rows into corresponding Python objects.
Don't know ORM, but with SQLObject you write a small wrapper class
yourself to tell the code how your tables behave, what foreign keys
there are, and whether you want to use other attribute names in
Python than the column names in SQL etc. It's trivial for programmers
but I guess it might be more of a hurdle for the non-programmers that
Mindwrapper is aimed for.
An excerpt for a current project thinkware.se/whisky/whisky.cgi
follows:
class WhiskyBrand(SQLObject):
_columns = [Col('name'), Col('location', default=''),
Col('owner', default=''), Col('url', default='')]
_joins = [MultipleJoin('Whisky', joinMethodName='whiskies')]
class Whisky(SQLObject):
_columns = [Col('whiskyBrandID', foreignKey='WhiskyBrand'),
Col('type'), Col('details', default='')]
_joins = [MultipleJoin('TastingNote')]
A classic problem with RDBMS is to handle schema evolution, and as
far as I understand, Mindwrapper want to support incremental development.
An approach based on ZODB etc might be simpler, but whatever the tool
is, it's not trivial to evolve an application once there is live data.
I have a feeling that whatever technology we use, development without
skilled programmers is going to be problematic... In a way, the fixed
schema of a relational database might provide a kind of "early warning
system" that might be better than more subtle data problems caused by
schema evolution in a "soft" system such as ZODB...
After all--the difference between a skilled programmer and someone
who is an expert within the problem domain goes far beyond syntax.
I think it's a worthwhile thing to try to create ways to make
something available to non-programmers that allows them to do a
significant part of the development they need, but to have real
expertize involved for the tricky parts is probably a good idea.
AFAIK there is no
mapping that starts with a Python object tree and translates it
into relational tables (which is a more complicated process).
I think we need to be able to go from the database as well, or
we will loose the ability to use existing databases. It really
varie from location to location whether SQL databases are to
be seen as a public interface or an application internal
implementation of storage.
But regardless of that, changing the data model once there is
existing data is non-trivial. I doubt that you can ever create a
system where you can handle non-trivial restructuring of the
data model once there is existing data that you need to preserve.
Another problem I've seen with OO mappers is that they
typically have a very strict opinion about how to map classes
to tables. One concrete class == one table, but there are more
alternatives, and it's not obvious that 1 concrete class = 1
table is always right. With inheritance and just simple kinds
of attributes, you have at least four well know alternatives
(see http://www.ambysoft.com/mappingObjects.html ) out of which
the last (generic schema) might fit Mindwrapper best, but it
doesn't really use the relational database as it's normally done,
and I think both performance and other aspects will suffer.
(I assume ZODB's Oracle backend uses such an approach, and it seems
to work there though.)
But if you have a class with attribute that are collections, like
lists or dicts, the natural solution would be to let several tables
correspond to one class, rather than to force simple collections
to have an object id for each simple value.
For instance, if you have a Polygon class, that looks like this:
class Polygon:
def __init__(self, coordinates, borderColor, fillColor):
...
p = Polygon( ((1,3), (4,3), (5,5)) black, red)
it would be natural to save it in two tables like this:
polygon
oid |border|fill|
0123456|black |red |
polygon_coordinates
oid |i|x |y |
0123456|0|1.0|3.0|
0123456|1|4.0|3.0|
0123456|2|5.0|5.0|
Has anyone seen a wrapper that allows this? Automatically?
I think SQLObject could force me to make a Coordinate class,
where every coordinate has an object identity, which I would
not have bothered about from a pure Python perspective.
BTW Webware's MiddleKit starts with a middle tier that is mapped in
both directions, but it creates its own Python objects as well.
I never liked the idea to make such a big bundle in one package
as Webware and ZOPE. I'm more of a Unix philosophy man, preferring
more independent components...but maybe I need to take another
look...
If I could figure out a way of mapping an object tree created with
the existing Mindwrapper abstraction layer to relational tables, I
would be ecstatic, but mapping relational tables to some kind of
MVP or MVC framework is an entirely different project (worthwhile,
but different).
I'm sure a generic schema mapping would be possible, but it leads
to low performance (complex selects for each object) and difficult
reporting, so it might not be worth it.
At 09:09 2003-03-29 -0800, Donnal wrote:
--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se
I guess this is getting a bit off-topic for wxPython, even if
it's about the wxPython product Mindwrapper, but there seems to
be several interested people. I'd be happy to move to another
forum if that's desired.
Thank you for your thoughtful reply. I, too, would be happy to move
this discussion to another forum if need be, but the topic has
broader implications for wxPython than SQL-mapping alone. Currently
wxPython does not implement a document-view framework, nor does it
provide built-in support for MVC or MVP architectures. So, one way
or another, nearly every wxPython app has to deal with connecting
GUI objects to persistent data, relational or not.
With your indulgence I will first respond to a few related points
by addressing them together (but out of order).
... It's trivial for programmers but I guess it might be more of
a hurdle for the non-programmers that Mindwrapper is aimed for.
... ...
I have a feeling that whatever technology we use, development
without skilled programmers is going to be problematic...
... ...
After all--the difference between a skilled programmer and
someone who is an expert within the problem domain goes far
beyond syntax. I think it's a worthwhile thing to try to create
ways to make something available to non-programmers that allows
them to do a significant part of the development they need, but
to have real expertize involved for the tricky parts is probably
a good idea.
First, let me say that Mindwrapper is NOT intended primarily for
non-programmers (despite what I said about one of your clients
possibly finding it helpful). In fact, it was originally intended
just for my own use, but along the way I was talked into making it
available to a wider audience. My purpose in releasing it as open
source now is to give something back to the community that has been
so helpful to me, and to get feedback that will help me improve it
(for others, and for my institution).
As I mentioned previously, I came to Python and wxPython out of a
deep dissatisfaction with Excel/VBA/Access. En route I tried Java
and Eiffel, but found the code/compile/test cycles too cumbersome
for my style. Python, however, "fit my mind" and fit my style
perfectly, so I thought I had found the answer.
As much as I enjoyed wxPython, however, it still seemed that the
process could be made simpler. Initially I merely wrote a few
prototype apps using wxPython, but soon I began to notice common
problems with common solutions: things like overlapping hierarchies
of nested panels and nested sizers, binding events to observable
objects, independent and dependent variables, separation of data
concerns from presentation concerns, and so on. Then I decided to
design a framework to make it easier to for me to apply these
features to every custom application I work on. The result is
(becoming) Mindwrapper.
If it turns out that Mindwrapper allows problem domain experts to
participate more actively in the development process, that would be
a good thing IMO, but that was not my primary intention. (I am a
practicing MD who happens to have a few programming skills, and in
my experience, being able to see the application from both sides of
the fence is often extremely helpful.)
Now back to the issues at hand.
Don't know ORM, but with SQLObject you write a small wrapper
class yourself to tell the code how your tables behave, what
foreign keys there are, and whether you want to use other
attribute names in Python than the column names in SQL etc. It's
trivial for programmers but I guess it might be more of a hurdle
for the non-programmers that Mindwrapper is aimed for.
The point I was trying to make is that with SQLObject, the starting
point is the table, not the object tree. Sure, it is trivial to
write the small SQLObject wrapper around the table, but then you
still need to connect the GUI to it: not difficult, but not trivial
and often tedious. It is the ease of connecting the presentation
layer to the abstraction layer that makes Mindwrapper useful to me.
A classic problem with RDBMS is to handle schema evolution, and
as far as I understand, Mindwrapper want to support incremental
development. An approach based on ZODB etc might be simpler, but
whatever the tool is, it's not trivial to evolve an application
once there is live data.I have a feeling that whatever technology we use, development
without skilled programmers is going to be problematic... In a
way, the fixed schema of a relational database might provide a
kind of "early warning system" that might be better than more
subtle data problems caused by schema evolution in a "soft"
system such as ZODB...
First I should say that I have no immediate plans to interface
Mindwrapper to ZODB. I only mentioned it because doing so would be
more natural (and probably easier) than interfacing to an RDBMS.
Nevertheless, the Mindwrapper abstraction layer, is one that you
would likely consider a "soft" system. It is easy to add new data
elements (even complex elements) to existing data documents in
Mindwrapper (but that is true for an RDBMS as well?). Likewise,
removing a given element is no problem. Renaming elements or moving
them in the labeled tree-graph presents a more difficult problem,
but I have been working on a mechanism to allow that as well.
After all--the difference between a skilled programmer and
someone who is an expert within the problem domain goes far
beyond syntax. I think it's a worthwhile thing to try to create
ways to make something available to non-programmers that allows
them to do a significant part of the development they need, but
to have real expertize involved for the tricky parts is probably
a good idea.
Point taken (see above). But surely you wouldn't object to making
your own job easier, would you? <wink>
Donnal Walter:
> AFAIK there is no mapping that starts with a Python object
> tree and translates it into relational tables (which is a
> more complicated process).I think we need to be able to go from the database as well, or
we will loose the ability to use existing databases. It really
varie from location to location whether SQL databases are to
be seen as a public interface or an application internal
implementation of storage.
Because my own custom applications do not start with an existing
database, I have been a bit blind to this situation until now, but
you make a good point. OTOH, I would expect it to be easier to map
a relational table into a Mindwrapper object tree than the other
way around.
But regardless of that, changing the data model once there is
existing data is non-trivial. I doubt that you can ever create a
system where you can handle non-trivial restructuring of the
data model once there is existing data that you need to preserve.
This is a difficult problem, without question, but with Python's
introspection capabilities, my untested opinion is that migrating
one object tree to another will be easier than changing a set of
relational tables.
Another problem I've seen with OO mappers is that they
typically have a very strict opinion about how to map classes
to tables. One concrete class == one table, but there are more
alternatives, and it's not obvious that 1 concrete class = 1
table is always right. With inheritance and just simple kinds
of attributes, you have at least four well know alternatives
(see http://www.ambysoft.com/mappingObjects.html ) out of which
the last (generic schema) might fit Mindwrapper best, but it
doesn't really use the relational database as it's normally done,
and I think both performance and other aspects will suffer.
Mindwrapper's information model is best described as a directed,
acyclic, labeled graph. In such a graph, there are two kinds of
branch nodes: list nodes and object nodes. *If* and when I try my
hand at mapping to relational tables, I would definitely think that
each list node would map to a separate table. Object nodes could be
mapped using any of the first three alternatives mentioned above,
or possibly some combination.
But if you have a class with attribute that are collections, like
lists or dicts, the natural solution would be to let several
tables correspond to one class, rather than to force simple
collections to have an object id for each simple value.
Yes, exactly.
--- Magnus Lycka <magnus@thinkware.se> wrote:
=====
Donnal Walter
Arkansas Children's Hospital
> Webware's MiddleKit maps a Pythonic object model onto a SQL
> database.If I understand correctly, this statement is not quite accurate.
MiddleKit maps its own middle tier syntax onto a compatible
Pythonic object model and SQL database. Unless I have
misunderstood, it will NOT take an arbitrary object tree in Python
and map it to SQL.
"a Pythonic object model" in my sentence was referring to the MiddleKit
object model, which is Pythonic (as opposed to SQLonic). But your point
is correct. Unlike say, ZODB, MiddleKit doesn't archive any old Python
object.
> I have already used the object model to generate HTML
> forms and views. There's no reason the same couldn't be done for
> the GUI.
>
> I recall one of the early MiddleKit users was doing a GUI, not a
> WUI, but I don't remember what GUI framework he was using.
>
> http://webware.sourceforge.net/If you want to write your own GUI framework (using wxPython, for
example), Webware/MiddleKit would be one way to provide SQL
support. MiddleKit uses its own "middle tier" syntax from which to
generate SQL CREATE statements and to define Python objects with
which "to bootstrap your project." IOW, Middlekit is a good tool if
you are building your own RDBMS framework, but unfortunately it is
not compatible with the Mindwrapper model-view-presenter
architecture.
The MiddleKit/Python classes are fairly ordinary Python citizens. You
might be right that they are incompatible with Mindwrapper's MVP
architecture, although they certainly aren't incompatible with MVP in
general (as I remember it from Smalltalk).
On Saturday 29 March 2003 04:04 am, Donnal Walter wrote:
--- Chuck Esterbrook <ChuckEsterbrook@yahoo.com> wrote:
--
Chuck
http://ChuckEsterbrook.com
Is that last part ("but it creates its own Python objects") a problem?
What it first does is create classes. For example, if your obj model
defines "Customer", then you wind up with a Customer.py class that is
nearly empty which inherits from a GenCustomer.py class which contains
all the generated MiddleKit stuff.
Customer.py "belongs to you". You can put whatever you like in there
(normally your business/domain logic) including adding more base
classes. MiddleKit will instantiate it when you fetch objects out of
the database.
Presumably, you would have had a Customer.py and Customer class anyway
if you were building your objects from scratch.
Does that cause any technical issues with Mindwrapper?
On Saturday 29 March 2003 09:09 am, Donnal Walter wrote:
BTW Webware's MiddleKit starts with a middle tier that is mapped in
both directions, but it creates its own Python objects as well.
--
Chuck
http://ChuckEsterbrook.com
Aaaaaahhh! That just kills me. 
I built Webware to be modular because Zope's architecture was too
monolithic for me. However, new people always assume that because
Webware comes with more than one package, that it's also monolithic.
Webware's MiddleKit does NOT require the app server (WebKit) or vice
versa. Likewise with UserKit, etc.
There are _some_ dependencies, like WebKit requires MiscUtils, but given
the nature of MiscUtils (to collect utility classes and functions not
found in the Python std lib), that's not surprising or burdensome.
On Saturday 29 March 2003 01:45 pm, Magnus Lycka wrote:
I never liked the idea to make such a big bundle in one package
as Webware and ZOPE. I'm more of a Unix philosophy man, preferring
more independent components...but maybe I need to take another
look...
--
Chuck
http://ChuckEsterbrook.com
Chuck Esterbrook:
Donnal Walter:
> BTW Webware's MiddleKit starts with a middle tier that is
> mapped in both directions, but it creates its own Python
> objects as well.Is that last part ("but it creates its own Python objects") a
problem? What it first does is create classes. For example, if
your obj model defines "Customer", then you wind up with a
Customer.py class that is nearly empty which inherits from a
GenCustomer.py class which contains all the generated MiddleKit
stuff.Customer.py "belongs to you". You can put whatever you like in
there (normally your business/domain logic) including adding
more base classes. MiddleKit will instantiate it when you fetch
objects out of the database.Presumably, you would have had a Customer.py and Customer class
anyway if you were building your objects from scratch.Does that cause any technical issues with Mindwrapper?
[and from another part of the thread]:
The MiddleKit/Python classes are fairly ordinary Python citizens.
You might be right that they are incompatible with Mindwrapper's
MVP architecture, although they certainly aren't incompatible
with MVP in general (as I remember it from Smalltalk).
"Incompatible with the architecture" may have been too strong a
statement. I probably was thinking "incompatible with the syntax".
Or "redundant" with the syantax may be even more accurate.
The Mindwrapper abstraction layer (AL) notation is a modeling
language in its own right, and it defines classes that have the
right hooks for the MVP architecture created in the notation found
in the presentation layer (PL), not to mention links for dependent
variables, inheritable constraints, internal lists of complex
objects and more. Yes, the MiddleKit/Python classes are ordinary
Python citizens. That means someone has to add hooks for the MVP
framework. The Mindwrapper AL classes are NOT ordinary Python
citizens; they have the MVP hooks built in. I suppose it might be
possible to use multiple inheritance in some way to mix the two
different sets of classes, although I can't think of a relatively
painless way to do so.
MiddleKit provides a spreadsheet style (CSV-based) syntax for
modeling a domain. Mindwrapper provides a Python-based syntax for
domain modeling. MiddleKit generates classes that have the right
hooks for SQL access. Mindwrapper defines classes that have the
right hooks for GUI access. Two different types of notations, two
different goals. Can they be mergerd seamlessly? Perhaps, but off
the top of my head, I don't see how.
This is no criticism of MiddleKit, BTW, which I find potentially
more compatible with the basic Mindwrapper information model than
either SQLObject or ORM.
Regards,
=====
Donnal Walter
Arkansas Children's Hospital
I am trying to use wxPyGridTableBase as a viewer/editor of a potentially
large database. So far it looks great. However, there is a particular method
I was expecting to find, but so far I have not been able to find it. This is
what I want to do.
I can set up the grid table, I can set up a database cursor, I can retrieve
data from the cursor and populate the grid in response to requests from
GetCellValue (probably not the correct method name, but I am not in front of
my machine at the moment).
I want to give the user the ability to "jump" into the middle of the table,
say by selecting a starting name. I want to redisplay the grid starting from
this point, but still with the ability to scroll up and down through the
entire table.
I can calculate the starting row number by doing a search through the
cursor. I cannot find a way to pass this number to the grid so that it can
reset its first visible row number to this calculated value, and redisplay
itself from that point.
Hopefully someone will be able to point me in the right direction.
TIA
Frank Millman
See section:
1.4.1 Cursor Manipulation
from http://wiki.wxpython.org/index.cgi/wxGrid .
Particularly:
SetGridCursor, and MakeCellVisible
HTH,
Mike
Frank Millman wrote:
I am trying to use wxPyGridTableBase as a viewer/editor of a potentially
large database. So far it looks great. However, there is a particular method
I was expecting to find, but so far I have not been able to find it. This is
what I want to do.I can set up the grid table, I can set up a database cursor, I can retrieve
data from the cursor and populate the grid in response to requests from
GetCellValue (probably not the correct method name, but I am not in front of
my machine at the moment).I want to give the user the ability to "jump" into the middle of the table,
say by selecting a starting name. I want to redisplay the grid starting from
this point, but still with the ability to scroll up and down through the
entire table.I can calculate the starting row number by doing a search through the
cursor. I cannot find a way to pass this number to the grid so that it can
reset its first visible row number to this calculated value, and redisplay
itself from that point.Hopefully someone will be able to point me in the right direction.
TIA
Frank Millman
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org
--
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
It's not just me then... Perhaps you should think about marketing
and packaging?
It's a long time since I looked at it (Sept 2001) so I guess I
ought to have another look. I can well imagine that the threshold
to get into it is smaller now.
What I remember was that I hardly ever got past installation and
configuration, but that was long before distutils etc, so I can
imagine that things are much better now. (Although it seems
MiddleKit is still alpha after all htis time?)
If I compare with a recent project, I used SQLObject and PyMeld.
With both those the threshold to download, install and get productive
was very low.
Are you using MiddleKit with wxPython?
At 01:26 2003-03-30 -0800, Chuck wrote:
Aaaaaahhh! That just kills me.
I built Webware to be modular because Zope's architecture was too
monolithic for me. However, new people always assume that because
Webware comes with more than one package, that it's also monolithic.
--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se
What I remember was that I hardly ever got past installation and
configuration, but that was long before distutils etc, so I can
imagine that things are much better now. (Although it seems
MiddleKit is still alpha after all htis time?)
I need to update that to "production". MK has already been used in
production applications for some time and has the most extensive
regression test suite of any package in Webware.
If I compare with a recent project, I used SQLObject and PyMeld.
With both those the threshold to download, install and get productive
was very low.Are you using MiddleKit with wxPython?
No, my current app is surprisingly low on data. I may pull it in on
"Phase II".
An early MiddleKit user was doing GUIs, but I don't recall the
framework. Of course, you can use MiddleKit anywhere (gui, command
line, etc.) but there would be benefit in having wxPython libs
ready-to-go to generate grid views for browsing objects, detailed
object views and forms.
Magnus Lycka wrote:
class Polygon:
def __init__(self, coordinates, borderColor, fillColor):
...p = Polygon( ((1,3), (4,3), (5,5)) black, red)
it would be natural to save it in two tables like this:
polygon
>oid |border|fill|
>0123456|black |red |polygon_coordinates
>oid |i|x |y |
>0123456|0|1.0|3.0|
>0123456|1|4.0|3.0|
>0123456|2|5.0|5.0|Has anyone seen a wrapper that allows this? Automatically?
Not sure but check AdaptableStorage for ZODB
Niki Spahiev
Many thanks to Mike and to Chuck for the replies - SetGridCursor was the
answer. According to the docs, MakeCellVisible is called automatically by
SetGridCursor, so I left it out and it works fine without it.
I should have found it myself, but I was looking in the wxPyGridTableBase
class for a method, forgetting that all the methods in wxGrid are
available - twit.
The results are spectacular. I can scroll through a table of 20 000 rows,
and jump to any row I want to based on a search string, at blazing speed,
using both PostgreSQL and SQL Server. If I push it to 50 000 rows, searching
through the cursor slows down a bit, but in practice no-one will scroll
through such a big table without applying some filtering first, so I do not
think it will be a problem.
Thanks again, guys.
Frank Millman
----- Original Message -----
From: "Mike C. Fletcher" <mcfletch@rogers.com>
To: <wxPython-users@lists.wxwindows.org>
Sent: Sunday, March 30, 2003 6:08 PM
Subject: Re: [wxPython-users] Help wth wxPyGridTableBase
See section:
1.4.1 Cursor Manipulation
from http://wiki.wxpython.org/index.cgi/wxGrid .Particularly:
SetGridCursor, and MakeCellVisibleHTH,
Mike