[Bese-devel] LispWorks and UCW

[Marco Baringer]

Friedrich Dominicus <frido at q-software-solutions.de> writes:

> sorry, for bothering you with this. I had to tweak the mopp.lisp file,
> and am now not sure if it's a bug with LispWorks or with the given
> code.

never say sorry for a bug report.

> As I understand all the symbols needed for portable MOP should get
> imported with 
> (defmethod provide-mopp-symbol ((symbol symbol) (implementation (eql :lispworks)))
>   (when (find-symbol (string symbol) :clos)
>     (import-to-mopp (find-symbol (string symbol) :clos))))

that's the idea yes.

> Now it happens that this has failed for some symbols, but I suppose
> that should not have happened. I know that the following is just a
> hackerish solution to the problem:

[ snip ]

> but with that I got UCW compiled and running with LispWorks. I'm quite
> sure that this is not the "right" solution to the problem. Maybe
> someone here has a better suggestion.

odd. apparently our provide-mopp-symbol isn't doing what it should. it
would be very helpfull if you: 1) trace mopp::provide-mopp-symbol 2)
reload mopp.lisp 3) check what (find-symbol (string
'mopp::standard-class) :CLOS) returns.

The code in mopp.lisp will only work if lispwork does in fact define
all the symbols we need in the clos package, this was once the case
though things may have changed.

> I still have some problems understanding UCW. Mostly how the parts
> should play together. The relationship between application, component,
> sub-components etc is not clear to me. 

an application represents a program. [multiple programs can live
within the same server]. A component represent a piece of the user
interface (a window, a pane, a button, a label, a calendar,
etc.). Components are often (but not always and not neccessarixly)
combined (for example: the admin app has a window component which
"contains" a tabbed-pane component which "contains" other
components. one of these other components is the rerl component which
"contains" a form componet which "contains" other component).

i guess the question is: how does one component "contain" another? the
answer is that, generally, the container component will have slots
whose values are the contained components (or lists of components),
however ucw really doesn't care. the only thing whcih is usefull (but
even this can be ignored) is that a given component know who, on the
screen, its parent component is. if this relation is setup then the
method compute-url (and update-url) will work as you expect and action
urls are affected by the "closest" components.

> I do not understand what slime is used for, I guess it's to see the
> error messages. Is this a correct?

among other things, yes. slime is used as a generic portability layer,
it provides access to the debugger, the sockets and to locks on all
lisps. i assume that people already have slime installed so it was an
easy dependency to add.

> And well there is a thing I do  not like. The use of links for
> starting actions. I would think for that buttons are the "right"
> choice. Now I read someone has hacked around ucw:button? 

replace (<ucw:a :action ...) with (<ucw:button :action ...). 

NB: <ucw:button, unlike <ucw:a, must be wrapped in a <ucw:form tag.

> Would this someone explain what he has to done to implement that?

Alan Shutko wrote the <ucw:button code, look in
ucw/src/yaclml/ucw-tags.lisp. (it's very similar to the definiton of
<ucw:a). Basically the <ucw:button tag macro (like <ucw:input :type
"submit") expands into a small amout of javascript which registers the
action with ucw (using make-new-action) and puts the proper value in
the action parameter wihch will be sent back to the server.

-- 
-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