[cells-devel] [Fwd: Re: some dumb? cells questions]

[Kenny Tilton]

Kenny Tilton wrote:

>
>> From: Friedrich Dominicus <frido at q-software-solutions.de>
>> Subject: some dumb? cells questions
>> To: cells-devel at 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