cells-devel

cells-devel@common-lisp.net

567 discussions

[cells-devel] Research has revealed!
by Frieda 13 Apr '08

13 Apr '08

Recent discoveries in herbal science have shed new light on the subject of penis enlargement. Research has revealed that your penis has the ability to grow beyond its current size when fully erect. Like all the other muscles in your body, your penis is actually designed to grow! http://www.qunebtoh.com/

1 0

[cells-devel] baby steps
by Ken Tilton 13 Apr '08

13 Apr '08

The attached works a tiny little bit. Running hunch, starting the server with the snippet at the top of example.lisp, running (reload), and then navigating to 8000/apropos I see three symbols matching the initial value of "md-slot-v". Deleting the "v" and then tabbing I see eight values matching "md-slot-". This required especially telling the handler creater not to expect "/apropos" as the prefix to subsequent messages (in fact ( i just defaulted if the name did not match apropos. Oh, you will also see hijinx where I store nodes by name as well as by ID, because I got back (("term" . "md-slot-")...) not (("i1234" . etc)) even though I see openair.js returns the id. Go figger. Oh. I may have really screwed up. At one point it seemed only the changed field (the search term) was being sent, suddenly I see the "pkg" as well, perhaps meaning there is no need to keep a copy of the client-side-data as you will see I am maintaining. Obviously I have no idea what is going on, perhaps I am seeing "pkg" only as a fluke behavior of pop-up menus (maybe if they are uninitialized they choose the first value and then that looks like a change to be transmitted?) I am clueless. If browsers always send all non-nil attributes with every request (a) that sounds like a waste and (b) we can lose the client-side-data hash table. Hopefully (a) is not the case (and anyway I thought /we/ were deciding what to send...hmmm, I am starting to like my theory about pop-up menus). whew! learning curves are exhausting, but fun. This seems to be working. I would love to feature this at eclm 2008 beacuse it shows how Cells interconnect values, how Cells facilitate the driving of an alien framework by a Lisp framework, and finally because it is Web 2.0, something folks might actually be interested in. Hang on. I just edited in some "<-kt" prefixed comments, and am attaching again example.lisp. I decided to retest and, whoa, a problem resurfaced: the whole thing simply stops working. I got stuck on this earlier and was just recompiling here and there with new debug statements and it started working again. That suggests, btw, that there is a defparameter or something that gets reset by the file being recompiled and reloaded (but I tried a full recompile and that did not help). Anyway, I am sure it is something stupid, and it is too late for me to stare at. kt ;; -*- mode: Lisp; Syntax: Common-Lisp; Package: cells; -*- #| Hunchncells -- Cells, Parenscript, and HTML Copyright (C) 2008 by Andy Chambers This library is free software; you can redistribute it and/or modify it under the terms of the Lisp Lesser GNU Public License (http://opensource.franz.com/preamble.html), known as the LLGPL. This library is distributed WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the Lisp Lesser GNU Public License for more details. |# ;; from Ken Tilton <kennytilton(a)optonline.net> ;; to achambers.home(a)gmail.com (Yes, this is you.) Learn more, ;; date Thu, Apr 3, 2008 at 3:15 PM ;; subject Re: [cells-devel] undersold aspect of cells ;; ;; A an interactive Lisp apropos is a good idea. The ACL gui version does ;; not search as the user types, but for fun we could do that, perhaps ;; doing it both ways to show before/after live during the talk. The ACL ;; dialogue has a checkbox for "exported only" and a pop-up menu of known ;; packages to choose-from to limit search to one package. A checkbox ;; next to it says "All" and means ignore whatever might be selected ;; (most UIs have a top item that says "All". anyway...). Then there is a ;; radio group of four buttons that also imits search to functions, ;; classes, variables, or all. Results are displayed in a scrolling list ;; with seven columns: name, package, function, setf, var, class, and ;; exported. Several of those are just booleans with an "x" showing if, ;; eg, the symbol has a function, a setter, a class, or is exported. The ;; var column shows var or con if it is a constant. The columns are ;; resizeable (bit of a frill). ;; Oh, and the input field is also a pop-up of the query history (which ;; would not make sense if each keystroke was treated as a new query. ACL ;; has a "search" button instead. Otherwise, the results pane is rebuilt ;; as the other filters are changed--the user does not have to hit Search ;; each time. ;; Anyway, I would be tempted to reinvent that as far as widget sets ;; allow: checkbox, radio button/group, the straight "search" button, ;; popup menus, and a multi-column scrolling grid view, input of course, ;; and then any decorative frames, say, to group the radio buttons. ;; Bonus points for a double-click taking them to the CLHS. :) ;; ;; (in-package :openair) (progn (declaim (optimize (debug 3) (speed 0) (safety 1) (compilation-speed 0)))) #+test (progn (when (and (boundp '*oa*) *oa*) (trc "stopping" *oa*) (hunchentoot:stop-server *oa*) (setf *oa* nil))) #+ughh (setf (log-file) "hunch.txt") (defparameter *oa* nil) #+test (let ((x (start-server :port 8000 :dispatch-table *dispatch-table*))) (setf *oa* x) (setf (log-file) "hunch.txt") ;; <-kt accomplished nothing (trc "got server" x) ;(hunchentoot:stop-server x) (describe x)) (defun reload () (cells-reset) (reset-sessions) (setf *catch-errors-p* nil *dispatch-table* (list ; (test-page "/check-test" 'web-checkbox) (test-page "/apropos" 'web-apropos) (create-folder-dispatcher-and-handler "/js/" "/mainline/js/")))) (defmd web-checkbox (page) (status (c? (param? "STATUS"))) (kids (c? (the-kids (mk-div () (mk-form (:action "get") (mk-checkbox "Status: " status) (mk-div () (mk-text (status (u^ web-checkbox)))))))))) (defmd web-apropos (page) (title "Lisp Apropos") (style "style.css") ;; <-kt all attributes moved into value slots of corresponding nodes (kids (c? (trc "page kids rule entry!!!!!!!!" self .cause) (the-kids (mk-div () (mk-form (:action "get") (mk-label (:for "term") "Apropos: ") (mk-input (:md-name :term :name :term :value (c-in "md-slot-v"))) ;; <-kt start somewhere for easier testing (mk-checkbox "Exported: " exported-only-p) (mk-label (:for "pkg") "Package: ") (mk-select (:md-name :pkg :name "pkg" :id "pkg") ;; <-kt was there an extra (list... here? Not needed (loop for pkg in (subseq (list-all-packages) 0 10) collect (let ((pkg pkg)) (mk-option () (mk-text (package-name pkg)))))) (mk-text (c? (if (fm^v :pkg) "on" "all"))) (mk-div (:id :result) (mk-ul () (loop for match in (bwhen (search (fm^v :term)) (let ((a (apropos-list search nil ;; (fm^v :pkg) <-kt- this started sneaking in, I punted (fm^v 'exported-only-p)))) (trc "got match count" (length a) search (fm^v :pkg) (fm^v 'exported-only-p)) (subseq a 0 (min 10 (length a))))) ;; <-kt- just making debugging manageable do (trc "piling up match" (^id) match) collect (let ((match match)) (mk-li () (mk-text match)))))))))))) (defun test-web-apropos () (cells-reset) (reload) #+nah (let ((app (mk-web-app (:prefix "testwa" :request (c-in nil)) (make-instance 'web-apropos :fm-parent *parent*)))) (declare (ignorable app)) (inspect app))) (defun test-request (self &rest req) (trc "test req" req) (describe req) (setf (request self) req) (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))) do (trc "bingo changed" h (id h)) (trc "new xhtml" xh) finally (setf (updates self) nil))) (defvar *web-app* nil) (defun test-page (path resource-class) (lambda (request) (trc "bingo request!!!!" request path resource-class) (start-session) (let ((root (or (session-value 'root) (progn (print "creating new web-app...") (mk-web-app (:prefix path :request (c-in request)) (make-instance resource-class :fm-parent *parent*)))))) (setf *web-app* root) (setf (session-value 'root) root) (assert (null (updates root))) ;; <-kt stumped at one point, then the issue just went away (setf (request root) request) (handler root))))

1 0

[cells-devel] Re: [cells-gtk-devel] Re: Anything new for me to show off at ECLM 2008?
by Ken Tilton 12 Apr '08

12 Apr '08

Peter Hildebrandt wrote: > Well, there's something wrong with the cells cvs again, so it would > not let me commit my latest changes. You can grab the latest version > here: > > http://www.washbear-network.de/fritz/pub/cells-gtk3.zip Hmmm, a little trouble there. PicoZip on WinXP cannot read it, WinZip on Vista (my new laptop for the eclm talk) complains but then seems to open it. The complaint looks like winzip just is not handling Vista. Maybe just tar.gz it? I appreciate the trouble you took making a zip, btw. Question 2: the above does not include a Cells directory (unless the expansion broke). I will be trying to build it (looks like I have to hack the ACL .lpr files for a while) in the meantime. > > My suggestions: > > (1) Cairo Drawing Area > > I have the cairo drawing area thing working by now and put in a simple > example (creates boxes and circles and random positions, then they > react on mouse over, can be selected, dragged around, and you can use > a select box (like in windows explorer) to select and move many shapes > at once). I finally took the time and get the kids slot to work > properly, so you can have ruled kids slots on your drawing primitives > and have cells create other shapes for you (say, you want to draw a > sun -- then you start with a yellow filled circle and have a kids rule > creating some lines for the rays. The number of rays may depend on a > widget (and so can the length), and you have a "declarative drawing"). Isn't that fun? I remember when we made kids a Cell (almost immediately). I was sure the wheels would fall off. It Just Worked(tm) and I started to suspect Cells would scale pretty well. > > (2) Tree View > >>From the stuff present in the demo I personally like the tree view > example, since it lets you explore the actual object hierarchy of the > demo. I don't even know whethe something like this could be done in C > at all. Omigod! I did an inspector at one point and used it to inspect the inspector window itself. Then I navigated down to the actual widgets in view and watched as the inspector showed things like the mouse-over state dynamically (without asking the inspector to refresh). I seem to recall adding some Cells internals to make it work, tho. In this screenshot: http://www.tilton-technology.com/cloucell.jpg ...the widget being inspected is the four-widget row just above "Class: Ixrow". > > (3) Cells Tree View > > Works like a charm -- as long as you don't delete stuff from the > observed structure (I ran into a conceptual problem with cells3 here, > gonna ask you on the cells list when I have the time to deal with > that). Anyway, I deactivated the delete button, and the rest is still > pretty nice. I look forward to the IR, maybe you have run into something I want to add to Cells to better handle things going away (a frequent problem). In my latest app I am running into a lot of problems with what is generally called referential integrity, specifically external references to kids that have been not-to-be'd. eg, my window's keep a reference to the "focus", which might be in a math problem the student decides to delete. uh-oh. Sprinkling (setf (focus w) nil) all over the place broke down when it ended up erasing a new value that had been set by code that tried to handle the problem by, say, moving the focus to the next problem when deleting the current problem. Man, imperative programming sucks. :) > > (4) Threading > > It is relly nice and lispy to use the repl to change properties of the > windows currently displayed and to add and remove widgets > interactively (especially if you have a background in C) -- but I > don't know whether that works in MS Windows. Just checked, > bordeaux-threads on windows does not support Allegro. Bummer. I will be doing repl stuff during my talk -- ACL runs a separate process from the IDE to execute Lisp. We just need to have a breather in the event loop handling to give the IDE enough cycles to be responsive. > > (5) MAYBE: cells-ode + open gl > > That'd be really neat -- if I figure out the opengl drawing area and > port my current physics simulator code to cells-ode as a backend plus > gtk-gl as a front end. They say there's a weekend coming up, so stay > tuned. OK, don't make yourself crazy on my account. In fact, I already have Cells-gtk as I had it last running on my laptop, I might just leave it at that. I am going to try to get to Celtk, Cello, TripleCells (lite integration with an RDF triple-store), Cells-Gtk, and OpenAIR (the cells/ajax bit andy is doing). Whew! cheers, ken

4 5

[cells-devel] Re: How do I do this in JS?
by Ken Tilton 12 Apr '08

12 Apr '08

Andy Chambers wrote: > On Fri, Apr 11, 2008 at 11:28 PM, Ken Tilton <kennytilton(a)optonline.net> wrote: > >>Instead of using gensyms to name (ID) interesting fields (not DIVs) I want >>to use their names, and do so as a path down from the page, so the id for >>the term input element would be, eg, "apropos.term" or "apropos/term". Then >>the Lisp-side tree of instances becomes its own dictionary (no need for >>mirroring slots on the page instance) and then we'll never have a problem >>with duplicates -- well, if we have a list of identical structures we'll get >>into a subscript as well, so how would I encode that? Suppose instead of >>just listing matches each match contained a checkbox to indicate (I don't >>know) show CLHS entry and then boom they hit enter and multiple entries >>appear. Well, they need the checkbox to have a path: >>apropos/match[42]/show-clhs. Is this where we do "apropos/match.42/clhs" as >>an ID? I guess I am asking what are the limitations on the id name >>characters. > > >>From the spec... > > ID and NAME tokens must begin with a letter ([A-Za-z]) and may be > followed by any number of letters, digits ([0-9]), hyphens ("-"), > underscores ("_"), colons (":"), and periods ("."). > > I hadn't actually noticed this before and assumed that anything would > be ok but went ahead and checked. > > However, this might not matter so much because you can do the thing > you want with jquery selectors and filters. Instead of a slash, you > use ">", and instead of [42], you use :nth-child(42) > > apropos/match[42]/show-clhs would then be > $("#apropos > #match :nth-child(42) > #show-clhs) Cool. Maybe I can leave this idea to you to implement? The idea would be to have a path slot on every node that for things which wold never change was nil and for anything else searched up to the first parent with a path and used that plus the symbol-name of its own :md-name which can be coded as a Lisp symbol such as 'term or :term (formatted into a JQ-acceptable selector as a string). One instance can reference another with (fm-other :term) or (fm^ :term) if the node is not a child (I can clean up all that whacky inter-model referencing syntax like fm-other and dm^), the only one who has to worry about the JQ names on the Lisp side is the bit that pipes things over to the browser and handles the (now) POSTs. I think widget values can be handled as usual in Cells apps: if it is an input field, just say c-in or c-input or c?n. We will only get POSTs from input fields, and Cells will allow those to be setf'ed when they come in. The page can have an equal hashtable to speed location of a CLOS instance given its JQ ID. An observer on the JQ path can stuff this dictionary, or just have the rule itself do it before returning the value: :jq-selector (c? (let ((n (symbol-name (md-name self))) (sa (jq-selector-above self)) (s (if sa (conc$ sa " > " sa) n)))) (setf (gethash s (jq-dict (u^ web-app))) self) s)) Something like that. > >> This may be easier than I thought! I was feeling the caffeine, now I am not. <g> Better you than me if you like where I am going with this. My one question is the same we had with cl-ode -- observers do not know which way a value is going. Observers now get passed the Cell (a very recent change) so we can use that: only ruled cells are headed outbound. I am just not sure that holds up -- what of we have an input Cell reserved for setting in reponse to things happening on the server? Well, we could say those still do not get propagated out to the browser -- those should be slots on the model, not widgets in the DOM. If we want a widget in the DOM to reflect that value (yes, this feels right) we just have a widget with a rule that says: (mk-text (c? (server-load (u^ web-app)))) Well, in that case I guess we would have a server instance as the parent of the web-app (remember when I said fm-top might not hold up?) but you get the idea. And even if this input=inbound, ruled=outbound breaks down we have the trick we are doing with cl-ode: simply flag the cell itself for direction. Hmmm, pardon the rambling, but we do have c?n slots. They run whenever something global changes to provide a default the user can override by typing, but meant to be re-defaulted if they go back and change this overarching other parameter. ie, I have changed the item selection so the size and color get re-defaulted, I am starting over. So this would be a two-way slot... it would mostly work except that the observer on xhtml will see a ruled /and/ input cell and not know if it should push it onto the updates. Hmmm. This is to be expected, we are once removed from the action. The first thing that pops into my head is a second dictionary, this time keying the jq selector to the value we know is over on the client side. The observer on xhtml can simply check that the new-value is not already on the client side. When we get posts, the first thing we do is record that that value is already on the client-side, before injecting the value into the Lisp model. Speaking of which, I guess inputs will come over one at a time as you have things set up, but if you think you'll ever get into bundling them up and sending over multiple inputs, we should apply another trick from cl-ode and control propagation (so multiple setf's look like one to the model). whew. I would gone back and edited all that but it may help for you to see my thought path (and maybe something in there sounds better to you than where I ended up). Man, you jumped in at the deep end, eh? :) kt ps. I CCed Peter H because he is the mover behind cl-ode and I thought he'd enjoy seeing the cross-pollenation. k

1 0

[cells-devel] [openair] Changes to get CSS styles working ...
by Frank Goenninger 11 Apr '08

11 Apr '08

Needed to make a small change in defmodel page: The lines with the :style got changed to: (:link :rel "stylesheet" :type "text/css" :href (^style)) Now CSS file loading works for me ... Cheers, Frank

1 0

[cells-devel] Re: Problem with request
by Ken Tilton 11 Apr '08

11 Apr '08

Ken Tilton wrote: > I made the change so the little indicator to the right of the package > pop-up says either "on" or "all" and that worked when I selected a > package. But then I clicked on exported-only and the tag reverted to > all. I had a lisp (describe request) in the processing stream and can > see why: > > #<HUNCHENTOOT::REQUEST @ #x21aa559a> is an instance of > #<STANDARD-CLASS HUNCHENTOOT::REQUEST>: > The following slots have :INSTANCE allocation: > HEADERS-IN ((:USER-AGENT > . "Mozilla/5.0 (Windows; U; Windows NT 5.1; > en-US) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13") > (:CACHE-CONTROL . "max-age=0") > (:X-REQUESTED-WITH . "XMLHttpRequest") > (:ACCEPT-LANGUAGE . "en-US") > (:ACCEPT-ENCODING . "gzip, deflate") > (:REFERER . "http://localhost:8000/apropos") > (:ACCEPT . "*/*") > (:COOKIE > . > "hunchentoot-session=3%3a0b9ec45ad30835f959590b891dc5ddee") > (:CONNECTION . "keep-alive") > (:HOST . "localhost:8000")) > METHOD :GET > URI "/apropos/EXPORTED-ONLY-P?EXPORTED-ONLY-P=on" > SERVER-PROTOCOL :HTTP/1.1 > CONTENT-STREAM #<FLEXI-STREAMS::FLEXI-BINARY-LATIN-1-IO-STREAM @ > #x219f7132> > COOKIES-IN (("hunchentoot-session" > . "3:0b9ec45ad30835f959590b891dc5ddee")) > GET-PARAMETERS (("EXPORTED-ONLY-P" . "on")) > POST-PARAMETERS NIL > SCRIPT-NAME "/apropos/EXPORTED-ONLY-P" > QUERY-STRING "EXPORTED-ONLY-P=on" > SESSION #<HUNCHENTOOT::SESSION @ #x21862422> > AUX-DATA NIL > RAW-POST-DATA NIL > > The get-parameters just shows the effected field. Is that something we > are doing? I would say we could change rules to say (or (param?...) > .cache), but I recall you said... well, that was attributes, nothing is > said if the attibute goes away or something. OK, I have been thinking. We like the granularity, so these get-parameters -- er, why aren't they post parameters? -- should not be treated as they are now as definitive of all the data, they just signify specific updates to the model. So I am thinking we take a different approach and simply loop over the values received and SETF the model slots, which should be c-in or c?n if they need to calculate an interesting initial value for a field based on other info. I will play with this. Meanwhile, I see a parameter on the server that says output-chunking is true -- in the request handler instead of bunging them all into a single string can we just write them one at a time to page and trust hunch to chunk them? kt

2 2

[cells-devel] OpenAIR: Doesn't work for me any more ...
by Frank Goenninger 11 Apr '08

11 Apr '08

Andy, I have tried to get this to work: --- BEGIN OF FILE --- (in-package #:openair) (defvar *web-app*) (defparameter *server* nil) (defun ht-monitor-page (path resource-class) (lambda (request) (start-session) (let ((root (or (session-value 'root) (mk-web-app (:prefix path :request (c-in request)) (make-instance resource-class :fm-parent *parent*))))) (setf *web-app* root) (setf (session-value 'root) root) (setf (request root) request) (handler root)))) (defmd ht-monitor (page) name ip-address term :title ":: HUNCHENTOOT MONITOR ::" :style "/css/ht-monitor.css" :name (c? (server-name *server*)) :ip-address (c_? (server-address *server*)) :term (c-in "") :kids (c? (the-kids (mk-div () (mk-text (c? (conc$ "Name: " (name (u^ ht-monitor))))) (mk-div () (mk-text (c? (conc$ "IP Address: " (ip-address (u^ ht- monitor))))))) (mk-form (:action "get") (mk-label (:for "i") (mk-text "Input: ")) (mk-input (:name "i" :id "i" :-type "text" :value (c? (reverse (term (u^ ht- monitor))))))) (mk-div () (mk-text (c? (conc$ "Reversed: " (reverse (term (u^ ht-monitor))))))) ))) (defun start-ht-monitor () (cells-reset) (reset-sessions) (setf *catch-errors-p* nil) (setf *print-circle* nil) (setf *dispatch-table* (list (ht-monitor-page "/ht-monitor" 'ht-monitor) (create-static-file-dispatcher-and-handler "/index.html" "/Users/frgo/projects/gt/app/ht-monitor/index.html") (create-folder-dispatcher-and-handler "/css/" "/Users/frgo/projects/gt/app/ht-monitor/css/") (create-folder-dispatcher-and-handler "/js/" "/opt/common-lisp/openair/js/"))) (when *server* (hunchentoot:stop-server *server*)) (setq *server* (hunchentoot:start-server :name "frgo's HT MONITOR" :port 4242 :dispatch-table *dispatch-table* ))) (export! start-ht-monitor) --- END OF FILE --- Symptoms: 1. No updates received from Web browser 2. When trying to update a slot on a page model I do not get any update of the Web page ... Is the git repo somehow in an "intermediate state" ? - I seem to remember you saying so in some email. Appreciate your feedback. Best, Frank

3 13

[cells-devel] [openair] redundant updates and mk-checkbox
by Andy Chambers 09 Apr '08

09 Apr '08

Hi Kenny, Just a quick note to mention various updates.... - reinstated the serverless test suite so that it works alongside hunch http://gitorious.org/projects/hunchncells/repos/mainline/commits/4c7bb90927 - added the mk-checkbox macro http://gitorious.org/projects/hunchncells/repos/mainline/commits/4a0795cb3 - prevention of redundant updates http://gitorious.org/projects/hunchncells/repos/mainline/commits/aa110dfe069 Cheers, Andy

2 2

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

← Newer
1
...
12
13
14
15
16
17
18
...
57
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel