How to organize a Javascript UI?

Question

I need good examples and best practices on program architecture.

I'm trying to build a JS UI for an app that works with Google.Maps. In the 1st draft, user should be able to draw geometric shapes on the map in a way similar to G.M. Then the shapes are sent through AJAX and the response is displayed.

Problem is that the code got complicated just with polygons editing.

Inspired by Joel's "Duct-tape Programmer", I tried to sketch a straightforward code that makes actions and switches event handlers, to avoid big if-else trees. "New poly" button creates an observer for map.onclick, changes event handlers for other buttons or hides them, and hides itself, etc.

The downside of this approach is that data handling code is mixed with interface. A code that creates a div container to display the data on the new polygon stands next to the code that deals w/ G.M or w/ the shape data. If I want to revise the UI, I'll need to process the WHOLE app.

I could review it later and move this UI-generating code elsewhere, but then came my lead programmer. He instead insisted on "messaging" approach: a simple event system where objects subscribe to events and fire them. Interface code can be perfectly isolated from data handling and talking to G.M, but now each listener has to double-check if this message is to it.

For example, clicking on a poly on a map must highlight it and start editing. But not if another poly is being drawn. So, some are-you-talking-to-ME?-code is necessary everywhere.

I'll appreciate good examples of UI architecture approaches.

Answer 1

The event handling idea suggested to you is a good approach.

Here's some more ideas:

• Make the shape drawing thing a component
• The shape drawing component sends events to other code, to react to stuff like "editing" or "clicked"
• This component could also handle the editing part - It sends "clicked" event to controller, controllers tells the component to go into edit mode
• While in edit mode the component would not send normal "clicked" events until the editing was closed, avoiding your problem of having to check

In general, it's a good idea to have a "view" layer which simply deals with displaying the data and sending events about user actions on that data (ie. clicks, etc.) to a "controller" layer, which then decides what to do - for example it could decide to change the view into editing mode.