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

[Friedrich Dominicus]

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.
>
> 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
;-)

> ...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. 
>
> 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 ;-)

Regards
Friedrich