[Bese-devel] UCW: random annoyances

[Marco Baringer]

Brian Downing <bdowning at lavos.net> writes:

> Hi.  I've recently been learning UCW by putting together a simple game
> (occasionally up at http://www.lavos.net:2501/triple-triad/index.ucw),
> and have been incredibly impressed.  However, I've noticed some things
> that I'm not quite sure about.  I'm using a recent checkout of ucw-dev.
>
> First, I initially tried to have an entry point other than "index.ucw",
> however all links seemed to be made to go to that unconditionally, so I
> couldn't click on anything.  Easily fixed, but I don't really want to
> have an index.ucw entry point if possible.

here's what _should_ happen:

link and form urls are calculated by the method compute-url (which
walks tho component tree (following parent links) and calling
update-url). The defalut implementation of compute-url simply calls
compute-url on the application object (the idea is that yau can
provide an application wide default url and customize it for
particular components). The implementation of compute-url for
standard-application objects simply usesr the query-path of the
current request object. [all of this so that hopefully the code is a
bit less confusing].

anyway, the point of this is that if your app has a single entry-paint
named foo.bar, and you never define your own compute-url or update-url
methods, all links _should_ be of the form foo.bar?s=...&f=...&a=...

This (new) compute-url logic was implemented in patch
ucw--dev--0.3--patch-368 (bug fixs to the change in patch-369 and
patch-370). The old logic had index.ucw hard coded.

so there are two possible issues: 1) your using an old version of ucw
2) the new ucw code is bugged. the former can be checked with a simple
tla logs and the later can be checked by seeing how compute-url is
implemented in ucw/src/rerl/standard-component/standard-component.lisp.

> The :COMPONENT and :BACKTRACK initargs to component classes don't seem
> to be changeable upon reevaluation on my platform (SBCL 0.9.0).  This is
> quite annoying while in development, as I have to unintern the class
> name and recompile the entire file, or, in the case of :BACKTRACK, quit
> and restart UCW entirely for some reason.  Is there a hard technical
> reason why this is the case, or is this a bug?

this i a bug (i've created an issue for it in the docs/issues/
directory). Basically I need to define a correct reinitialize-instance
method for standard-component-class objects.

> Finally, this component definition:
>
> (defcomponent triple-triad-window (simple-window-component)
>   ((body :component setup :accessor body :backtrack t))
>   (:default-initargs 
>    :title "Triple Triad"
>    :stylesheet "stylesheet.css"))
>
> fails with a "Slot BODY is unbound" error.  I assume this is because
> it's trying to backtrack it before it is populated with the component.
> Adding an :INITFORM NIL in there fixes it, but that seems quite
> non-intuitive next to the :COMPONENT initarg.  Would it make sense for
> the backtracking machinery to check whether the slot is bound before
> trying to save it?

i'm going to add a check which prohibits both :backtrack and
:component on the same slot. That said it would alsa make sense to
have the backtrack machinery check for slot-boundness.

> Given enough time I may try to fix some of these on my own, but for
> right now the code base is pretty confusing to me, and I figured I'd at
> least make them known.
>
> Finally, I just want to put this here, since this is just a ridiculously
> simple expression of something that would be hellish with traditional
> web programming:
>
> (<ucw:a :action (rotatef (deck (p1-picker app)) (deck (p2-picker app)))
>         "[<- swap ->]")
>
> Thanks for UCW!

my pleasure.

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