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 …
- 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.
- 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.
- XML Data Island Retain XML responses as “XML Data Islands”, nodes within the HTML DOM.
- Browser-Side XSLT Apply XSLT to convert XML Messages into XHTML.
- Browser-Side Templating Produce browser-side templates and call on a suitable browser-side framework to render them as HTML.
- 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.
- 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.
- 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.
- 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.)