February 2004 - ucw-devel@common-lisp.net

[ucw-devel] [ucw] 0.1.1
by Marco Baringer 12 Feb '04

12 Feb '04

i've put up a snapshot of ucw (with the latest versions of all the required libraries) as it is today, it's not 0.2 or anything but it'll at least let people play with some of the new features (hint hint hint). ftp://ftp.common-lisp.net/pub/project/ucw/ucw_0.1.1.tar.gz -- 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

1 0

[ucw-devel] [ucw] rfc: how to handle transactions
by Marco Baringer 09 Feb '04

09 Feb '04

christion queinnec (one very smart cookie) implements transactions with something along these lines: (let ((done-p nil)) (when done-p (call sorry-cant-do-this-more-than-once) (exit-from-let-body)) (call some-page) (setf done-p t)) basically the use of the lexical done-p ensures that the body of the let will only be executed once (due to the fact that done-p is a closed over variable which doesn't change values on subsequent returns from (call same-page)). i'd really love the implementation of transactions in ucw to be this simple, however unlike queinnec's model we can't be sure that the call to call will only show one page (in fact in his model CALL is actually SHOW-PAGE (or something similar)). anyway, what i'm wondering is this: if component FOO is in a transaction, and that transaction has already terminated, should we simply not allow FOO to return multiple times (as would happen with the above implementation) or should we do keep doing what ucw currently does and not allow any of the pages generated by FOO (or components called by FOO) to call actions? -- 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

1 0

[ucw-devel] [ucw] back to a past which doesn't exist anymore
by Marco Baringer 09 Feb '04

09 Feb '04

while playing around with transactions i ran into the following situation: suppose components A and B are called sequentially within a transaction. after the transaction terminates the user is taken to the "final" component (whatever that may be). now let's suppos the user returns to the page rendered by A and attempts to follow a link, at this point our transaction voodoo comes in and simply returns the user to the "final" component, and this is Good. however let's suppose the user then returns again but this time goes back to a page rendered by B and follows a link. Ascii art: t -> A [follow a link] B [follow a link] C [back button * 2] A [back button * 2] B [follow a link] ERROR Since the user followed a link on the A "page" (ie the output of the component A) the session stack was wiped from A onwards, hence we no longer have any reference the actions available from B and the server errors. This is not only a transaction issue, any time we go back to a componnet and then go back to a component which came after the component we went back to we'll run inte this inexistent action error. Having the session stack be a tree would solve this, but what would we gain? We could simply incode session + frame + action in a single value and put them in a application wide hash table, then we could update all the actions which a back action has elimintated, but this would mean that we'd need to look a basically global variable every time we get a request, which doesn't seem like a great idea either. so, i'm stumped. p.s. - does anybody follow ucw-devel(a)common-lisp.net from nntp? -- 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

1 0

[ucw-devel] session transactions
by Marco Baringer 07 Feb '04

07 Feb '04

we've got session transactions! have a look at examples/transaction.lisp in a upto the minute ucw (ucw--dev--0.1--patch-94). nested transaction need a bit more thought but basically the idea is this: you setup up a start and end session-frame, when you get past the end frame every action beteen the start and end is substituted with an action which just takes you to the final component. the request-response loop has been completly refactored, i've elimintated a bunch of special variables in favor of a single *context* special which is a request-contex object holding all the various "stuff" we need during a request-response iteration. in the process ucw has lost a lot of error handling code, a bunch of things which previously gave you a heplful page explaining what went wrong now just drop you into the debugger. anyway, if anybody wants to go stomp on ucw a bit i'd be happy to know where it breaks. (i've tested only on openmcl + aserve.) -- 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

1 0

[ucw-devel] status
by Marco Baringer 02 Feb '04

02 Feb '04

ucw development has slowed down a bit recently (to be precise it's moved to other sub projects). cl-icu is currently in a workable (even under cmucl!!) but un polished state. the next thing to do is create a yaclml and tal interface to icu (tags like <:current-time, <:current-date and <:currency-value which use the client's locale and icu to properly format the data). the cps transformer (the base of all the action vodoo) has undergone a major rewrite. it's now much more complete than it was before and much easier to read and modify and tramploines so that stack overflowing is no longer a problem. it can even transform and run itself (but don't try and read the output of that). as far as ucw itself: i'm currently refactoring the request<->response loop code trying to make it easier to understand and extend. to goal of this is to add action transactions, and should happen shortly. before that however the distinction between named actions and actions will be removed, we'll simply use a builtin function to handle actions, this will allow a lot more flexibility in where to send action requests to and greatly simplify the request response loop (basically we won't have any special cases). -- 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

1 0