On Saturday 23 March 2002 05:32 pm, Ernesto Revilla wrote:
> Dear everybody,
>
> Still I'm not using Webware. (But I hope soon.)
>
> Things that would be nice:
>
> * The dumping routine you (Stefan and Jason) should be part of
> MiddleKit and perhaps the default persistence method, if no database
> is configured. Consider the Java J2EE container behaviour which
> writes entity beans to files when it is shut down.
Using a single text file as the persistent store would kill performance
and concurrency in a serious way. Even one file per class would be
difficult.
Something based on pickle or marshal might be workable.
PickleObjectStore would inherit from ObjectStore and flesh out the
abstract methods. But I'm not saying it would be easy.
> * An model-wide unique object Id. I read in an article of OR-Mapper
[snip]
MK already has model wide unique object ids. This is the objectKey() of
an MK object. It simply consists of the klass serial num and the obj
serial num (which is relative to the class).
This has worked really well since the beginning.
> * Transactions: In Webkit a transaction is a container for session,
Would be nice. I don't have a strong need for them, so this will have
to come from someone else.
> * Triggers: It seems that a database abtraction layer gives us the
> freedom to choose whatever database vendor. Compiere ERP (see
> Sourceforge) is using oracle but a PostgresSQL transformation is
> underway. But no database abstraction (but translation). So we hace
> to rewrite all the logic again for the middle-tier? Don't know.
> Perhaps. In the object world, triggers are observers. Whenever a
> observer wants to see changes (or accesses) of an object (class) it
> registers itself in the class. Whenever a value is changed
> (setAttribute) it checks if there are any observers and calls them in
> sequence. An observer could change the real value to be changed (or
> leave it as it is, cancelling the modifications).
>
>
> * As I have the plan to write a ERP, I will try also to write some
> rule interpreter, so business rules can be written in a simple
> language: If attribute x of an object of class y is modified, change,
> delete or insert a object, or call some other function. (It would be
Triggers are more procedural/RDB oriented. Although some applications
can benefit from an explicit, general purpose observer system, most can
just use method overriding. Take your example of "if attribute x of an
object of class y is modified, ...call some other function." In
MiddleKit you would do this:
class Y(GenY):
def setX(self, value):
GenY.setX(self, value)
function()
MK already generates the Y.py stub for you. So it's the last 3 lines
that you have to add.
In fact, putting rules outside the Y class could be confusing.
> nice, that advanced users of the application could establish their
> own rules: if stock goes below stock.min, send me an email.)
You don't have to write any code for that example. I already did!
http://StockAlerts2.com/
> * I don't like where much SQL conditions as it binds to much to the
> database. Instead a generic query language should be established,
> perhaps a subset of OQL. Instead of TableX INNER JOIN TableY INNER
> JOIN TableZ, much more intuitive and easier to remember and write
> would be class.attribute1.attribute2......attributeN=something, like
> Order.Line.ArticleRef.Stock<1 should be translated into SQL
> (ArticleRef is of type Article, Line is of type OrderLine) to
> (Article INNER JOIN OrderLine ON Article.Ref=OrderLine.ArticleRef)
> INNER JOIN Order ON OrderLine.OrderRef=Order.Ref WHERE
> Article.Stock<1). Also object comparison, should have no problems if
> unique Object-Ids would be used.
Yes. I think we could take advantage of the python parser that comes
with python and perhaps have a Pythonic query language that gets
translated to SQL or whatever. But I get along fine with what we have
now in my day to day work.
-Chuck
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
