From burban at opopop.net Wed Mar 4 00:41:28 2009 From: burban at opopop.net (burban at opopop.net) Date: 04 Mar 2009 00:41:28 +0000 Subject: [Bese-devel] Follow up to "New tutorial typos" In-Reply-To: <8a4b88390902260121i72ca50fcj17cf43c2c2b3ea96@mail.gmail.com> References: <8a4b88390902260121i72ca50fcj17cf43c2c2b3ea96@mail.gmail.com> Message-ID: <87ab82jf0n.fsf@default.opopop.net> szergling writes: [...] > > Now, I am also confused about another thing. Suppose a component > displays an action that does not 'answer', but has side-effects > instead. I'm not sure why this action would repeatedly get called even > when the component display is only refreshed and not clicked on. > > Here is a simple example to illustrate: > > (defcomponent refresh-demo () > ((value :initform 0 > :accessor component-value))) Add slot option ":backtrack t" for value. Works also for the > (defmethod render ((c refresh-demo)) > (<:p "Current value is: " > (<:as-html (component-value c))) > ( "Increase value")) > > (defentry-point "refresh.ucw" (:application *example-application*) > () > (<:p "Refresh test") > (call 'refresh-demo)) > > > It is similar to the counter (increment/decrement) example. We have a > value which can be increased by clicking on our incf action. After the > first click on the hyperlink, I see a new incremented > value. Subsequent clicks on the hyperlink also increment the value, as > expected. However, clicking on "refresh" in my browser (after the > first increment action) also results in the value being incremented. I > expect to see the same value, since no action has been carried out, > really. > > I can sort of see why this must be so I guess, since there's some "URL > propagation-like" stuff, so even a refresh is a new "hit" causing an > action. However, this also works with form actions, and seems wrong, > since nothing has been posted... > > (defmethod render ((c refresh-demo)) > (<:p "Current value is: " > (<:as-html (component-value c))) > ( :action (incf (component-value c)) > (<:input :type "submit" :value "Increase value"))) > > Again, try to increment once (clicking on the form button), then just > use refresh. So what have I done wrong here? Would appreciate any > pointers. Well, time for a new chapter of the tutorial "backtracking":) -- B. Urban From senatorzergling at gmail.com Sun Mar 8 09:08:38 2009 From: senatorzergling at gmail.com (szergling) Date: Sun, 8 Mar 2009 22:08:38 +1300 Subject: [Bese-devel] Follow up to "New tutorial typos" In-Reply-To: <87ab82jf0n.fsf@default.opopop.net> References: <8a4b88390902260121i72ca50fcj17cf43c2c2b3ea96@mail.gmail.com> <87ab82jf0n.fsf@default.opopop.net> Message-ID: <8a4b88390903080108h1fbc6bcet3d96477e4ad91b8b@mail.gmail.com> On Wed, Mar 4, 2009 at 1:41 PM, wrote: > szergling writes: [...] >> Now, I am also confused about another thing. Suppose a component >> displays an action that does not 'answer', but has side-effects >> instead. I'm not sure why this action would repeatedly get called even >> when the component display is only refreshed and not clicked on. >> >> Here is a simple example to illustrate: >> >> (defcomponent refresh-demo () >> ((value :initform 0 >> :accessor component-value))) > > Add slot option ":backtrack t" for value. Ahh, that works now. And I was only trying to understand that myself with my frame & backtracking illustration (in the same post!). I thought I did try the :backtrack option, or perhaps it was :component, but that might have been too late in the night. > Well, time for a new chapter of the tutorial "backtracking":) How was my tree diagram for a start? Comes complete with a "gotcha"! :D Thanks for the heads up! From drewc at tech.coop Sun Mar 8 20:15:54 2009 From: drewc at tech.coop (Drew Crampsie) Date: Sun, 8 Mar 2009 13:15:54 -0700 Subject: [Bese-devel] Follow up to "New tutorial typos" In-Reply-To: <8a4b88390903080108h1fbc6bcet3d96477e4ad91b8b@mail.gmail.com> References: <8a4b88390902260121i72ca50fcj17cf43c2c2b3ea96@mail.gmail.com> <87ab82jf0n.fsf@default.opopop.net> <8a4b88390903080108h1fbc6bcet3d96477e4ad91b8b@mail.gmail.com> Message-ID: 2009/3/8 szergling : > On Wed, Mar 4, 2009 at 1:41 PM, ? wrote: >> szergling writes: > > [...] > >>> Now, I am also confused about another thing. Suppose a component >>> displays an action that does not 'answer', but has side-effects >>> instead. I'm not sure why this action would repeatedly get called even >>> when the component display is only refreshed and not clicked on. >>> >>> Here is a simple example to illustrate: >>> >>> (defcomponent refresh-demo () >>> ? ((value :initform 0 >>> ? ? ? ? ? :accessor component-value))) >> >> Add slot option ":backtrack t" for value. > > Ahh, that works now. And I was only trying to understand that myself > with my frame & backtracking illustration (in the same post!). I > thought I did try the :backtrack option, or perhaps it was :component, > but that might have been too late in the night. I have to note here that even with :backtracking T, the action itself is still again run. This always happens. Backtracking works by re-instating the value of any backtracked places before running the callbacks and actions again. The behavior, like everything else in UCW, is extensible (we've been talking about isolated frames as well, there are some good use cases). There is no way, without using HTTP, to distinguish between a link being clicked and a link being re-loaded. UCW offers 'action isolation', so that a particular action will only run once. UCW-AJAX offered 'invocation isolated', the would re-run the action if it was clicked again, but not if it was reloaded. This naturally requires javascript. I'd love to see someone port the ucw-ajax components to -core so we could play with this stuff. >> Well, time for a new chapter of the tutorial "backtracking":) > > How was my tree diagram for a start? Comes complete with a "gotcha"! :D I liked the tree diagram a lot! The actual tree structure will become more explicit in a later revision, as i'm adding parent->children and child->parent links to frames (via frame-ids) in order to support a frame garbage collector that has better heuristics than the queue we use now. Even without :backtracking the tree structure does accurately represent the various frames used. The nasty part is that the value displayed on the page when a user hits 'back' might not be the value stored somewhere in memory. Backtracking "solves" this problem, though i find in practice it's rarely needed .. 'back' is not always 'undo' in an application, and user expectations reflect this. backtracking, for me, has mostly been replaced with isolated actions, and callbacks and action that expect to be executed a number of times, and therefore know that any data they access might have 'changed in the future'. Regardless, the tree of frames diagram does accurately model a users 'path' through an application, and more importantly they are where we store the callbacks and actions that really drive UCW. When a particular UCW-generated URL is hit, the UCW dispatcher first extracts the session, then the frame is found in the session. Assuming it finds the frame (it may have expired), it reinstates the backtracks, it then looks up the name of any GET or POST variables in the CALLBACKS store, which lives in that particular frame. Any callbacks that are found are FUNCALLED with the value of the HTTP variable. Once all the callbacks have been called, it find the ACTION in the ACTIONS store and funcalls it. Once all that is done, a new frame is created, and the toplevel component is rendered withing the context of that new frame. UCW tags that create actions and callbacks are run during the render cycle, populating its action and callback stores, and the whole process begins again. At least that how it works by default. There are a number of excellent use cases for not creating new frames, different forms of isolation, etc etc, so all this is extremely extensible. >Apologies if this seems like a rant. I'm frustrated. You don't even >deserve this... it's not your fault. Actually, it might be, as i'm one of the Adminstrators at cl-net, and i control the domain and mail system... if you are losing mail that is my fault! :). Cheers, drewc > > Thanks for the heads up! > > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel > From erick at fsl.org.mx Sun Mar 15 00:20:43 2009 From: erick at fsl.org.mx (erick at fsl.org.mx) Date: Sat, 14 Mar 2009 19:20:43 -0500 (CDT) Subject: [Bese-devel] Getting started control flow example Message-ID: <56885.189.228.229.109.1237076443.squirrel@webmail.fsl.org.mx> Hello: I'm doing the examples in the getting started manual and I have troubles to make to work the control flow code. Attached is the code I'm using. The problem is I can't display the message. With the following code (defaction display-message (message) (unless (call 'example-control-flow-message :message message) (setf $message nil))) After submit alway got this: Hello ! Reset message With the message part missing. And if I modify display-message this way: (defaction display-message (message) (unless (call 'example-control-flow-message) (setf $message nil))) Without: :message message From burban at opopop.net Sat Mar 28 17:37:44 2009 From: burban at opopop.net (burban at opopop.net) Date: 28 Mar 2009 17:37:44 +0000 Subject: [Bese-devel] ucw-core demos and compatibility with old UCW In-Reply-To: <87hc1uvof6.fsf@default.opopop.net> Message-ID: <878wmp7dlj.fsf_-_@default.opopop.net> Hi, I have now a Web site running live ucw-core demos and manual examples. In addition, I found a way to allow running in the same Lisp instance old UCW and new ucw-core; this may help the transition. All info is here: http://lisp.opopop.net/web.ucw (section ucw-core) Hope this helps. -- B. Urban From drewc at tech.coop Sat Mar 28 18:04:07 2009 From: drewc at tech.coop (Drew Crampsie) Date: Sat, 28 Mar 2009 11:04:07 -0700 Subject: [Bese-devel] ucw-core demos and compatibility with old UCW In-Reply-To: <878wmp7dlj.fsf_-_@default.opopop.net> References: <87hc1uvof6.fsf@default.opopop.net> <878wmp7dlj.fsf_-_@default.opopop.net> Message-ID: Hey b. urban, ucw-core was designed to be able to run both the _dev and _ajax components. Your best bet is to simply port the _ajax component tree + supporting code to -core. At it's base, -core is almost identical to _ajax, so this should be trivial. I'd love to have support for the _ajax stuff back in the main tree if you (or anybody else) feels like doing the work. Cheers, drewc 2009/3/28 : > > Hi, > > I have now a Web site running live ucw-core demos and manual > examples. In addition, I found a way to allow running in the same Lisp > instance old UCW and new ucw-core; this may help the transition. > > All info is here: > http://lisp.opopop.net/web.ucw (section ucw-core) > > Hope this helps. > > -- > > B. Urban > > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel > From burban at opopop.net Sat Mar 28 21:29:34 2009 From: burban at opopop.net (burban at opopop.net) Date: 28 Mar 2009 21:29:34 +0000 Subject: [Bese-devel] ucw-core demos and compatibility with old UCW In-Reply-To: References: <87hc1uvof6.fsf@default.opopop.net> <878wmp7dlj.fsf_-_@default.opopop.net> Message-ID: <877i29nxoh.fsf@default.opopop.net> Drew Crampsie writes: > Hey b. urban, > > ucw-core was designed to be able to run both the _dev and _ajax > components. Your best bet is to simply port the _ajax component tree + > supporting code to -core. At it's base, -core is almost identical to > _ajax, so this should be trivial. I'd love to have support for the > _ajax stuff back in the main tree if you (or anybody else) feels like > doing the work. I really plan to look about this. From what I have seen so far, it may indeed be simple, but you never know what lurks around the next corner... Another point of interest for the "minimalist" UCW users, or people wanting to study the core, is that my modified ucw-core tarball: http://lisp.opopop.net/files/ucw-core-0.9bis.tgz is stripped down from all non used stuff of the original ucw-core. Regards. -- B. Urban From drewc at tech.coop Sat Mar 28 18:33:59 2009 From: drewc at tech.coop (Drew Crampsie) Date: Sat, 28 Mar 2009 11:33:59 -0700 Subject: [Bese-devel] ucw-core demos and compatibility with old UCW In-Reply-To: References: <87hc1uvof6.fsf@default.opopop.net> <878wmp7dlj.fsf_-_@default.opopop.net> Message-ID: Great page though, i really like it... would you be willing to help me put together a new UCW website? Cheers, drewc 2009/3/28 Drew Crampsie : > Hey b. urban, > > ?ucw-core was designed to be able to run both the _dev and _ajax > components. Your best bet is to simply port the _ajax component tree + > supporting code to -core. At it's base, -core is almost identical to > _ajax, so this should be trivial. I'd love to have support for the > _ajax stuff back in the main tree if you (or anybody else) feels like > doing the work. > > Cheers, > > drewc > > 2009/3/28 ?: >> >> Hi, >> >> I have now a Web site running live ucw-core demos and manual >> examples. In addition, I found a way to allow running in the same Lisp >> instance old UCW and new ucw-core; this may help the transition. >> >> All info is here: >> http://lisp.opopop.net/web.ucw (section ucw-core) >> >> Hope this helps. >> >> -- >> >> B. Urban >> >> _______________________________________________ >> bese-devel mailing list >> bese-devel at common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel >> >