Inline SVG

Okay, I’m currently ripsnort delighted to have found a solution to this problem of rendering SVG element dynamically. As in:

  1. My web apps receive some <svg>...<svg> from an Ajax call
  2. ???
  3. Super, there’s a drawing on the page!!!

What is the secret sauce in step 2?

After a merry frolic through the majority of the internets and a dozen prototypes, I finally found the answer. In essence, you just create an “object” element with type and data settings:

javascript

  1. var svgObject = document.createElement('object');
  2. svgObject.setAttribute('type', 'image/svg+xml');
  3. svgObject.setAttribute('data', 'data:image/svg+xml,'+ svgCode); // the "<svg>...</svg>" returned from Ajax call
  4. $("#reportSVGDiv").append(svgObject);

It works in Firefox, and the article explains how to get it working in IE too, which I don’t need just yet.

A few other things I learned and tried:

  • I initially, naievely, tried just adding the SVG via innerHTML. As Jeremy explained to me, this doesn’t work because the browser uses a different compiler for HTML compared to pure XHTML. (And TiddlyWiki, like most things on the web, is HTML.) Even with an <object> tag around it, it won’t just switch over.
  • The easiest way to do this is to use a .svg suffix (or probably set mime type to svg, but this is tiddlywiki and I’m working from file:// URLs, where it’s not possible to set mime type). But then you can’t embed it on the page – you’d have to point to it from an embed tag or object tag.
  • You can inline the SVG if you write “pure” xhtml, and for this, you have to give the file a .xhtml suffix. As in this example.
  • I tried the Inject HTML into an iframe technique. I was hoping that with the right XML declaration and HTML type, I could convince the iframe it was hosting XHTML. But no, I could not. I’m still interested to know if there’s any way I could convince a dynamically generated iframe, with dynamic content, about the type of content it contains.

This is all part of some recent prototyping on an exciting TiddlyWiki project involving rich text editing, among other things. In a later blog post, I’ll explain how we’ve used this SVG stuff to mash up an online chart drawing tool with TiddlyWiki. I’m currently packaging it into a plugin.

XML Descriptors, Be Gone!

Dion posted a story about Nokia’s new mobile widgets. This will be very cool if it’s as good as it sounds. However, what got me was the XML-based config – three separate files for config, skin, and widgets. The widget config:

  1. <widget name="Example widget" version="0.1">
  2.  
  3.   <info>
  4.     <creator>
  5.       <user>username</user>
  6.       <date>7.6.2006 12:00</date>
  7.     </creator>
  8.  
  9.   <!-- Configuration of servicehandlers which the widget needs to operate -->
  10.   <services>
  11.     <service type="syndication" id="feed1">
  12.       <reference from="feedurlrss" to="feedurl"/>
  13.     </service>
  14.   </services>

My comment here isn’t specifically about this project, because most APIs continue to use this convention. I don’t get why APIs continue to come out requiring complex EJB-style XML config, in three different files no less. Learn from Rails and Pico and use code for config.

The arguments for XML config are fundamentally flawed:

  • “Anyone can edit it, not just programmers”. And if you believe that, you’re still waiting for your manager to learn FORTRAN and COBOL, thus rendering programmers obsolete. Mwuhahah. Obselete, I’ll tells ya.
  • “It can be changed at runtime, no compilation required.” This might occasionally be useful if the app’s shipped off to another site, but that’s a slim minority – it will either be a hosted app which you can easily re-deploy after re-compiling (as with these widgets) or a desktop app which will hopefully offer a nice config UI rather than requiring the user to hack some XML files! We like to develop standards to serve the vast majority, not the slim minority.
  • “It’s neater.” In any modern language, you can easily develop an API that lets you perform configuration with a grammar resembling a domain-specific language. I don’t consider the above XML to be particularly neat, nor most EJB descriptors I’ve come across.
  • “It can be validated.” True, you can check the file’s grammar, but you can’t validate that a given attribute must be a class in your program, for instance. With code-based config, you can.

Ajax Programming Patterns – Podcast 3 of 4: “DOM Population” and “Code Generation and Reuse” Patterns

The third podcast in this series of Ajax Programming Patterns. The 29-minute podcast covers five patterns. As with the previous podcast, there is reason for concern about the audio quality herein. Firstly, three patterns on DOM population – taking server response data and displaying it or storing it in the DOM:

The second group of patterns (representing a different chapter in the Ajax Design Patterns book) are a couple of generic Javascript patterns to make the code more maintainable and portable:

Ajax Programming Patterns – Podcast 2 of 4: Browser-Server Dialogue Patterns

Continuing from the previous podcast (cough 12 weeks ago), more programming patterns. Unfortunately, this recording (and the next one) went pear-shaped. Sorry. I do, however, recommend them to those of you who’ve been wondering what an Ajax talk would have sounded like in crackly 1930s recording technology, and one in which the speaker has a severe cold. FYI The level was too low and it didn’t correct very well…maybe one day, I’ll re-record, but for now I’d prefer to just get them out there as they have been sitting in the libsyn archive for many weeks.

The 40-minute podcast covers the following patterns:

  • Call Tracking Accommodate busy user behaviour by allocating a new XMLHttpRequest object for each request. See Richard Schwartz’s blog entry.Note: Pending some rewrite to take into account request-locking etc.
  • Periodic Refresh The browser refreshs volatile information by periodically polling the server.
  • Submission Throttling Instead of submitting upon each Javascript event, retain the data in a local buffer and upload it periodically.
  • Explicit Submission Instead of submitting upon each Javascript event, require the user to explicitly request it, e.g. submit upon clicking a button.
  • Distributed Events Keep objects synchronised with an event mechanism.
  • Cross-Domain Proxy Allow the browser to communicate with other domains by server-based mediation.

Click to download the Podcast. You can also subscribe to the
feed if you want future podcasts automatically downloaded - check out the
podcast FAQ at http://podca.st.

This podcast covers six patterns on Browser-Server Dialogue: Call Tracking, Periodic Refresh, Submission Throttling, Explicit Submission, Distributed Events,

Thanks for your feedback since last time. Good, bad, or ugly, it’s all welcome – in the comments for this podcast or [email protected]

Ajax Programming Patterns – Podcast 1 of 4: Web Service Patterns

Whereupon a new podcast series begins …

As promised, a new series of Ajax pattern podcasts. This is the first of four podcasts on the Ajax programming patterns.

In this 73 minute podcast, we look at the seven patterns of web services as they relate to Ajax clients.

Click to download the Podcast. You can also subscribe to the
feed if you want future podcasts automatically downloaded - check out the
podcast FAQ at http://podca.st.

  • RPC Service Expose web services as Remote Procedural Calls (RPCs). (Note: In the book and wiki, REST appears before RPC.) (6:55)
  • RESTful Service Expose web services according to RESTful principles. (13:25 )
  • HTML Response Have the server generate HTML snippets to be displayed in the browser. (44:45)
  • Semantic Response Have the server respond with abstract, semantic, data. (49:00)
  • Plain-Text Message Pass simple messages between server and browser in plain-text format. (56:05)
  • XML Message Pass messages between server and browser in XML format. (57:20)
  • JSON Message Pass messages between server and browser in Javascript Object Notation (JSON) format. (59:55)

Thanks for your feedback since last time. Good, bad, or ugly, it’s all welcome – in the comments for this podcast or [email protected]

New Ajax Demos

Further to the previous post on new Ajax programming patterns, it’s also worth noting there’s a new bunch of corresponding online Ajax demos too. Being programming patterns, they tend to be “pure refactorings” rather than enhancements, thus the user experience is mostly the same – you have to look under the covers to see what’s changed. The demos are mentioned in individual patterns, but here’s a sampling:

  • The wiki has a bunch of timeout-related refactorings. These refactorings are user-visible. (They’re not actually part of the programming patterns, but they were recently added.)
  • 2 other wiki refactorings involve On-Demand Javascript . (No UI change.)
  • A JSON playground.
  • The Portal Drilldown Demo has been refactored to render with XSLT and browser templating tools. (No UI change.)
  • A couple of refactorings added to demonstrate REST (broken right now, probably due to a PHP config issue) and RPC on the Ajax Shop demo. (No UI change.)

As with all the demos, they’re tested on FF and IE6, please let me know if anything breaks.

18 New Ajax Programming Patterns

I’ve uploaded full text for 18 new Ajax patterns, completing a first-cut draft for all Programming Patterns content, which will be one part of the book. This section bridges the gap between the very basics of Ajax – XMLHttpRequest, DOM, etc – and the high-level stuff like widgets and visual effects. For instance, how do you do design the services accessed by XMLHttpRequest? Or how do you deal with a lots of Javascript? The focus here is on traditional tech concerns such as maintainability and understandability; and less about usability.

Breaking it down:

  • Web Services patterns are about overall browser-server architecture – what kinds of services and what kinds of messages? It’s relevant to the conversation of Jon Tiersen and others about what sort of responses are possible – XML, JS, HTML, JSON. It’s also relevant to another recent conversation, on [http://www.theserverside.com/news/thread.tss?thread_id=35979 Ajax and webservices], as it covers REST and RPC.

  • Browser-Server Dialogue covers a mixed bag of patterns about XMLHttpRequest handling and what you can do with it, such as loading JS on demand.

  • DOM Population is about transforming incoming XML into DOM content, e.g. XSLT.

  • Performance Optimisation covers a variety of performance patterns such as caching and pre-fetching.

  • Breakout (can you think of a better name) is about going beyond standard Ajax constraints, namely using a server-side mediator to access external domains and introducing a plugin to go where no Ajax app is allowed to go.

  • Code Generation and Reuse is strongly related to some of the emerging frameworks like Echo2 and SAJAX.

This is all early days, so any feedback on the structure, names, or content will be taken into account and acknowledged too (really!). OK, here’s the lot …

Programming Patterns

Web Services

  • RESTful Service Expose web services according to RESTful principles.
  • RPC Service Expose web services as Remote Procedural Calls (RPCs).
  • HTML Response Have the server generate HTML snippets to be displayed in the browser.
  • Semantic Response Have the server respond with abstract, semantic, data.
  • Plain-Text Message Pass simple messages between server and browser in plain-text format.
  • XML Message Pass messages between server and browser in XML format.
  • JSON Message Pass messages between server and browser in Javascript Object Notation (JSON) format.

Browser-Server Dialogue

  • Call Tracking Accommodate busy user behaviour by allocating a new XMLHtpRequest object for each request. See Richard Schwartz’s blog entry (http://smokey.rhs.com/web/blog/poweroftheschwartz.nsf/d6plinks/RSCZ-6CEQAR).Note: Pending some rewrite to take into account request-locking etc.
  • Distributed Events Keep objects synchronised with an event mechanism.
  • On-Demand Javascript Download Javascript as and when required, instead of downloading it all on page load.

DOM Population

Performance Optimisation

  • Fat Client Create a rich, browser-based, client by performing remote calls only when there is no way to achieve the same effect in the browser.
  • Browser-Side Cache Maintain a local cache of information.
  • Guesstimate Instead of grabbing real data from the server, make a guesstimate that’s good enough for most user’s needs.
  • Submission Throttling Instead of submitting upon each Javascript event, retain the data in a local buffer and upload it periodically.
  • Explicit Submission Instead of submitting upon each Javascript event, require the user to explicitly request it, e.g. submit upon clicking a button.
  • Multi-Stage Download Quickly download the page structure with a standard request, then populate it with further requests.
  • Predictive Fetch Anticipate likely user actions and pre-load the required data.

Breakout

  • Cross-Domain Mediator Allow the browser to communicate with other domains by server-based mediation.
  • Richer Plugin Make your application “more Ajax than Ajax” with a Richer Plugin.

Code Generation and Reuse

  • Ajax Stub Use an “Ajax Stub” framework which allows browser scripts to directly invoke server-side operations, without having to worry about the details of XMLHttpRequest and HTTP transfer.
  • Server-Side Code Generation Automatically generate HTML and Javascript from server-side code.
  • Cross-Browser Component Create cross-browser components, allowing programmers to reuse them without regard for browser compatibility.

Aside I was interviewed yesterday for a Japanese magazine about how I’m using the wiki. So maybe some people will be interested to know that I always write the patterns offline because I am more creative in Vim and also to avoid textarea hell. (So much for Writely, will anyone create Vimly, there’s gotta be more money it than cloning MS-Word online :-D). I also use the Mozex or ViewSourceWith extensions to make partial edits using Vim.

This time, I decided not to upload once or twice at a time; but instead all 18 at once. There’s serious overhead of introducing each new pattern to the wiki (from Vim, the sequence is: 2mins spell-check, 5-10mins markup massaging, 2 mins fixing the link and description on the homepage; sometimes exacerbated by server lag.) Uploading all at once at least allowed me to focus fully on the task and also made some aspects more efficient, particularly updating the homepage.)