Do you have a bug tracker or somewhere I could submit a bug for http://prettydiff.com/? The site doesn't work in Opera — the "Base Text" and "New Text" boxes are completely missing (though there was no indication that anything was wrong or missing). I was starting to feel pretty stupid after staring at the page for 5 minutes trying to figure out how in the world to just use the site.
Ben Barber On Wed, Jul 13, 2011 at 7:55 AM, austincheney <[email protected] > wrote: > On Jul 13, 12:40 am, dtang85 <[email protected]> wrote: > > @austincheney -- I do like the tips you suggested, as many of them > > have been mentioned in the YUI Theatre videos and several books. > > However, I don't think by simply following these good practices will > > you "reveal a pattern of code that is easy to reproduce, easy to > > extend, and easy to maintain". I've created applications following > > most, if not all of these good practices, but still have been left > > with an application that is hard to maintain and add new features. For > > example, I've created several modules on a page and later down the > > road I've realized that these modules need to communicate. As a > > result, I've called methods of Module B from Module A, resulting in > > tight coupling. I've found that using the Publish/Subscribe pattern > > eliminates this really well and provides a great architecture for the > > most part. I haven't seen any drawbacks yet, but I'm curious as to > > whether there is a better approach to structuring the JS of an > > application. > > I am not bothered by different methods needing to communicate with > each other or share resources. That is actually two different > problems. > > 1) Sharing resources > This is easily addressed by keeping resources high enough in the scope > of the application as necessary for modules to access in closure. The > key here is never have modules return data or resources that might > need to be shared. > > 2) Inter-module communication > This is easily solved setting variables to be used as boolean flags in > a scope higher than the modules. For example: > var moduleAFlag = false, > moduleA = function (x) { > if (x) { > moduleAFlag = true; > return; > } > }; > > Different flags allow for identification of various conditions in each > module or when modules execute in various conditions. > > The complication appears that you are attempting to use custom methods > on various modules and other moving pieces. I consider this > unnecessary complexity. I can empathize that such techniques allow > for elegant reuse and faster authoring of complex code spanning > various levels of interspersed code islands, but I would not want to > be the one tasked with maintaining that code. In my opinion that > sounds like a horrendous way to mask the location of errors. > > > I am interested in the MVC pattern applied in JS like Backbone. How > > would you describe this pattern from a JS point of view? > > Modules, views, and controllers are all intended to be isolated > components with specific purposes and each separated from the data. > What I have suggested here in no way interferes with MVC except, > perhaps, how the components are supplied in a given instance versus an > application definition. The difference there, at least outside of > JavaScript, is that a schema is used to define an instance by > specifying a list of components with additional meta-data. That > difference has nothing to do with how each isolated component operates > and what they communicate. > > Austin Cheney, CISSP > http://prettydiff.com/ > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
