This is off the cuff, and I'm likely to be missing subtle issues, but I believe permanent actions are still supported via def-permanent- action (or something similar). Since the handler executes in the session context, you can store a reference to the active widget (assuming only 1 such widget active per session) in the session table. If you pass a set of parameters to the handler function (embedded in your SVG file) that could then perform side effects on the widget reachable from the current session table.
If you want the SVG itself to change in response to a click via a server side response - you'll either need to run a javascript handler that interacts with it or ship out a new file (or generate a new file) in your response. I'm not sure this addresses all the issues, but hopefully it's a helpful scenario to think about. Ian On Jun 25, 2009, at 6:17 AM, nunb wrote: > >> a few hundered different links/actions in that case. I had hoped to > be able to >> generate a session-specific version of a destination-url like >> http://my-host/noticeclick?targetid=4711 > > If there are so many actions, then mux them into a muxer-fn and use > flags for the actions, eg > > onclick="mux(1);" > onclick="mux(2);" > > etc. > > Perhaps I don't understand your line of thinking, but I am at a loss > as to what /noticeclick?targetid=foo buys you. > > As Lelie said, this can easily be done with a custom url handler (note > that calling it will spit out the updated weblocks widget tree in the > output stream). > >> that I can call from an onclick="sendToServer(evt)" event, where >> sendToServer() is a JS method which calls to weblocks, weblocks does >> something with the > > If you want a static svg, put in onclick="myspecialfn()" where you > need some interaction, then > > (defmethod render-widget-body ((widget contains-svg) &rest args) > > (send-script (format nil "function my-special-fn (argv) { /* code > that populates args_hash_js = {key1:foo key2:bar}; */ ; ~A ; } " > (make-action-string-with-args > (lambda (&key key1 key2) > "lambda can access everything in > the current session, incl. the widget whose render-widget-body this is > in.") > :args "args_hash_js" )) > ;; any of these: > (with-html (:object (:xml ....))) > (slurp-bar-file "/pub/some.svg) > (template-file "/pub/some.svg" :var1 "foo") ) > > Depending on how complex you make my-special-fn you can embed all the > various action-options into it, similar to muxer-fn above. > >> information, and based on the result we might need to update a few >> attributes in the SVG too. > > afaik, this is impossible with a static svg, right? > > this is easy to do if your svg is embedded inside a render-widget-body > (even allowing for large static chunks of it to be pulled in through > templates/format strings etc). html-template is probably more > efficient than format. > >> The right thing(tm) would maybe be to have the SVG delivered >> dynamically, with a JS-variable >> containing the session-specific url destination for the above being >> templated in at that time. > > Absolutely. Especially if you want the SVG to change based on the > input. The rough-cut above addresses exactly this scenario, if I'm not > mistaken. > > I still don't get the need for "the session-specific url destination" > though :-P > >> However, >> I still don't see how to tweak that into Leslie's suggested >> hunchentoot-prefix handler. > > nope, still don't get it. perhaps you could restate the case for this? > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
