Following from previous posts, here’s my notes from the third SAG (Uni. of Illinois CS Dept) workshop/discussion on the Ajax Patterns. See the initial post for a background on this series.

Note that there was a “2.5”th workshop on HTML Response, JSON Message, XML Message, etc - it happened, but there’s no audio, so I decided to skip it wrt the numbering (the present workshop is really Workshop 4).

 

Feb-20-2006 Third Ajax Patterns Discussion

============================================================
0:00

Use the "hidden version" versus the wiki
  [MM Guys, definitely the
  hidden version - the wiki more or less stopped a few months
  ago.]

Mention of O'Reilly Rough Cuts
  - Takes a while to make something ready, do you want to deny
    people the advantage of seeing it?

5:00 Intros
============================================================
5:30 Call Tracking

  [MM btw On the wiki, this was the first full pattern I wrote
  and it's pretty awful. Virtually rewrote it for the book. (The
  book content should eventually find its way back to the wiki,
  but maybe something more like the book format, with Wizlite for
  annotation.)]

XMLHttpRequest Call didn't address the bigger picture Call
tracking highlights the async nature of calls - several ways to
track it.  Hand-drawn, crude, diagrams.  
[MM These diags are mockups for the O'Reilly illustrators] Could
have global XHR object - but then limiting multi-processing Is
this pattern worried about resources or reliability?
  - More about
    [TODO Clarify it's about Call Tracking.] From the wiki
    version, seems like resources etc. Ambiguous.

11:00 When start thinking abt async communication, can think
about reflecting on the message. (??)

============================================================
12:00 Distributed Events

Fits quite well with Call Tracking
  [TODO Check Related Patterns sections, add refs?]

Single object/entity might have interdependencies

Clear that it's like an Ajax version of publish-subscribe
  - "Distributed" name confusing, "terrible".
  - Sounds like multiple servers (no).
  - Using patterns like Observer, a different name referring to
    the same thing.
  - But he's focusing on the fact that the events are
    distributed. ie in Java usually listeners are all in the same
    ?space.
  - Yeah it's kind of distr'd events, but the problem doesn't fit
    in with it.

Solution didn't seem to get into the details. Focus went back and
    forth between events and.
    [TODO Observer pattern sidebar]

Interesting, the problem is a really different context. There's
no vocab for that sort of thing, he's trying to create a
vocabulary for it with this pattern.
- Except that in MS case it's transparently distributed. Hook
  docs together, doesn't matter if docs are on same machine or
  not. Built into that (platform). Probably slower than JS.
  People have been building distr'd events systems for a long
  time. Interesting that it's become a big part of these JS
  systems.
- So maybe problem/forces should say more about the complexity of
  the communication

19:00 browser-to-browser is *not* distrib'd.
    [TODO Clarify that it's the same browser.]
  - Last line "should be clear ...": Using a generic interface
    rather than making a specific interface. Could have model
    object with a list of views. Instead, we say the model has a
    list of dependents
      - Well yes, it's another level of indirection, but could
        have implemented update as a list of views. But the main
        thing is, we have a generic interface - you don't know if
        the dependents are views and what they'll do with it. If
        you know they're views and you call redisplay(), you'll
        know they'll redisplay.
      - Had the same feeling - less about extra layer of
        intermediation and more about the fact it's generic.
      - [TODO Reword]
  - Examples: APIs where there's a central mediator. Java
    listeners don't have a central controller, every event
    listener has its own
    [TODO Decision - central manager versus Java-style autonomous
    where each object maintains its own listeners. (See below.)]
  - Decisions: History or state. cf Memento pattern
    [TODO Ref Mememto (or sidebar)]

Enjoyed this discussion. Issues about reflection or whether
interfaces are generic to the problem you're solving. As the
event mechanism becomes more complex, tend to genericise. The
event handling becomes the focus, the architectural locus of
these dist'd environments. Temptation to overload the event
mechanism - the idea of reflection comes in, interesting that we
don't have the vocab to talk about it.

Tradeoffs - "better solution" by adding a layer of indirection.
But that comes at a cost.

I think the heart of this pattern is "something changes,
      something then notified". Key is for Observer, should be
      named after what happened to the subject. If you have a
      system where you're calling your observers to go do
      something ... (different type of events). Events are always
      events relative to some subject, whereas if going to have
      some central repo with dictionary mapping subjects to
      listeners.  Actually a fairly minor issue, but seems bigger
      because not addressed.  As events get more complex, tend to
      centralise it
      [TODO Also depends on sophistication of inheritance and
      delegation mechannisms ... not so great in JS, which pushes
      toward centralising]

33:10 Observer mistakes: Forget to (un)register observer, forget
      to notify observer, forget to declare observer's handler.
      Some mistakes easier to catch than others, for me the ones
      that take longer are when I forgot to register it, esp if
      only in some certain conditions.  From HotDraw, learned it
      doesn't pay to try to be efficient. e.g. Drag figure around
      a screen - must redisplay, therefore must be real fast,
      therefore didn't use observer. So easy to make mistakes
      when mixing those mechanisms (observer and direct call).
      Became a lot easier when committed to using observer for
      everything.
      [TODO Mention this - tip:]

There's a lot you could say about it, not sure author wants to
      say it.  Good purpose: How to convert distr'd events into
      that style. Can see a lot of people doing it the stupid way
      - each display element asking the server if something's
        changed.
        [TODO Flag this risk, probly in Decision about central
        management?]

Code example: Show picture (e.g. interaction diagram)
      [TODO Diagram]

============================================================
38:45 On-Demand Javascript

Just-In-Time JS Not convinced of author's motivation for this.
Would have to be huge amount of JS to worry about it - it's
nothing compared to an image. But I was excited about it for
other reasons, could have dynamic behaviour depending on the
user/context.
[TODO Mention how images are different, they load in parallel and
user can begin interacting beforehand. Can't say same about JS.]
[TODO Emphasise the "behaviour messages" idea as well.]

Need to give performance reasons, could do with an eg in 2-3
sentences Also useful for cross-domain.  "Conventionally best
practice has been to include JS unobtrusively"
[TODO Reword/elaborate if nec Maybe "best practice *is* ..."]

Should have a pattern for modularising your system
[TODO More background info on this, if not separate pattern.]

Near the end of the Solution Variant: Question - What does it
  mean to add new members to the DOM?
  [TODO Clarify ie that nothing will actually happen.] Javascript
  Response - Reword to "Behaviour Message"

Didn't feel that I knew how to do it. Got the big picture, but
not the details, even though lots of pointers. If author wants me
to implement it just by reading the pattern, needs more details.
  - But I never feel like I can do anything unless I try it.
    [TODO Check (the book version has updated this, check that).]

Interesting if browsers could do this automatically.  Cache JS.
[MM Caching addressed in latest book version.]

Question on debugging: What if run eval(js) - if you look at src
for the original page, it won't be there. How will you find those
definitions when you're in the browser? That could be a good
reason not to use it.
[TODO Discuss Venkmann-handling (should work ok).]

==============================================================================
55:30 XML Data Island

Have a group of data you want to do something with - bring the
XML in, display the table etc from that, and you still have the
data.

What's the motivation of having it in XML?
  - They do say that - "could have a custom data format" etc.

Interesting. Stick an entire chunk of XML, which is gibberish to
the HTML, but can still use it.

"Even without these browser-specific technologies ...", so the
author thinks XSLT goes along with XML Data Island.
  - Then you do get this agreed-upon standard for doing these
    transformations.
  - HTML has a schema.
      - Ah but there's this special XML tag. Best thing is for
        the browser to ignore it - they can all ignore it in a
        portable way. (Laughter.)
      - Some people here speak other languages - we're all used
        to hearing a language we don't understand and we all
        ignore it - common human reaction, and somehow our
        programming languages don't do it. Only thing that's
        advanced enough to ignore things it doesn't understand is
        HTML.
      - Ajax is defiantly utilitarian - unrelentingly ugly and
        people just plow ahead. One thing now is that org's like
        Google can pay people to plough through the ugliness -
        crud to deal with, browser dependencies

============================================================
1:05 This pattern answers why using XML. Ajax apps so dynamic,
talking to the server all the time.
      - With HTML, could convert on the server
        [TODO Why not server-side XSLT]
      - Mentions you can offload work
      - Don't want the GUI to be hard-coded into the server.
        Story is weather info - just has to tweak the XSLT -
        doesn't change the XML coming from the weather place.
        Your portal can display it different from anyone else.
      - Fits with web services
      - cf Stylesheets
        [TODO Good to have links to tutorials on XSLT. Chiliplop
        pattern language (?) Book on XML patterns, never
        finished. On website.]

============================================================
1:12:30 Browser-Side Templating

    Didn't see any templates I really liked, even though should
    be do-able.  Authors thinking it makes life easier for web
    developers, I don't know.
      - My guess is that it makes life easier ... because half of
        them are below average, below-average programmers like
        when you can cut-and-paste etc
        [MM Surprised it's seen as a cut-and-paste technique -
        really just a means of separating presentation from
        logic.]
      - With JSP etc, can still let a web designer work on the
        template
        [TODO Explain why - ie to keep the HTML dependence in the
        web tier]