[Bese-devel] Documentation

[Marco Baringer]

Marco Simon <marco_simon at web.de> writes:

> Hi list,
>
> once again some questions from a lisp and ucw-beginner:
> Marco Baringer mentioned in his great "hello-world" video
> that one could use the (ok x y) function for catching the field-
> values from a html-form for further processing.

ok is an action which takes two arguments: 1) the component 2) the
value. what it does is to cause the call form which created the
component (the first argument to OK) to return the second argument
pased to ok.

(with the new cc-interpreter i am seriously considering redefining OK
like this:

(defaction ok ((c component) &rest values)
  (values-list values))

)

> The ok-functions seem only to return one single field y out of the
> component x. So I can process a single html-form-field. But how can
> I process an html-form with several fields ? I just tried something
> like (<ucw:form :action (list (ok myform field1) (ok myform
> field2))) in order to get the fields' value returned as a list, but
> that didn't seem to work.

nope. there are basically two (or three) options for collecting form
info.

1:

(let ((field1 ...) (field2 ...) (field3 ...))
  (<ucw:form :action (ok component (list field1 field2 field3))
    (<ucw:text :accessor field1)
    (<ucw:select :accessor field2
      (<ucw:option :value (something))
      (<ucw:option :value (something-else)))
    (<ucw:input :type "checkbox" :accessor field3)))

in this case you'd use the component like this:

(defaction whatever ((c component))
  (destructuring-bind (f1 f2 f3)
      (call 'my-form-component)
    (do-stuff f1 f2 ...)))

2:

(<ucw:form :action (ok component)
  (<ucw:text :accessor (field1 component))
  (<ucw:select :accessor (field2 component)
    (<ucw:option :value (something))
    (<ucw:option :value (something-else)))
  (<ucw:input :type "checkbox" :accessor (field3 component)))

and now you'd use the component like this:

(defaction whatever ((c component))
  (let ((form-data (call 'my-form-component)))
    (do-stuff (field1 form-data) (field2 form-data) ...)))

or 3:

(<ucw:form :action (ok component)
  (<:text :name "f1")
  (<:select :name "f2"
    (<:option :value "a string")
    (<:option :value "another string"))
  (<ucw:input :type "checkbox" :name "f3"))

and you'd use it like this:

(defaction whatever ((c component))
  (let* ((form-data (call 'my-form-component))
         (f1 (ucw::get-parameter "f1" (ucw::context.request *context*)))
          ...)
    (do-stuff f1 f2 ...)))


i've used both #1 and #2 depending on what felt easier at the
time. i've never used #3 but i have seen it "in the wild" and will
gladly accept a patch which makes it slightly easier to type. #3 has
the draw back that the values passed around must all be strings, but
has the advantage that you can use it in public urls (iow you don't
need an already existing session object).

> Wha other actions beside (ok x y) could I have used ? I guess it isn't the
> only one for processing html-formular-data. And much more important:

There are no 'form processing' actions. All actions are 'form
processing' actions. does this make any sense? an action is just a
function which takes a component as the first parameter and is defined
via defaction. you can write an action which takes as may other args
as you want and you can get the parameters to an action from just
about anywhere.

> How could I answer that question by myself ? At this point I am used to
> pic some function-reference and have a look for the fitting function.

basically anything defined via defaction.

with a very very recent ucw/arnesi you can inspect the variable
arnesi::*cc-functions* and find out all the functions defined via
defmethod/cc (the macro underlying defaction).

> A futher problem, which perhaps is related to my
> developement-environment (xemacs via ssh, cmucl, slime/swank, ucw)
> is that my emacs gets stuck as soon as any error appears while my
> ucw-application is running. The the browser starts loading the next
> "page" endlessly, my emacs/slime shows me the the debugger, but I'm
> not able do anything futher in emacs because it doesn't react on any
> further input.  Any Ideas what the problem might be ?
> Compile-time-errors can be debugged without any problems and without
> getting stuck.

this is really really bad :( this basically makes an instantaneous
edit/compile/debug cycle (the core of lisp development) impossible.

slime has a know bug where, when an sldb buffer first pops up, the
first key you hit (whatever it is) generates a <buffer is read-only>
error, but subsequent key presses should work.

first off a few questions: what version of cmucl? is the entire setup
running remotely or is xemacs local and everything else is remote?
what's in the *slime-events* buffer? have you run
mp::startup-idle-and-toplevel-loops? (i believe slime runs this
automatically on startup, but adding it to .cmuclrc can't hurt)

hth.

-- 
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen