April 2008 - cells-devel - mailman3.common-lisp.net

Re: [cells-devel] [openair] another redundant update
by Ken Tilton 08 Apr '08

08 Apr '08

Andy Chambers wrote: > On Tue, Apr 8, 2008 at 12:20 PM, Ken Tilton <kennytilton(a)optonline.net> wrote: > > >> ps. As long as we are discussing Cells or macrology or OpenAIR or Lisp I >>think we should spam this list until you are ready to start a project on >>c-l.net for OpenAIR. I am thinking you need more than git, you want mailing >>list services as well. Or can gitorious do that? Or could c-l.net do git? I >>might ask later, git looks like fun. > > > I wondered about that. Sorry to everyone who's on this list but not > interested openAIR. I think by the time the apropos demo is ready, > I'll start a c.l.net project. Until then, I'll prefix all my openair > questions with [openair] on the subject line so you can send them > straight to /dev/null if your not interested. Good idea. But this is a great thread for Cells -- folks subscribed are here only because I won't stop ranting about Cells on c.l.l. Meanwhile almost no one understands the point. Even Peter Seibel said he did not see the point. A project like OpenAIR is a practical application (Peter should understand "practical" <g>) and ideal because it shows Cells doing two things: the usual declarative dataflow between widgets and, two, driving a parallel framework, in this case web browsers. As for pure Cells afficionados, again, driving a hostile framework (I mean simply one that has a mind of its own so we have to adjust to its world view) will lead to some nice blackbelt Cells. eg, the way we used without-c-dependency to minimize output and then did further optimization in the observers was Good Stuff. Then noticing the flaw (grandparent-grandkid) and the ways of resolving it purely with Cells was more blackbeltery, tho with luck we can duck that with an XREF hack to imbue browsers with html object identity. Still, astute observers will get a kick out of how object identity (something any Lisper will honor and cherish) makes the excessive output problem go away (speaking of which, once you do that you can take out the without-c-dependency). kt

1 0

Re: [cells-devel] another redundant update
by Ken Tilton 08 Apr '08

08 Apr '08

Andy Chambers wrote: > On Tue, Apr 8, 2008 at 1:23 AM, Ken Tilton <kennytilton(a)optonline.net> wrote: > >> Here is what I did for the exported-only checkbox (untested): >> >> (defmacro mk-checkbox (label attribute &key top-args label-args input-args) >> `(mk-div (,@topargs) >> (mk-label (,@label-args :for ,(symbol-name attribute)) >> ,label) >> (mk-input (,@input-args >> :name ,(symbol-name attribute) :id ,(symbol-name attribute) >> :-type "checkbox" >> :checked (c? (,attribute (u^ page))) ; parameterize? >> :value (c? (,attribute (u^ page))))))) > > > Cool. I wasn't trying to get you to do all the work but admittedly I > don't think I'd have come up with something so neat straight away. > Something similar should work for radiobuttons too. No work, really. I just took your code and turned it into a template by swapping out anything that would vary from use to use, throwing in backquotes and commas here and there. The tricky part is a CLOS issue: I can never remember whether to splice in additional initargs before or after the ones the macro wants to auto-provide. As I mentioned a while ago, auto is good but complete control for the user is also good, so we want them to be able to override something like :-type. You might think a second reference overrides the first. Nope, it is ignored. But I always forget between occasions when I am doing this and end up doing (describe (make-instance 'xxx :aa 1 :aa 2)) after defining the appropriate class to remind myself. > > >> And then you can just do: >> >> (mk-checkbox "Exported Only" exported-only-p >> :top-args (:one 1 :two 2)) >> >> And to think they banned even a preprocessor from Java. :) >> >> Notes: >> 0. I mentioned first the idea of having a 'watched-parameter' slot on the >>checkbox. Above macrology lets me achieve even more succinctness without >>complicating the checkbox implementation which stays as minimal as possible. >>Who does not get macros?!!! :) >> >> 1. Observe that parameters for any node must be in their own list. >> >> 2. I added a common parent (an extra mk-div) but hopefully that is OK, >>seemes right anyway. If not, I have a work-around in mind, but macros only >>emit one form so it would take (probably) a "flatten" call ... hmmm, I >>suspect I am being daft: do these things end up going thru a the-kids form >>anyway, which would flatten any list so the outer mk-div could just be >>(list...)? Probably. > > > Extra grouping elements never do any harm and are sometimes required > for fancy CSS. All those rounded corner tricks you see in "Web 2.0" > require the contained elements to be wrapped in at least one div and > depending on the technique used, sometimes 2 or 3. Great. > > >> 3. Will the top always be a page? Perhaps that is another parameter. > > > Probably. I'll try to think of an occasion where that wouldn't be the case. Maybe on an ecommerce page there would be a lits of items and for each the user has to select "size" or "color"? So the parameter "size" is for some sub-node, not the page? > > >> 4. I started with an initial-value parameter then realized that is being >>set at the page level. Then I noticed both checked and value mirroring that. >>What I believe I have done (check Celtk) is have an intial-value slot whose >>observer sets the parameter of whatever node is being controlled (here the >>page). Actions on the checkbox likewise set the parameter of the controlled >>node. Then the checkbox value (as you have it) watches the parameter, but we >>at least author the parameter completely (including initialization) from the >>authoring of the checkbox. But I can see it going the other way, with the >>checkbox being, say, an optional interface to a page value that would >>possibly be maintained/originate elsewhere. Anyway, I am still curious about >>the checkbox/value redundancy. > > > Sorry. That bit wasn't working correctly in the full version anyway > so I need to check that more thoroughly. As I understand it, > > value: is the initial value for the control > checked: is a "boolean" attribute > > In html, the mere presence of boolean attributes says that they're > true. Madness! > I think cl-who is clever about this so if we set it to nil, the > xml rule should just remove checked entirely from the attribute list. > In traditional web apps, when a user clicks the "submit" button, the > notion of "successful" forms is introduced to identify which controls > should be sent. A checkbox is successful if it has been checked. > When its successful, its added on to the request as a (key, value). > The key is the checkbox's :name. The value is its value. On the > server, you can tell by the absence of exported-only-p that the > control is unchecked. The nice thing is that future generations will never have to see this unpleasantness, they will think OpenAIR is reality. > > With our fine-grained control of what we're sending back though, we > may as well just send back "on"/"off" values for our checkboxes (or > 0/1 whatever). We can update the value on the js side (in fact, we > can just ignore the value completely and just decide what to send back > based on the checked state). I shall leave this to you. :) Lemme know if you get stuck. kt ps. As long as we are discussing Cells or macrology or OpenAIR or Lisp I think we should spam this list until you are ready to start a project on c-l.net for OpenAIR. I am thinking you need more than git, you want mailing list services as well. Or can gitorious do that? Or could c-l.net do git? I might ask later, git looks like fun. k

1 1

[cells-devel] another redundant update
by Andy Chambers 08 Apr '08

08 Apr '08

Hi, This was mentioned a while ago and is causing a problem now. When an ajax request comes in, one of the things that gets updated is the input value. For example... old: <input name="term" value=""/> ...user types in "progv" and hits TAB new: <input name="term" value="progv"/> We want the model on the server to update itself to reflect this change but we don't need to send it down to the browser because the browser already knows. The problem this is causing (and this is something we'll need to take a mental note of for the future) is that the event binding for the input element is lost when that element is replaced. That means any actions after the first don't trigger an ajax request. We could rebind the event on the new element but I think its better not to send it in the first place. I think this would apply to all UI elements so if that's the case, the solution is probably to filter updates containing these elements the same way that ascendant and redundant nodes get filtered in the code below. (let ((updt (loop for (h . xh) in (updates self) unless (loop for (h2 . nil) in (updates self) thereis (unless (eq h h2) (when (fm-ascendant-p h2 h) (trc nil "suppressing redundant" h :seeing-ascendant h2 (id h2)) t))) collect xh))) I've pushed a new version out to the repo but haven't dealt with this problem yet. Another thing you might notice if you look at commented out code in the example is that the radio button at the bottom seems a bit verbose. Radiobuttons could probably do with a layer on top providing a nicer way of creating them. At the moment, user code has to create labels, manage the checked/unchecked status, and the value for each input. It should provide something like celtk's mk-radio -- Andy

2 3

[cells-devel] (no subject)
by andy 06 Apr '08

06 Apr '08

Subject: Re: [cells-devel] Booyah!! openair off the ground In-Reply-To: <47F91574.8040608(a)optonline.net> References: <a70cc98c0804050550x796539cduef259247e875ab42(a)mail.gmail.com> <47F7C616.6010004(a)optonline.net> <47F7E848.2070504(a)optonline.net> <18424.63017.660090.684646(a)martin.lyndoch.net> <47F91574.8040608(a)optonline.net> X-Mailer: VM 8.0.9 under Emacs 22.1.1 (i486-pc-linux-gnu) Ken Tilton writes: > andy wrote: > > > >> I just wanted to see it working before reading up on aserve's > > > >> webobjects and adding support for them so kenny can see this in > > > >> action. > > > > > > > > > > > > OK, so I should wait? > > > > Yeah. I'm working on that now so I'll let you know later this > > goes. Mmm. Not going too well here. webactions seems to require something called :sock that doesn't appear anywhere on cliki.net. Does this come pre-installed with allegro? > Cool. I am working on Cells.js. :) > > How about xref, or just ref. > > Awesome. I kept thinking "xref" but I kept worrying about a clash, altho > I think it was href I remembered. > > It is so much fun doing this without a clue on the domain (and the more > I look at it the less I feel bad about having missed all this <g>). > > > I don't think the name matters really > > much since xml has namespaces to avoid collisions. We just put it in > > the http://openair.net/ (or whatever) namespace. > > Ah, snazzy. > > > > > I'm going to read through the previous stuff you've posted about > > lookups since I'm still not clear about how it would work. Here's my > > understanding at the minute. Does it sound ok? > > > > All the actual xml would have to be stored somewhere, presumably a > > javascript associative array. Then, whenever something is sent to the > > browser, we find all xlookup elements and replace them with their > > associated content. > > Yep. I am hoping that when you said the "x" was for extensible that this > will work. > > The crazy thing is that where browsers cache pages and images and other > things we are taking caching to a new (is it new?) level. google does a fair amount of clever stuff with javascript. I'm sure there must be some fairly advanced caching going on there. > I mentioned GC being a concern. Possibly we have a fallback mechanism if > we screw that up whereby xref can -- should something requested not be > found -- make one last try by asking the server. Of course I am hoping > the existing not-to-be mechanism will let us keep the client-side > dictionary (where xref looks, the js associative array) tidy, but a few > lines of code for a fallback might be smart. > > Or am I being silly about even needing GC? Well, if we are building RIAs > then we might well end up with users hanging out for a long time on the > same page -- that by the way is me guessing the dictionary will get > tossed when they leave a page. Getting ahead of myself as usual... I've heard of cases where it isn't. Not quite sure how that happens though. I think the GC is a good idea and it doesn't sound like it'll be that hard. > > > It occurs to me that this apropos example would benefit another way from > > > something like xlookup. Suppose can only guess a chunk of name that is > > > very common, so there are a lot of matches. That's OK, now they just > > > click various check boxes that limit the matching. But each time they > > > click on a selection criteria a round-trip is needed to ask Common Lisp > > > which symbols are, say, exported. Suppose a third are. > > > > > > Without xlookup, the xhtml for that one third must be resent. With > > > xlookup, the parent just resends itself listing so many terse little > > > xlookup tags. GC on the client side could be handled during "not-to-be" > > > processing. > > > > Just to make sure I'm not missing anything, is the comparison below > > what you consider the difference to be? > > > > <xlookup ref="s123"> > > > > Here's the equivalent > > > > <li id="l123"><span id="s123">progv</span></li> > > No, but I am guessing it's a typo, you meant to compare with (using the > burgeoining new name and throwing in another slash just to see if I am > learning anything): > > <xref ref="l123"/> You can now put XML on your resume :-) > ie, it's the line that does not need resending -- in general, we want to > go as high up as possible. In fact, technically that might be > (introducing a syntax for email discussions in which dictionary entries > are signified thus: > > l123 : <li id="l123"><xref ref="s123"/></li> > > ...with this as a separate entry: > > s123 : <span id="s123">progv</span> We don't even have to invent a new syntax. You can define javascript objects using a syntax almost exactly like that... var cache = { l123 : "<li id=\"l123\"><xref ref=\"s123\"/></li>" s123 : "<span id=\"s123\">progv</span>" }; then if we need to update it... cache["l123"] = "<li id=\"l123\"><xref ref=\"s124\"/></li>"; -- Andy

1 0

[cells-devel] Booyah!! openair off the ground
by Andy Chambers 06 Apr '08

06 Apr '08

So I put kenny's code into master and made it work with the hunchentoot server. I changed the example a little so that it only makes requests when focus is removed from the text box (hit tab or click somewhere else in the window). I just wanted to see it working before reading up on aserve's webobjects and adding support for them so kenny can see this in action. Admittedly, it does seem a little buggy. If the apropos-list is too large, it seems to hang the server (although refreshing the page and starting again is allowed because hunch just starts a new thread). To try it for yourself... If you haven't cloned the repo already... $ git clone git://gitorious.org/hunchncells/mainline.git openair ...otherwise update your repo $ git pull origin ...then after adusting your asdf locations accordingly... (require :openair) (start-server :port 8080) (reload) then point your browser to http://localhost:8080/apropos type something into the text box and hit Tab. -- Andy

3 4

[cells-devel] following progress
by Andy Chambers 05 Apr '08

05 Apr '08

Ken asked a while ago about being notified about commits. I asked about a commit mailing list on the gitorious message board. They told me I can follow an RSS feed for each branch. There was also some mutterings about making the post-commit-hook available in some way (this is just a script that git runs after commiting). Do you guys use rss? On a MAC, you can get it to show up in your email. -- Andy

1 0

[cells-devel] Openair: How to get a rule fired on every single change in the browser ?
by Frank Goenninger 05 Apr '08

05 Apr '08

Hi Andy, Kenny, in my apps I often rely on the fact that for every single keypress of the user I have a changed cell and therefore I get my dependencies updated on every single user action. Now ... I just don't see how I can achieve this with Openair (I am not a Javascript expert - not even a beginner ;-) Thanks for input ... Best, Frank

1 1

Re: [cells-devel] openair progress
by Ken Tilton 05 Apr '08

05 Apr '08

Andy Chambers wrote: > On Fri, Apr 4, 2008 at 10:48 PM, Ken Tilton <kennytilton(a)optonline.net> wrote: > > >> Lemme know when that is done and I will bravely try to update. The on-line > > > I'll send emails to cells-devel whenever I push to the repo. I've > also posted a feature request to the gitorious guy to add mailing list > support whenever a push is made so maybe some time in the future, > that'll happen automatically. > > >>git doc actually looks pretty good, but any tips on the following would >>help: >> >> picking up your latest version in toto >> committing anything I do so (a) it does not tromp on everything and (b) >>you can merge with it > > > picking up the latest version: > > git pull origin > > > In git, branches are really easy, so... > > git checkout -b kenny Very cool: mkdir openair cd openair git clone git://gitorious.org/hunchncells/mainline.git cd mainline git pull origin -> Already up-to-date. git checkout -b kenny -> Switched to a new branch "kenny" Cool. Now I do not see a new directory or anything, so I guess I just start whacking on the code in mainline? Hmmm... I guess it gets interesting after we both have made changes and I want to pick up your newest stuff... well, I guess I can just hack away and commit under the kenny branch and when /you/ decide to add anything I did to the mainline I can just start over with a fresh copy. We can cross these hairier bridges as needed. I get the feeling Linus has done it again and git is taking over. Should I move all my stuff to git do you think? And is this something common-lisp.net can do, or am I headed for gitorious? > > creates the kenny branch and checks it out. > > hack, hack, hack > > git commit -a -m "fixed some stuff" > > If you and Frank add yourself as users to gitorious, I'll add you both > as commiters to hunchncells. I have signed up as "kennytilton". thx for the tutorial! kt

1 0

Re: [cells-devel] openair progress
by Andy Chambers 04 Apr '08

04 Apr '08

On Fri, Apr 4, 2008 at 6:20 PM, Ken Tilton <kennytilton(a)optonline.net> wrote: Here's the latest source. I went back to making it work with hunchentoot becuase of the sessions thing. Is there a nice way to optionally depend on some library. The best I came up with was to put :use-hunch, or :use-aserve in *features* before loading and then have different defsystem forms for each case (like Edi does with cl-ppcre sort of). I suppose allegro users would probably always want to use aserve so maybe we'd just use #+allegro. So what's up with that loop gotcha. Is that because of we're collecting a macro form? I'll see if that's the problem. -- Andy

4 6

Re: [cells-devel] openair progress
by Andy Chambers 04 Apr '08

04 Apr '08

On 4 Apr 2008, at 19:56, Ken Tilton wrote: > Andy Chambers wrote: >> On Fri, Apr 4, 2008 at 6:20 PM, Ken Tilton >> <kennytilton(a)optonline.net> wrote: >> Here's the latest source. I went back to making it work with >> hunchentoot becuase >> of the sessions thing. > > Bummer. Remind me: this is because aserve does that differently, not > because it cannot handle them, right? At first I thought we'd have to implement the whole idea of sessions but someone pointed out yesterday that allegroserve has "webactions". I just wanted to see it working before I ported it to webactions. > > Yep. Some allegro users will want to develop portably and use > hunchentoot -- I do that for production work to avoid an ACL lock-in. But am I correct in thinking that real allegroserve has just the same interface as portable aserve (or at least a superset of features). > > >> So what's up with that loop gotcha. Is that because of we're >> collecting a macro >> form? > > No, it has to do with all closures capturing the same lexical which > gets rebound until the loop ends so at the end all closures see the > same value (the last). > > I have looked closer at how you minimize updates using the content- > rule to do your own change detection. I think I am going to have a > bunch of Ajax questions soon. :) > > Do you think there is any way we can implement my idea of a browser- > less test harness in which we just... hmmm, ideally we setf the REQ > slot with something valid. That's a good idea. Not sure about the best way to create the request objects but one way would be to just save them for later when they come from the browser. All we're interested in at the moment is the GET parameters so that approach should be fine. -- Andy

1 0