view fields that do not correspond to data slots

[Jan Rychter]

I have a view with fields that do not correspond to data slots in the
data object. I thought it was enough to specify :slot-name nil in the
view field definition, but it seems this gets ignored. I'm not ussing
scaffolding.

The result was that when I had a view field with a reader, but no
writer, I was getting this warm welcome from my debugger:

There is no applicable method for the generic function
#<STANDARD-GENERIC-FUNCTION SB-MOP:SLOT-DEFINITION-WRITERS (1)>
when called with arguments
(NIL).
[Condition of type SIMPLE-ERROR]

Restarts:
0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "hunchentoot-worker-266" {12DE6A81}>)

Backtrace:
0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA NIL) {14D77995}>)
1: (SWANK::DEBUG-IN-EMACS #<SIMPLE-ERROR {12FC1889}>)
2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {12FC1DFD}>)
3: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {1207C979}> #<CLOSURE (LAMBDA NIL) {12FC1E0D}>)
4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {1207C979}> #<CLOSURE (LAMBDA NIL) {12FC1DFD}>)
5: ((LAMBDA (CONDITION SWANK-BACKEND::OLD-HOOK)) #<SIMPLE-ERROR {12FC1889}> #<CLOSURE (LAMBDA (CONDITION SWANK-BACKEND::OLD-HOOK)) {12191D7D}>)
6: (INVOKE-DEBUGGER #<SIMPLE-ERROR {12FC1889}>)
7: (INVOKE-DEBUGGER #<SIMPLE-ERROR {12FC1889}>)[:EXTERNAL]
8: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T)) #<unused argument> #<unused argument> #<SIMPLE-ERROR {12FC1889}>)
9: (SIGNAL #<SIMPLE-ERROR {12FC1889}>)[:EXTERNAL]
10: (ERROR #<SIMPLE-ERROR {12FC1889}>)[:EXTERNAL]
11: ((SB-PCL::FAST-METHOD HANDLE-CLIENT-REQUEST NIL) #<unused argument> #<unused argument>)
[...]

Incidentally, is there a way to make these backtraces at least a little
bit more meaningful? I mean, apart from the error message there is zero
useful information in the backtrace itself (yes, I tried compiling after
proclaiming debug 3) :-(

Anyway, the problem was triggered in
update-object-view-from-request. find-slot-dsd could not find the
effective slot definition (not surprising, the slot does not exist), so
slot-definition-writers complained:

(write-value (field value obj)
"Writes a field value into object's slot."
(if (slot-boundp field 'writer)
(funcall (form-view-field-writer field) value obj)
(when (view-field-slot-name field)
(let* ((writer-name (car
(slot-definition-writers
(find-slot-dsd (class-of obj)
(view-field-slot-name field)))))
(writer (when writer-name (fdefinition writer-name))))
(if writer
(funcall writer value obj)
(setf (slot-value obj (view-field-slot-name field))
value))))))

This code would actually work correctly if :slot-name nil weren't getting
ignored for me.

What I don't quite understand was why this code was executed at all when
my slot did not have a :writer definition?

In case you wonder, "virtual" view fields with readers but no writers
can be useful, because you can still perform validation on them. An
example could be a dual-password-entry form.

--J.

[Vyacheslav Akhmechet]

On 5/11/08, Jan Rychter <j...@rychter.com> wrote:
> I have a view with fields that do not correspond to data slots in the
> data object. I thought it was enough to specify :slot-name nil in the
> view field definition, but it seems this gets ignored.

Just pass nil instead of the name:

(defview foo (...)
(nil ...)
(nil ...))

The defview compiler removes all references to slot-name keyword
argument because it uses the first symbol for that.

> What I don't quite understand was why this code was executed at all when
> my slot did not have a :writer definition?

The idea is that if the slot doesn't have a writer, you may still wish
to serialize it vie setf slot-value. You could always pass a writer to
the form view field that does nothing, if that's what you'd like.

> Incidentally, is there a way to make these backtraces at least a little
> bit more meaningful?

There probably is, but I haven't discovered it yet, unfortunately :)