Now that 0.1 is more or less released, it is a good time to take a step back, evaluate the current code base to see where stuff can be improved, refactored and made more contributor-friendly.

To this end Matt has been giving the current Scooby team high level overview of the front-end architecture of Scooby. Here are some rather skeletal notes, please fill in where I have left gaps.

Also, there are headings for stuff that hasn't been discussed yet - this will provide us with a jumping off point for stuff to discuss the next time.

Suggestions/Criticisms/Opinions/Flames should be rendered in bold with a wiki signature so we can easily spot them as action items, or jumping off points for discussion

File Layout

• The file "main.jsp" in the root of the webapp contains the skeleton for the layout of the page
• All JavaScript files are stored in the js/ directory
  • BobbyRullo - We can probably all agree that the js directory needs a little TLC - some more hierarchy would be a good starting point, and I strongly reccomend Dojo's packaging system or something like that so that dependecies are clear. Also, it would be good to have seperate directories for stuff from third parties (currenly just json I believe)
  • MatthewEernisse Whatever ever packaging system we use, I really want to avoid anything that uses ugly hacks like document.write (okay maybe if it's only for Safari it's okay). I've asked where I can go to find more out about Dojo's require method, but have not had an answer forthcoming. I've been surfing around in the source, but I'm also hoping I can pick Alex's brain about that at some point soon. The only other thing I'd put on my Christmas list for packaging is that pluggable components should be segregated from core code somehow -- the same thing I mentioned in the discussion on the mailing list about the json_service_impl.js library.
  • BobbyRullo I too have had a hard time finding docs about the packaging system.

UI Rendering

• The initial rendering of the UI is done in Cal.placeUI() in cal_main.js.
• UI of stuff is done mostly programtically through DOM and innerHTML calls. (innerHTML is all done during the initial page load.)
  • Main.BobbyRullo - The layout of scooby is very dynamic, and thus static HTML cannot be used to render, so we do stuff in this programmatic way. Yet I feel that something is lost this way, the nice thing about static HTML is that it is easily maintainable. You can clearly see where individual ui elements and tweak them. One step towards more maintainable ui is to have all the ui elements (call them widgets if you like) be actual objects which you call with constructors and are manipulatable through member functions and stuff. Then we can instantiate them in other (test) pages and tweak them without having to load up the whole UI. If we go down the DOJO route we can go so far was to use their widget templating system, which I like becuase you basically mock up a ui element in static html and then add then use that as a template to create new widgets with dynamic paramters. VERY object-oriented, very HTML-coder friendly - the best of both worlds
  • MatthewEernisse We didn't actually get to the discussion of the placeUI method, but if you look at it you'll see that each UI component is already an object, instantiated with a constructor (e.g., var leftSidebar = new ContentContainer?('leftSidebarDiv'); -- the single param is the id of the DOM element). The ContentContainer object is a very simple object with two basic methods -- setPosition(top, left) and setSize(width, height). The object represents an absolute-positioned DOM element (usually a div), and lets you programmatically place and size it on the page. I don't know anything about the Dojo widget system, but the process you use to describe the prototyping process with static HTML is pretty much the standard way to do it. Originally these UI components for Scooby were actual markup on the page with hard-coded values, and I transitioned them to this object-oriented system that now dynamically calculates sizes and positions based on the size of the window.
  • BobbyRullo Matt, yes your stuff is objects which is good, but what I was describing was not instantiating some sort of generic ui componenet like ContentContainer^?, but more like new LeftSideBarDiv^?(), which would 'know' how to draw itself. The template is actual mark up with dynamic elements...Hard to describe without seeing it so check out http://dojotoolkit.org/docs/fast_widget_authoring.html which is Dojo's approach

il8n

• xxxx

Error Handling

• BobbyRullo - JohnTownsend^? threw out a good idea about having front end exceptions passed back to the server

Async Registry

• xxx

Event Handling

• xxx

Misc

• BobbyRullo - this is nitpicky, but it tweaks me a bit so I'll mention it - clone should not be a static method. MatthewEernisse I'll keep that in mind (actually CalEventData.clone is done the same way) moving forward, and will fix those two when I get a chance. Alternatively, if it's sufficiently irritating, feel free to jump in and fix that broken stuff yourself. But otherwise I promise I will fix it when I get a chance. :)