:present-as widget odd behavior

[Jason Miller]

I needed a quick list presentation and so used the widget :present-as with a child-class of gridedit.  This appears to work, but I get warnings that make no sense; namely "Implicitly calling MAKE-WIDGET to render #<FUNCTION ...>" and "Cannot update the widget children of #<FUNCTION ...>" where the function is what I'm using as the argument to :widget-init

I set a (break) on the render-widget-body default method, and here's a partial backtrace:

  0: ((:METHOD WEBLOCKS:RENDER-WIDGET-BODY (T)) #<FUNCTION (LAMBDA (&KEY WL-FCCS::VALUE WL-FCCS::FABOO &ALLOW-OTHER-KEYS) :IN "/home/aidenn/src/lisp/wl-fccs/src/init-session.lisp") {100C8B$
  1: ((LAMBDA (WEBLOCKS::OBJ &REST WEBLOCKS::ARGS) :IN WEBLOCKS:RENDER-WIDGET) #<FUNCTION (LAMBDA (&KEY WL-FCCS::VALUE WL-FCCS::FABOO &ALLOW-OTHER-KEYS) :IN "/home/aidenn/src/lisp/wl-fccs/$
  2: ((:METHOD WEBLOCKS:WITH-WIDGET-HEADER (T T)) #<FUNCTION (LAMBDA (&KEY WL-FCCS::VALUE WL-FCCS::FABOO &ALLOW-OTHER-KEYS) :IN "/home/aidenn/src/lisp/wl-fccs/src/init-session.lisp") {100C$
  3: ((:METHOD WEBLOCKS:RENDER-WIDGET (T)) #<FUNCTION (LAMBDA (&KEY WL-FCCS::VALUE WL-FCCS::FABOO &ALLOW-OTHER-KEYS) :IN "/home/aidenn/src/lisp/wl-fccs/src/init-session.lisp") {100C8B3F4B}$
  4: ((:METHOD WEBLOCKS:RENDER-WIDGET-CHILDREN (WEBLOCKS:WIDGET)) #<WEBLOCKS:DATAFORM "dom558">) [fast-method]
  5: ((:METHOD WEBLOCKS:WITH-WIDGET-HEADER (T T)) #<WEBLOCKS:DATAFORM "dom558"> #<FUNCTION (LAMBDA (WEBLOCKS::OBJ &REST WEBLOCKS::ARGS) :IN WEBLOCKS:RENDER-WIDGET) {100A2063AB}> #<unavaila$
  6: ((:METHOD WEBLOCKS:RENDER-WIDGET (T)) #<WEBLOCKS:DATAFORM "dom558">) [fast-method]
  7: (WEBLOCKS::RENDER-DIRTY-WIDGETS)
  8: ((LAMBDA NIL :IN WEBLOCKS:HANDLE-CLIENT-REQUEST))
  9: ((:METHOD WEBLOCKS:HANDLE-CLIENT-REQUEST (WEBLOCKS:WEBLOCKS-WEBAPP)) #<unavailable argument>) [fast-method]
 10: ((FLET #:|doit-95| :IN WEBLOCKS:HANDLE-CLIENT-REQUEST))
 11: ((:METHOD WEBLOCKS:HANDLE-CLIENT-REQUEST :AROUND (T)) #<WL-FCCS::WL-FCCS {100456C393}>) [fast-method]
 12: (WEBLOCKS::CALL-IN-WEBAPP #<WL-FCCS::WL-FCCS {100456C393}> #<CLOSURE (LAMBDA NIL :IN WEBLOCKS:HANDLE-CLIENT-REQUEST) {100AC09D0B}>)
 13: ((:METHOD WEBLOCKS:HANDLE-CLIENT-REQUEST :AROUND (WEBLOCKS:WEBLOCKS-WEBAPP)) #<WL-FCCS::WL-FCCS {100456C393}>) [fast-method]
 14: ((:METHOD HUNCHENTOOT:HANDLE-REQUEST (HUNCHENTOOT:ACCEPTOR HUNCHENTOOT:REQUEST)) #<WEBLOCKS:WEBLOCKS-ACCEPTOR (host *, port 3455)> #<HUNCHENTOOT:REQUEST {100AC01803}>) [fast-method]
 15: ((:METHOD HUNCHENTOOT:PROCESS-REQUEST (T)) #<HUNCHENTOOT:REQUEST {100AC01803}>) [fast-method]
 16: (HUNCHENTOOT::DO-WITH-ACCEPTOR-REQUEST-COUNT-INCREMENTED #<WEBLOCKS:WEBLOCKS-ACCEPTOR (host *, port 3455)> #<CLOSURE (LAMBDA NIL :IN HUNCHENTOOT:PROCESS-CONNECTION) {100AA5B06B}>)
 17: ((:METHOD HUNCHENTOOT:PROCESS-CONNECTION (HUNCHENTOOT:ACCEPTOR T)) #<WEBLOCKS:WEBLOCKS-ACCEPTOR (host *, port 3455)> #<USOCKET:STREAM-USOCKET {100A9B46A3}>) [fast-method]

[Jason Miller]

On Wednesday, January 14, 2015 at 3:51:27 PM UTC-8, Jason Miller wrote:

I needed a quick list presentation and so used the widget :present-as with a child-class of gridedit.  This appears to work, but I get warnings that make no sense; namely "Implicitly calling MAKE-WIDGET to render #<FUNCTION ...>" and "Cannot update the widget children of #<FUNCTION ...>" where the function is what I'm using as the argument to :widget-init

So I tracked this down to the following code:

(defmethod widget-children ((obj dataform) &optional type)

  "Returns all widgets from all view fields with presentation widget-presentation"

  (let ((widgets))

    (map-view-fields 

      (lambda (field-info)

        (when (typep (slot-value (field-info-field field-info) 'presentation) 'widget-presentation)

          (push (widget-presentation-widget (slot-value (field-info-field field-info) 'presentation)) widgets)))

      (dataform-form-view obj)

      (dataform-data obj))

    widgets))

 Since widget-presentation-widget must be funcallable, there is no way that it will be a widget; furthermore the view itself takes care of redrawing itself when the dataform is dirty.  Is it safe to just completely remove this method?

[o_z]

Yes, code should be fixed and tested, if you can do it you are welcome.

It is in low priority for me.

вторник, 3 февраля 2015 г., 22:35:14 UTC+2 пользователь Jason Miller написал: