cells-devel March 2008

cells-devel@common-lisp.net

7 participants
23 discussions

[cells-devel] 100% Safe To Take, With NO Side Effects.
by Candice 31 Mar '08

31 Mar '08

Men are going to stand up and clap their hands at these penis enlargement capsules. It has produced remarkable results that have never been seen before with NO negative side effects. These penis enlargement capsules offer women what they really want, more to play with! Those extra inches really do make the difference! http://yutoutye.com regards,

1 0

[cells-devel] html attributes
by Andy Chambers 31 Mar '08

31 Mar '08

Hi Kenny, As you may have noticed in the examples I put up earlier, each html has a number of allowed attributes. This mirrors quite closely the options you can set in tk. The macros I've defined so far actually provide a nice benefit (that doesn't seem to exist in any of the other html generation libraries) of validating your html. For example, if you tried to put a "fizzle" attribute on some element, you'd get an error whereas this would be perfectly acceptable in many other html generation libraries. I think that some of the Haskell ones do clever things with typing to achieve the same effect. The drawback, as far as I can see is that this pollutes the namespace by adding a whole bunch of methods that do essentially the same thing. If someone wanted to use this library, many useful names like "onclick", and "href" would be snapped up already. Is the solution just to make a short nickname, then people can just use the package qualified names for all the functions we export. Cheers, Andy

1 0

[cells-devel] open-air code
by Andy Chambers 29 Mar '08

29 Mar '08

Hi Kenny, Here's my attempt at pushing changes to an updates slot. Would you mind having a look to see if you can see why its not working? The stuff of interest is..... updates on the the web-app model xuid on the html model xhtml also on the html model What's happening is that when it comes to printing the updates slot (just before it would be sent down to an xhr), its populated with all nodes the first time around, then nothing thereafter. All the models are made using defmodel rather than defmd because that's what celtk did (presumably before defmd was invented). Once I've got the updates working, I'll try to change these to use defmd instead. The only non-cells dependencies are cl-who and hunchentoot both of which are asdf-installable but you may be able to see the problem without having to install these.

2 1

[cells-devel] observer design question
by Andy Chambers 28 Mar '08

28 Mar '08

My model consists of a family tree of objects all of which have an xhtml ruled cell. The client needs to be updated if the value of this slot has changed. However, a change in one would cascade up the tree so if we were logging these changes, and sending them down to the client, one of the things we send would be the entire document which is not what we want. How do I set up the observer to log the change only if it has not been accounted for already.

3 6

Re: [cells-devel] observer design question
by Andy Chambers 28 Mar '08

28 Mar '08

On Fri, Mar 28, 2008 at 3:46 PM, Ken Tilton <kennytilton(a)optonline.net> wrote: > Andy Chambers wrote: > > On Fri, Mar 28, 2008 at 3:15 PM, Ken Tilton <kennytilton(a)optonline.net> wrote: > > > >> > > >> > $("#my-id").html("Hello World"); > >> > > >> > Translated, that means find the html element with id "my-id" and set the html > >> > inside it to be "Hello World". If I can just keep track of all the > >> > little changes, I'll > >> > send a list of these commands to be eval'd on the client. > >> > >> Coolio. I am about to send something with the OpenGL version to help > >> with some ideas. > >> > >> Question: Can you feed #my-id to the browser and then reference it later > >> in a page send? Or must it originally arrive as part of a larger X/HTML > >> tree, only after which it can be referred to directly? > > > > > > If you mean "Do all id's have to be known up front?". > > No, I meant /can they be/ defined up front, or <gasp> even later in one > stream. ie, as long as all the pieces are in place (as identified by ID) > by the time the browser has to actually render we are good to go. Yes you can do this. As long as something has been "injected" into the DOM (whether as part of the original page load, or as a DOM manipulation, you can select it in a subsequent command. > btw, I gather we can have a path ID where each segment corresponds to a > node higher in the hierarchy? So I could specify /body/left-leg/sock and > /body/right-leg/sock and have the DOM wearing two different socks? Yup. Jquery supports that particular subset of xpath (although with a slightly different syntax).

1 0

Re: [cells-devel] observer design question
by Andy Chambers 28 Mar '08

28 Mar '08

Sorry. I keep on sending this stuff to Kenny rather than the list. I've gotta get into the habit of hitting "reply to all" instead of just "reply". On Fri, Mar 28, 2008 at 3:26 PM, Andy Chambers <achambers.home(a)googlemail.com> wrote: > On Fri, Mar 28, 2008 at 3:15 PM, Ken Tilton <kennytilton(a)optonline.net> wrote: > > > > > > $("#my-id").html("Hello World"); > > > > > > Translated, that means find the html element with id "my-id" and set the html > > > inside it to be "Hello World". If I can just keep track of all the > > > little changes, I'll > > > send a list of these commands to be eval'd on the client. > > > > Coolio. I am about to send something with the OpenGL version to help > > with some ideas. > > > > Question: Can you feed #my-id to the browser and then reference it later > > in a page send? Or must it originally arrive as part of a larger X/HTML > > tree, only after which it can be referred to directly? > > If you mean "Do all id's have to be known up front?". The answer is no. The > example above could be changed to > > $("#my-id").html("<p id=\"my-id2\">some more stuff</p>"); > > and now we have a new fully fledged node in the DOM with all the rights > and privileges of whatever was initially sent. >

1 0

[Fwd: Re: [cells-devel] observer design question]
by Ken Tilton 28 Mar '08

28 Mar '08

[ooops--for the list] -------- Original Message -------- Subject: Re: [cells-devel] observer design question Date: Fri, 28 Mar 2008 10:44:15 -0400 From: Ken Tilton <kennytilton(a)optonline.net> Organization: Theory Y Learning To: achambers.home(a)gmail.com References: <a70cc98c0803280617n161f774ek466efe371228d2bb(a)mail.gmail.com> <47ECF307.5000704(a)optonline.net> <a70cc98c0803280730t27003f4dgbf5bc8d2fc22dbf2(a)mail.gmail.com> Andy Chambers wrote: > On Fri, Mar 28, 2008 at 1:30 PM, Ken Tilton <kennytilton(a)optonline.net> wrote: > >>Andy Chambers wrote: >> > My model consists of a family tree of objects all of which have an >> > xhtml ruled cell. The client needs to >> > be updated if the value of this slot has changed. However, a change >> > in one would cascade up >> > the tree so if we were logging these changes, and sending them down to >> > the client, one of the >> > things we send would be the entire document which is not what we want. >> >> How did the entire document change (I mean in /precisely/ what way such >> that your app wanted to send the whole thing? > > > The xhtml rule (for an html div) looks almost like this (in the real > one there's a line to > put the attributes in too). > > (c? (with-output-to-string (s) > (with-html-output (s) > (:div > (str (apply #'concatenate 'string > (mapcar #'xhtml (^kids)))))))) > > So the value of it depends on its kids. If any of the kids change, > then the xhtml slot on the div object will also > change. If I was to put an observer on xhtml, it would fire all the > way up the tree from each leaf that changed > wouldn't it? Yes. This is cool, this is like OpenGL display lists which are like objects in that my parent does not need to be rebuilt on the OpenGL side just because I have changed, my parent display list just runs and when it calls me -- well, it is more like Lisp with changing a function defintition while the application is running, my new display instructions get executed. So what I am hearing between the lines is that the kid can change and push itself over to the DOM (if I have the jargon right) and the browser will Do the Right Thing in re getting everything rendered? Get back to me to confirm, meanwhile I will refresh on the sleight of hand I did to make display lists work. IIRC the trick will be to have each rule turn off dependency tracking, sample each kid to get them up to date, then turn dependency back on for the /assembly/ of the kids into the current xhtml result. kt

1 0

[cells-devel] cell dependancies
by Andy Chambers 27 Mar '08

27 Mar '08

I'm not sure whether I would actually need this but was wondering if user code can get a cell's dependancies? Maybe we could pass this information along to the javascript. I've been thinking about the caching thing I mentioned on c.l.l Caching is certainly possible in javascript. Even the browser's own caching system could be used if we use a REST based system although since we're aggregating events, this might not be so useful (lots of unique requests so less chance of a cache hit). The solution would be to send a list of requests, and in the response, include each request with its resulting updates. Add these to the cache and we should get more hits. -- Andy

2 1

Re: [cells-devel] family hierarchies
by Andy Chambers 27 Mar '08

27 Mar '08

On Wed, Mar 26, 2008 at 1:57 AM, Ken Tilton <kennytilton(a)optonline.net> wrote: > Andy, > > Food for thought: I just noticed a recent email from Peter Hildebrandt > who had likewise wished he had time to do what you are doing. Peter > struck me as very solid (as do you <g>). Sounds like things are going > well for you, so you might mention Hunchncells on cells-devel or even > c.l.lisp when you are ready for company, or we could just try Peter > and/or Edi Weitz directly. I thought I had but looking back, it does seem that some of these exchanges have been sent directly to you Kenny. Sorry about that, I didn't mean to exclude anyone. So for the list.... I've picked off some of the low-hanging fruit in an effort to make hunchentoot handlers cells-aware. Most of the code so far has just been doing the equivalent of deftk but creating "html" widgets instead of tk ones. http://gitorious.org/projects/hunchncells The way this will work I think is as follows:- (most of this is vaporware) 1) request comes in from hunchentoot 2) cells handler gets "root" family object from hunchentoot session (or creates a fresh one) 3) kick off the propagation by setf'ing the request slot on root 4) an initial response is created from the xhtml slot of the root ...user does something on the browser end... 5) make ajax call to updates service 6) the update handler feeds some new paramaters into the model 5) observers on .kids, and .value log changes into an updates slot on the root 6) the updates are sent back down to the client The updates would be a list of strings representing updates to the DOM. When it gets to the client, it is simply eval'd and hopefully, the page reflects the new state. Here's some other stuff I've been thinking about. 1) In celtk, it seems like pretty much all events are sent from tk to cells for handling by the widget-event-handle. I think that doing the same for javascript events would be too expensive. Perhaps we could classify events into those that need to be sent immediately, those that can be sent periodically (say every 5 seconds), and those that can be ignored. I think even this would be probably not be scalable but I don't work for google so I don't have to worry about that ;-). 2) How do we feed these javascript events into the model? This would probably be another handler on a different url that listens for events specified as ajax GETs like this... GET /events?event=change&id=I034&new=somevalue It feeds these onto an events slot on the model and returns the current value of the updates slot mentioned above to the client -- Andy

4 6

[cells-devel] .kids/.kid-slots
by Andy Chambers 27 Mar '08

27 Mar '08

Just a quick one, What's the reasoning behind naming these slots this way (instead of kids/kid-slots)? -- Andy

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel March 2008