I think, for this shop, the question of "should we do this or just refactor the original" is pretty much answered: We have to. The mess I inherited is barely maintainable. As is is, if something changes or I find a bug, I have to touch code in every course individually. It's barely a step above code in frames (and does include some of that).
I'm basically building a course presentation system for the ISDs who build the individual training content. They have limited programming knowledge. I'm mostly trying to build a new basis for their work: A core course engine nearly all of it's logic externalized in small plugins. The idea being when the customer or ISD comes up with a new idea that would previously require new course template, I write one new plugin and either replace an existing plugin, or just add it to the stack of plugins. Practical example: Current functionality is a centered content, say 800x600, and content containment is handled by a plugin content.swf. Customer wants a full screen content. I build a new plugin to handle full screen layout. ISD's have little to no change in how they're building content. Another example: ISD's want to have something that creates keyboard shortcuts for them for each page. I write a plugin that searches the mc's in the content swf that have _accProps.shortcut set and create a shortcut based on that value, and remove it on page unload. Anyway, reading your response got me thinking of something that might be better in terms of design (but may be pretty out there). I was previously treating the plugins as if they were controllers: They receive events and act on the main application or other plugins. I think this may be my mistake. My next idea (which is still churning a bit in my head) is to create Plugins which are little more than containers for Command objects. Plugins implement specific interfaces so the Main controller knows what commands the plugin contains and what bus/chain needs to execute them. Still see a few problems: Some plugins create objects that fire events. Would the command create commands to handle them? Also it still sounds like I'll be passing the commands a reference to their containing controller or the view itself -- I'm still not sure how I feel about that (or if it should even bother me). You (or anyone else) see a glaring error in this thinking? On 8/22/07, Hans Wichman <[EMAIL PROTECTED]> wrote: > > Hi Jer, > > we have been dealing with the same kind of questions (and still are now > and > then). > > We have a course engine out there, which has a very simple setup/interface > (although the inner workings are not that simple). > But we ran into the same problem, adding content required us to recompile > the engine now and then. > > We thought about going the plugin way, and we even had most of the design > ready. > > It involved something like loading a plugin which existed of a number of > classes defining the plugin, request/result types, registration to one > service bus or another etc. In the end a request wouldnt know which > service > satisfied it, which plugin handled the result etc. > Basically it didnt involve a lot more than usual I think in terms of > patterns, using the command, businessdelegate, service, valueobject, > request/response (if you can call that a pattern), abstractfactory, > registries etc. > BUT the biggest problem at the moment is that the gap in terms of > refactoring between our current system and the 'utopia' system is too wide > to call it refactoring. Better to call it a complete rewrite. In addition, > the question we were asking ourselves was whether we were going to do this > because it would be uber cool to build such a plugin system, or that the > functionality required really demanded such as architecture. > > In the end we chose to follow a different route at the moment and that is > refactoring our current system step by step. Not that it is a bad system, > it > is pretty good as it is, but in order to be able to maintain/extend it etc > some refactoring is necessary. Maybe if the requirements require it (:-S) > and the refactoringsprocess has gone far enough, the plugin system will > find > its way in eventually. > > Maybe it is of any use to you if I describe the current system: > > the current system has a few part, a controlpanel, a dialog panel and a > locationpanel > These parts supports different commands, eg loadSwf, showDialog, > addTabButton etc > All these commands are supplied by the backend. > > So basically an empty interface starts up and sends a systemstart event to > the backend. > The backend says load location A, show dialog B, and adds these 3 buttons. > > The location can be anything, for example we have an fake email > application, > a notepad, panorama's etc, but the most basic location type is simply an > image with hotspots. If you click on a hotspot, an event goes back to the > server and the server tells us what to do again such as load another > location, remove some buttons, add some tabs. > > In the end its a complete elearning/adventure style kind of engine. > > HTH > JC > > > > > On 8/22/07, Jer Brand <[EMAIL PROTECTED]> wrote: > > > > AS2 / Flash 8 project and needing help with the design. I'm probably > going > > into way too much detail for the question but... > > > > I'm working on course template or engine (for lack of a better term) to > > deliver content swf's. The problem in our shop is the massive amount of > > change in basic functionality for each course have meant (before I > worked > > here) the template code has to change every course. This, to me, is a > very > > bad thing. > > > > My solution is to build the core template to be almost slide show > simple, > > but loads classes from external swfs as "plugins" and broadcasts a > number > > of > > events. Each of the plugins's implements an interface that tells the > main > > app what events the plugin should be subscribed to. > > > > Nearly all the functionality is contained in the plugins: LMS > > communication, > > layout, accessibility, the actual interface, etc. Plugins have to be > able > > to > > modify or add content to the main app and the loaded content pages. > > Plugins > > also have to be able to tell the main app when they're done doing > > performing > > their edits at each event. > > > > Now, I have a working solution, It does the job, and does it well. > > However, > > the design of the app and plugins are heavily interconnected. To get the > > job > > done, the main app has to constantly pass around pieces of itself and > > other > > plugins (like the display area or the UI), the interface to keep things > > working smoothly. > > > > Obviously it's not good design, but the prototype is out of the way, and > I > > know it's not an invalid path to use something like this. Now I'm > looking > > for a better way. Is there a Pattern or common practice for designing a > > plugin scheme? My first thought was "Hey, isn't there a Plugin pattern?" > > but > > my google skills are failing me on finding anything about it, or how > > anyone's done this in the past. > > > > Any help to be had or is this such a specific thing that general "this > is > > the best pattern" isn't a valid question. > > _______________________________________________ > > [email protected] > > To change your subscription options or search the archive: > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > Brought to you by Fig Leaf Software > > Premier Authorized Adobe Consulting and Training > > http://www.figleaf.com > > http://training.figleaf.com > > > _______________________________________________ > [email protected] > To change your subscription options or search the archive: > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > Brought to you by Fig Leaf Software > Premier Authorized Adobe Consulting and Training > http://www.figleaf.com > http://training.figleaf.com > _______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
