Kenny Tilton wrote:

...

From: Friedrich Dominicus frido@q-software-solutions.de Subject: some dumb? cells questions To: cells-devel@common-lisp.net Date: Tue, 06 Sep 2005 15:16:14 +0200 Organization: Q Software Solutions GmbH

I'm trying to find my way into decent web-programming, and are now looking into the following simple? Problem. The proofed way of doing web-programming seems the MVC stuff. Now the model may be a cl-sql class e.g and the view may come from any of the web"frameworks", however there is a need to get the data cleanly to the view and back I wonder if that would be a good? usage for cells.

Yes, it is a perfect fit because of the requirement that the model and view always be in synch. Of course on Windows they have the "refresh view" option so users can go quietly crazy not finding what they know is there, so there /are/ alternatives. :)

I did this with Franz's AllegroStore. What is needed is a bottleneck on DB writes, some place to put a custom hook which will cooperate with a Cell-powered mechanism to allow seamless declarative view code...uh, here is an example: a simple list view of all my cutomers. That will be a stack of text labels/controls, each showing the customer name. If the name changes we want the label to change, and if a customer is added or removed we want the list contents to grow or shrink. For the latter, we want to say:

(aStack ()... :kids (c? (mapcar #'make-list-cell (^ps-table 'customer))))

...where ps-table is a layer of code I wrote to make it seems as if the AllegroStore (persistent CLOS) customer class had a cell called ps-table (maybe a bad name) which amounted to a list of all the instances of that class in the persistent DB.

The hook I used was easy: because it was a persistent CLOS implementation, I was able to use things like initialize-instance and slot-value-using-class to place hooks on my persistent classes. These hooks simulated Cell-like data propagation from DB writes, effectively gluing DB access to the larger Cell-based application model.

...

So here we go with the questions. How would I tell cells to populate the view with database data?

Does SQL have any kind of callback mechanism that lets you detect DB writes? If not, you must create bottleneck functions for DB writes and use them consistently, then do the gluing from there. And you IPC to "announce" DB changes. We used GUIDs to give DB instances object identity that can be shared amongst processes.

Please note that this all /does/ involve creating a nice little layer of code to connect SQL with Cells. So it is no free lunch. But I have written a lot of code like this before and after Cells and I can confirm that it is a huge win for this type of DB browser/updater application. The view just stays in synch with the DB with no further effort from the developer than the original one-time effort to glue the DB to the Cells. Hellasweet.

...

How would I enforce a "direkt link", will say if the model data changes the view is modified accordingly and vice versa

"changes the view" I covered above. vice-versa (getting the model to follow the view) is no magic. Well, the output methods probably help a little. But at some point the user has to confirm an update, so the write itself ends up being procedural, not some rule on a persistent model instance slot that automatically copies a changed view instance slot.

...

How would I write validation functions?

I actually arranged for persistent slots of persistent instances to have rules associated with them. There was an "error" slot that could handle things like DB inconsistency, if one wanted to allow the DB write but raise a flag for the user to address. Otherwise, I was also able to have a non-persistent slot on a persistent class. That could be a validation rule, then the GUI code would refuse to commit the changes of an invalid record.

I know SQL does not work like an object database, but if I had to do this I would first look for one of the rough hacks done to fake persistent CLOS with SQL and see if they would work, because CLOS itself offers so many hooks. Or I might do my own perisstent CLOS hack. I think you really need /some/ CLOS correlate of your DB to make this work-- well, not "need", but I think it would be the easiest way to go.

kt