[okfn-help] IRC meeting log comments

Thu Sep 4 00:08:09 BST 2008

Hello all,

Sorry I missed the meeting this meeting. I got there, but only at 
9:30pm. Have read the log now:
http://okfn.org/wiki/meetings/2008-09-03

I can say firstly, that to go with the grain of OpenLayers, the map 
markers can probably be best resized by having a selection of images, 
and setting up the marker to use different images. I don't think you get 
the opportunity to set the image element size. But I'm only guessing, I 
couldn't even get the background shadow images to show up. :-)

I can also say that if anybody (ipe?!) wants to understand how we coded 
the Javascript in Microfacts, that this is the place to start:
http://knowledgeforge.net/microfacts/trac/browser/trunk/microfacts/public/behaviour/lib/moovc.js

It's a fairly classical (certainly incomplete) implementation of 
Model-View-Controller. We didn't just write that lot out, but arrived at 
it by refactoring. First, we made a spike solution for the "thread read" 
page. Then we refactored that into moovc (we're using mootools...) and 
then applied it elsewhere. The second and third pages were the 
geo-chrono page and the thread edit page. For the geo-chrono page, the 
Simile and OpenLayers code was encapsulated by view controllers, and 
then a page controller was written to direct them. The important point 
is the direction of travel, or the style of conception, which is far 
from (some) ideal.

Look next at a page controller, e.g. the map+timeline page controller, 
which derives from the base controller:
http://knowledgeforge.net/microfacts/trac/browser/trunk/microfacts/public/behaviour/app/controllers/geochronopage_controller.js

You can see it sets up two views (or view-controllers, if you want to 
think about the HTML DOM as the "view"):
http://knowledgeforge.net/microfacts/trac/browser/trunk/microfacts/public/behaviour/app/views/mapview.js
http://knowledgeforge.net/microfacts/trac/browser/trunk/microfacts/public/behaviour/app/views/timelineview.js

Each of which has a third party component (in this case, OpenLayers and 
Simile respectively). Domain data is sent with the page, and the 
controller just sets up the model with this domain data. So there's no 
AJAX call on page load.

The model class is here, and this needs to be reworked because it is 
called by moovc.js (in lib/ ...):
http://knowledgeforge.net/microfacts/trac/browser/trunk/microfacts/public/behaviour/app/models/model.js

Those are the MVC objects. What are the sequences?

Basically, the page controller's addView() method sets things up so that 
the page controller listens to events on each view, and so that each 
view listens to the events on the page controller.

When some screen event arrives at a view, the view interprets the user 
gesture and fires a suitable event, letting the controller know about 
the gesture. The controller then lets all the views know something 
happened (by firing its corresponding event). All the views then respond 
to the user's gesture as if it had happened only to them.

Things get going when the model is setup. The controller is already 
listening to the model, so when the model fires "onThreadStart", the 
controller relays this to the views, which respond to being informed of 
the existence of the domain data. Thread data appears on the screen, in 
whichever way the views wish.

Sometime later, a user may select a factlet. The clicked view picks up 
the screen event, and fires its "factletSelect" event, which the page 
controller immediately receives. The page controller immediately fires 
/its own/ "factletSelect" event, which all the views immediately 
receive, and their onFactletSelect() handler is called. The views then 
each do whatever they do, which may involve changing the "screen" (the 
HTML DOM) to indicate a factlet has been selected.

Although different views possess different behaviour, the occurrences 
are common.

The thread "read" and "edit" pages works in a similar way, but there's a 
lovely "event delegation" mechanism (written by Nick Stenning) which 
they use to interact with the HTML DOM.

But there's a lot of sorting out to do in this code base. So mind 
yourself on the sharp edges.

I was hoping that, after we established a central controller, we would 
identify most of the application occurrences, and much of the page 
presentation state (ie data that isn't domain data). Then we could work 
the controller into the overall model object, and call it an (active) 
Presentation Model. That might not be so hard to explain. :-)

Best wishes,

John.

-- 
Appropriate Software Foundation
http://appropriatesoftware.net
Telephone: 07811 392292

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okfn.org/pipermail/okfn-help/attachments/20080904/6667bf6b/attachment.htm 