[cells-devel] my very first baby steps with cells

[Kenny Tilton]

Friedrich Dominicus wrote:

>Kenny Tilton <ktilton at nyc.rr.com> writes:
>
>  
>
>>Friedrich Dominicus wrote:
>>
>>    
>>
>>>I got it (probably ;-), would someone mind to comment on it?
>>>      
>>>
>
>Thanks for your time. I try to explain my "convulted" way of getting
>into celsl a bit ;-)
>
>  
>
>>   (make-instance 'controller
>>          :view-obj (init-view view))
>>
>>C-IN (or C-INPUT) is used only where, in brief, the application will
>>be using SETF to change the value in a sempahoric slot. This is partly
>>because a dataflow model needs to get the original dataflow from
>>somewhere, usually from operating system events or a socket. One can
>>also sometimes get simpler and more efficient code by skipping the
>>declarative aspect (in which a slot like view-obj would have a rule)
>>and just make the slot C-In and then setf that slot from output
>>methods on on other slots. But like I said, that loses the advantages
>>of a declarative approach.
>>    
>>
>Well I read the explanations in 01-somwwhat and there I found if you
>the slot hast to be setf-able you have to use c-in (in short, so I
>wrote it that way.
>
I should have mentioned "...but I do not see any place in your code 
where you SETF view-obj". Did I miss it?

>  
>
>>Now in this case I further do not see view-obj getting involved in any
>>cell-mediated dataflow, so I do not think it even needs to be a cell.
>>
>>    
>>
>>>  (db-obj :accessor db-obj :initarg :db-obj :cell t
>>>:initform (cells:c? (update-from-view cells:self)))))
>>>
>>>      
>>>
>>The opening bit of update-from-view says:
>>
>>    (unless (slot-value self  'db-obj)
>>        .....)
>>
>>Actually, the c? macro offers any existing value as a read macro:
>>
>>    (db-obj :accessor db-obj :initarg :db-obj :cell t
>>    :initform (cells:c? (unless .cache.
>>                                  (update-from-view cells:self))))
>>
>>    
>>
>I've seen the variable but was quite happy to find out the above way
>;-)
>
That is fine if you do not mind "unsupported", ie, your code collapsing 
in a heap if Cells changes in some relevant way. the larger point is 
that, either way, after the second time this rule runs there will be no 
dependencies and the cell (and rule) will get optimized away. So I still 
do not see Cell-ish dataflow. That said,.....

>
>  
>
>>...and then do not check for an existing slot-value in u-f-v. Now I
>>do have rare occasion to write code like that, but the interesting
>>thing here is that this rule only runs once, after which it would
>>always return the same value. So there is no dataflow here, where one
>>thing changes (by a SETF of some c-input) and then a bunch of other
>>things get updated automatically in a cascade of rule evaluations. 
>>    
>>
>
>I do not understand that. If the view changes e.g if I use the back
>button of my browser I'll be back to the old view. The data will get
>filled from the then actual Database view, if I change something again
>it will get propagated again from the View to the Backend. 
>
I believe you! :) I just do not see the back button in the code or how 
this is working! I have a guess, though. I think somehow each time you 
are allocating all new instances, so the new cells / rules run once (the 
initial "awaken" pass started by TO-BE) and things show up nicely. Cells 
are all about long-lived state, where the same instance would survive 
back buttons and forward buttons and sideways buttons and still manage 
to stay current. That said <g>.......

>  
>
>>Maybe I missed something. My first question, does this code work for
>>you? If so, what are the things you see happening that tell you it
>>work? Just give me a simple scenario, such as "I start by reading in
>>this stuff. Then I change this description field, then I exit, and
>>when I look at the DB I see the new description text." Provide the
>>sample code and explain where necessary which code does which step.
>>    
>>
>See above, the back button of the browser makes it possible to return
>to the view. 
>  
>
>>A big problem here is that I do not know SQL or cl-sql. For example, is a view just in-memory, or does it refer to a screen view? I know a relational view is just an abstraction built atop physical tables, so maybe you are just talking about that. Well, I do see:
>>
>>    (defcomponent example-view (simple-window-component)
>>      ((db-obj :initarg :db-obj :reader db-obj)
>>       (tag :accessor tag :initarg :tag
>>        :component (text-field :size 20 :maxlength 20))
>>       (description :type string :accessor description :initarg :description
>>                :component (text-area-field :width 20 :height 10))
>>       (other :accessor other :component (text-field :size 20 :maxlength 20))))
>>
>>...and that looks like a GUI view component. Maybe the term is used
>>both ways? if you are updating a description field in a GUI view and
>>then seeing it written back out to the DB, maybe you could lay out for
>>me the code path by which that happens.
>>    
>>
>That is the view-component, I just included the db-obj to start the
>whole thing, I see from you comments that I probably could add it
>in the model and there the view-obj slot.
>  
>
>>    
>>
>>>I this a decent use of 'cells and is it cells-ish?
>>>
>>>      
>>>
>>Pending a better understanding of the above questions, as I said, I do
>>not see Cells doing very much, and so I would be surprised if they
>>help in this case. But let's see what your feedback is on the above.
>>    
>>
>Well Cells does the following for me here. I sketch the control-flow.
>- the first things which is called is a view which shows two textfields
>and one text area
>- On the first run the view object should be filled with data from the
>  backend
>- so I got a view with the slots filled by database values
>- Now I may change one, two or three fields. Aftar I send the form the
>database should be updated, this is done by cells here.
>- After that the content of both the view and the database are shown
>- Now it happens that I found that I made a bug and hit Back on my
>browser
>- the browser will display me the first view again, but with the
>changed database values
>- I change them again hit submit and the stuff updates my Database
>again.
>
>Agreed, cells does not do much here, but it's to learn how to let
>those objects interact. And for that it works quite nicely ;-)
>
I am going to go waaaaaaaaaaay out on a limb here and guess that the 
only thing Cells did was force you to structure things in a declarative 
way, or at least a nicely organized way, and that that itself is a big 
win. So it is not an issue of how long-lived is a model instance, or how 
many times a Cell rule runs, but how the data structures interact (as 
you said).

I have been doing Cells for ten years, but this is the first time I have 
encountered this. Interesting result. Thx.

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it."
    Elwood P. Dowd, "Harvey", 1950