ucw-devel

ucw-devel@common-lisp.net

18 discussions

[ucw-devel] Auto-nag: ucw link verifier failed
by root＠common-lisp.net 18 Jan '06

18 Jan '06

You are being nagged on because your project's name showed up in the nightly Checkbot run. Checkbot checks for broken links etc. This probably means that you are either pointing to a broken link or that someone is pointing to a broken link on your site. Or something else, it check's a bunch of stuff. Update your webpages or you shall be nagged again next week. To find out what's wrong with your webpages, please consult: http://common-lisp.net/checkbot/checkbot-common-lisp.net.html Any questions? You can reach the author of this cronjob at admin(a)common-lisp.net Thanks!

1 0

[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

Re: [ucw-devel] random questions
by Erik Enge 09 Dec '03

09 Dec '03

Marco Baringer <mb(a)bese.it> writes: > 1) what's a good default action for: > > a) we get a request with a "bad" session id > > b) we get a request with an in-existent action-id > > c) we get a request with an in-existent frame-id I'm unsure what you mean by the word "in-existent" not I'm going to assume you mean nonexistent. I would say signal a condition in all three cases and register default handlers for them in ucw in case the user does not. The default handlers could probably just return an error message of some sorts. > While we could just respond with some kind of error message i'd like > to offer the user some pollible ways to react, but what? does this > depend on whether it's a dev server or the production server? You mean the user as in the user who uses the webbrowser as opposed to the developer using ucw? Well, I'd say use the conditions and then it's up to the developer. > 2) since there are quite a few things which we want to handle > differently in a dev enviroment than in a production enviroment do we > want a global ucw:*debug-server* variable or a sub class of > application? I guess my knowledge of ucw is not up-to-speed yet as I'm not really sure what you are refering to. I'd say ucw should signal the same conditions irregardless and then let the developer decide what to do in which situations. > 3) mind if i kill ucw-devel(a)common-lisp.net and just do everything on > bese-devel(a)common-lisp.net? I don't mind. Erik.

2 1

[ucw-devel] random questions
by Marco Baringer 08 Dec '03

08 Dec '03

1) what's a good default action for: a) we get a request with a "bad" session id b) we get a request with an in-existent action-id c) we get a request with an in-existent frame-id While we could just respond with some kind of error message i'd like to offer the user some pollible ways to react, but what? does this depend on whether it's a dev server or the production server? 2) since there are quite a few things which we want to handle differently in a dev enviroment than in a production enviroment do we want a global ucw:*debug-server* variable or a sub class of application? (i'm leaning towards the latter as it would be a good test of how well the application api is defined) 3) mind if i kill ucw-devel(a)common-lisp.net and just do everything on bese-devel(a)common-lisp.net? -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

ucw-devel