[Mapbuilder-devel] Re: Some more cool AJAX patterns

[Michael M. <mi...@ma...>]

Cameron Shorter wrote:
> Mapbuilder people,
> I've starting a converstion with Michael Mahemoff from
> http://ajaxpatterns.org - who is developing useful AJAX design patterns
> that we can learn from and contribute to.
>
> As he points out, there are a number of AJAX frameworks in development.
>  It would be good if we could factor our AJAX logic out into one of
> these projects.
>
> Michael, comments inline.
>
> Michael Mahemoff wrote:
>
>> Cameron Shorter wrote:
>>
>>
>>> Hi,
>>> I'm working on http://mapbuider.sourceforge.net which is an AJAX based
>>> map viewer.
>>> With regards to AJAX, I think we are doing some cool stuff that I have
>>> not seen done elsewhere yet.
>>>
>>> 1. We have developed a Model/View/Controller design pattern inside the
>>> web client.  The model consists of an XML document which we load from
>>> a Web Service.
>>>
>>> The views are widgets represented by Javascript objects and XSLT.
>>> Between the two we use the browser's XSLT to build HTML snippets.
>>>
>>> When the model changes (by reloading from the server, or by user
>>> updates) an event is sent to all interested widgets, and the widgets
>>> repaint themselves using their XSLT.
>>>
>>> As you can imagine, this makes it very easy to extend an application
>>> by adding extra widgets or models.
>>
>>
>>
>>
>> Sounds slick. Since MVC can man so many things, I added a "Semantic
>> Events" pattern to explain it for now at least.
>
>
> Ok.  I'm not sure how the name links to the functionality, I think a
> Proxy pattern might be more appropriate.
> With regards to our server interaction, I think that we are going to
> rewrite our current design to use a Proxy pattern.  (We have a bit of a
> hack at the moment).

"Proxy" because the client-side model is a proxy for the server-side?
That's different to what I mean from semantic events, but probably a
second pattern we could add in.

>>
>>> --
>>> 2. We take this concept further by providing an XML configuration file
>>> which specifies the widgets/models to include in an application and
>>> our code is smart enough to only load the javascript code required.
>>
>>
>>
>> A question: I don't know enough about the framework, but I wonder if
>> there's a way to get this info without the declaration? I was going to
>> add a lazy javascript loading pattern, because I think DOJO does
>> something like that, so just thinking about where your framework fits
>> into that.
>
>
> I have had a quick look at DOJO and from what I can work out, a few
> differences between our projects are:
> 1. Mapbuilder is (almost) fully object oriented.  Ie, One javascript
> file for each javascript object.  DOJO seems to put many classes into
> one file.
> 2. Mapbuilder has implimented javascript inherience.  This means that if
>  we load a Widget class, we also need to load the WidgetBase class. This
> would probably be a design pattern for you.

Are you using Javascript's OO inheritance (extending the prototype),
etc.? WRT Javascript file inheritance, is this based on the config of
the objects? Could you say it's a form of pre-configured specification
of JS file dependencies?

> 3. We both seem to have implemented our own Javascript events.  As far
> as I can work out, javascript doesn't allow you to register for and send
> events from a standard object.  - Another design pattern?

Actually, I think this is something like what I meant by semantic events
- ie higher level events than just DHTML. And the corresponding
framework around propagating/registering/etc (you could break it down
into a few patterns, though I'd rather compartmentalise them all into
the one patterns since it's likely they'd all be used as a bundle).

>
> We have moved all our initialisation properties for each object into an
> XML file to make it easier to maintain and to centralise the loading
> into one place rather than have the HTML application including
> initialisation logic in the HTML.

Interesting. I created a pattern called "On-demand Javascript" to
capture all this JS-loading config.

>
>>
>>
>>> --
>>> If we won't so busy on our current mapbuilder goals, I'd like to
>>> factor out our framework into it's own library which can be used by
>>> other applications.
>>>
>>
>>
>> Have you seen the Ajax frameworks page? You might consider asking some
>> of the full-featured framework projects to pull in some of your
>> features. It sounds like they're
>>
>
> Thanks for the link, we should look at collaberating with these projects.
> Do you know if any of these projects are working together toward a
> common project?
>

I haven't heard of anything like that, I'd be very surprised if anything
like that was going on right now. My advice would be to contact each of
the leads and feel them out regarding how interested they'd be to take
on your generic components without constraining your own needs too much
- the idea should be to free up your time to work on map functionality
rather than chaining your project down. I think most of them will
porobably have their own one or two pet projects, maybe projects they're
migrating, so I think at least some of them would welcome an open-souce
project that will help to prove their architecture, and also serve to
demonstrate it.