[Bese-devel] Re: action-dispatcher & defentry-point

[Marco Baringer]

Evrim ULU <evrim at core.gen.tr> writes:

> Hi,
>
> I've been reading request-dispatch code and saw a warning which reads:
>
> ;;;; ** ACTION-DISPATCHER
>
> ;;;; This is the core dispatcher for ucw. Due to how ucw's compute-url
> ;;;; method works it is important that the action-dispatcher be
> ;;;; checked before any url-dispatchers, so it sholud be the first
> ;;;; element in an application's dispatcher list.
>
> We've built a portal-base to register all applications to it like an app
> pool and implemented apache vhost/ucw/db start/stop/zap functions just
> like sysv initrc. Sometimes we need to override old entry-points via
> recalling defentry-point.  I've seen new defentry point removes the old
> entry point and appends it. Shouln't it do a prepend? I know it removes
> the same entry point having the same class and url string but it's
> possible to have an entry-point say, standart-entry-point overriden with
> a regexp-entry-point. In that case, defentry-point wouldn't be
> overriding the old entry -point and since  class'es are different,  and
> old entry -point will show since dispatcher will dispatch the first one
> it sees (i saw, returning t from dispatch yields end of service). In
> fact, i must admit, there hasn't got to be two entry-points having the
> same url string, so we may drop the class-name check and depend only on
> url string.

it does an append because a prepend would, in my situation, hide the
action-dispatcher. i hadn't really considered the situation where you
have a url dispatcher on "foo" and want to redefine it as a regexp
dispatcher on "f.*", nor do i really think the effort involved in
having that 'just work' would be worth the gain (i do think that there
are occasions where delete-package followed by asdf:load-op is the
best solution, and this looks like on of them).

my current problems with defentry-point are do liking this setup:

an action-dispatcher (which must be first on the dipatcher list), a
list of entry-points and finally a tal-dispatcher. i don't know how to
make defentry-point figure out what it should do in this case. nor do
i want to complicate standard-application with multiple slots for
different kinds of dispatchers.

one thing i have though about doing is adding a :priority keyword to
dispatchers. when adding a new dispatcher to an app we insert it after
all dispatchers with a higher priority. so, in my case, i could give
the action-dispatcher a priority of 0, the tal-dispatcher a priority
of most-negative-fixnum and do whatever looks best for the normal
entry-points. comemnts?

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