Hi,

I like the idea of Ian, so I will try that first.

However, I'll answer some questions you raised just for the record
here:


On Jun 25, 3:17 pm, nunb <[email protected]> wrote:
> 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" ))

I assume that send-script will populate the Javascript namespace of
the target xhtml tree; since
I do not want to inline the SVG (portability issues with IE; if you
want check out info at wiki.svn.org) the SVG javascript namespace is
separate, so the function will not be visible to the SVG.


> > 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?

In a static SVG file you can have JS code that handles events and
modifies the DOM tree of the SVG,
with automatic redraw by the browser. The SVG file delivered to the
client is 'static' to the server,
but the SVG DOM tree is dynamic in the client. This is exactly where I
want to get some synchronization
to the server in.

> 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.

Yes, it would all be easy if the SVG is a subtree of the XHTML DOM
tree in the browser.


> I still don't get the need for "the session-specific url destination"
> though :-P

This was my error: apparently I automatically get a reference through
hunchentoot:*session* in any sensible handler. Just like allegroserve
used to provide :) Maybe this is not MVC-compliant but is what I was
looking for. I'll store the interesting widget's CLOS instance in a
session variable and that will suffice.


Utz

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to