[okfn-help] IRC meeting log comments
john.bywater at appropriatesoftware.net
Thu Sep 4 00:08:09 BST 2008
Sorry I missed the meeting this meeting. I got there, but only at
9:30pm. Have read the log now:
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
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:
You can see it sets up two views (or view-controllers, if you want to
think about the HTML DOM as the "view"):
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/ ...):
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
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. :-)
Appropriate Software Foundation
Telephone: 07811 392292
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the okfn-help