2010/3/10 àÒÉÊ íÉÒÏÎÅÎËÏ
<tallman@inbox.ru>
> Magritte is not ONLY for web development descriptions, but for any
> description.
Unfortunately, it's very common to use Magritte only as a tool for generating web-forms. Most if not all Magritte examples are about it. Tool like Magritte looks very powerful...potentially :) And it's not only about descriptors. Memento functionality is described in pretty easy-to-understand way, for example. Conditions structure and validation is very funny, too. I personally used two described above.
Firstly, I used magritte-based memento to fight GLORP limitations. GLORP has no nested UnitOfWorks, and you really need something in realworld application that will handle "save" button :). So, on "save" button pressing I begin UnitOfWork, commit memento and then commit UnitOfWork. It works very funny...but I was forced to implement my own memento class for it. There are two problems with Magritte mementos, and both leading to idea of GLORP-Magritte integration:
a) Magritte's default memento try to manage parallel edits to the model (and well, GLORP needs something like this, isn't it?). It makes two "copies" of object, one for manipulating, and other for comparing to "real object" on commit. It gives possibility to track modification to "real object". made in period from making memento to commiting it. Well, it conflicts with GLORP proxies. Instantiating of a proxy forces Magritte think there are edit conflict...well, you can manage it by using not-default memento (Caching instead of Checking).
b) Magritte's mementos can't manage model's behavior. For example, if I have simple object with two editable fields #price and #amount and one read-only field #total, it will be impossible to use Magritte's mementos to edit such an object. Supposing you want to observ #total during edit, i.e. before commit will happen. To manage this, I made a new Memento class. It makes a new instance of model's class for caching, and then uses every not-read-only Accessor to copy values from model to this class (well, it was little bit harder, but not much). And you see, it's very, very similar to GLORP caching technique.
You can overlook this on http://squeaksource.com/SmallPOS.html
Secondly, I trying to use (working on it just now) Magritte conditions not for just making data entry validations, but for implementing fast search and to build where-clauses for GLORP. And well, trying to do it I feel myself like...hmmm...translating from one language to another with similar semantic but different words :)
I was forced to expand Magritte descriptor's system with "this accessor should return this value". And GLORP already has it.
Next, GLORP's blocks parsing technique looks very promising for Magritte. Magritte has "plugable" condition, but it's out of Magriite concept really. Parsing of blocks may help a lot, combining "easy to write and read" advantage of blocks and "it's possible to serialise/manage programmatically" advantage of explicit using of special classes. GLORP uses block parsing for very same reasons, I believe.