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]
