I think the bottom part of the code posted is a good example of the kind of coupling that, as an application grows, becomes a real problem with debugging and adds a lot of inertia that makes changing any one part of the application hard.
I've been working recently with Backbone, and although I've ended up not using some of it's features (seamless integration with restful services for example) it does provide some useful structure to a large project. I've tried to keep all the logic of how various parts should behave in Models, tied up by a "Controller" (BB controllers are actually Routers!) each usually tied to a View (although the relationship is not one-to-one). The trick is to make sure that a View only ever binds to events in it's own Model, and can only affect properties on it's own model. The View also manages it's DOM representation obviously. This approach means that you can completely change what happens in the DOM (e.g. swapping out a flash movie for a <video> tag, or whatever) and only a single View needs to change. You can also change the logic of your application, and as long as the properties available on a Model are constant, no View needs to know about the difference. A more extreme version of this kind of idea is Knockout.js, which I'd play around with if Ihad the time! I think something that many of these architectures don't address is how your markup and JS are interrelated with your CSS. I'm sure most readers of this list could describe the theory- they should all be seperate - but in the real world, something "drag and drop" is unavoidably a blend of all three. On 12 Jul 2011, at 20:35, dtang85 <[email protected]> wrote: > @Poetro : I do namespace my PubSub object and it has publish, > subscribe, and unsubscribe methods. You can take a look at it along w/ > a demo on my GitHub account: > https://github.com/skaterdav85/Publish---Subscribe-object > > I guess my concern is that as my application grows, it will look like > a longer version of the following code, and I am not sure if this is > the best approach. I'm also curious as to how other people architect > their JS and if there are any other better architectural approaches. > > //subscription to /topic1 > PS.subscribe('/topic1', function () { > //use of jQuery here > }); > > $('#clickme1').click(function () { > PS.publish('/topic1'); > }); > > / > ***********************************************************************/ > > //subscription to /topic2 > PS.subscribe('/topic2', function () { > //use of jQuery here > }); > > PS.subscribe('/topic2', function (arg) { > //use of jQuery here > }); > > $('#clickme2').click(function () { > PS.publish('/topic2', ['arg1', 'arg2', 55, 'arg3']); > }); > > I did enjoy Nicholas Zakas's presentation, but it seemed a little bit > of overkill for your typical site and a little hard to not only > implement but also for someone else to come into your code and just > start writing. > > On Jul 12, 8:20 am, Pete Otaqui <[email protected]> wrote: >> As Nathan says, it really depends on what you're doing. You might want to >> look at Nicholas Zakas' "Scalable Application Architecture" talk which is >> very interesting: >> >> http://developer.yahoo.com/yui/theater/video.php?v=zakas-architecture >> >> I personally feel that it's suitable for the kind of thing Yahoo developed >> it for - a very modular homepage - but that the danger is in ending up with >> more and more rules in the "sandbox" (effectively letting it become a fat >> controller). The upside over pub sub is that you don't end up with lots of >> coupling between publishers and subscribers. >> >> On 12 July 2011 12:54, Acaz Souza Pereira <[email protected]> wrote: >> >> >> >> >> >> >> >> >> >>> I think that slide can help you: >>> http://www.slideshare.net/rmurphey/functionality-basedorg >> >>> 2011/7/12 Nathan Sweet <[email protected]> >> >>>> I think you need to say a little more. Do you mean classes that are >>>> loosely coupled, but have core dependencies that are always present? This >>>> is >>>> a way in which a lot of libraries and site architectures work. It very >>>> seriously depends on what it is that you're doing. It sounds from your use >>>> of the words "Publish" and "Subscribe" that you have\-}+-09sa=\-]=0-p943 a >>>> lot of JavaScript that operates dependent upon some flags that your user >>>> presents you, is that correct? If not, I'm kind of at a loss for what you >>>> mean. >> >>>> On Mon, Jul 11, 2011 at 11:39 PM, dtang85 <[email protected]> wrote: >> >>>>> Over the past year I've been focussing on JS and one thing that I >>>>> haven't seen too much about is how developers architect their JS for >>>>> small and large sites/applications. I've been primarily using the >>>>> Publish/Subscribe pattern based on my own custom implementation of the >>>>> pattern, but I'm starting to think that it may get harder to maintain >>>>> my site/application as I write more JS, as my code will consist of >>>>> several publications and several subscriptions. How do you architect >>>>> your JavaScript in a site/application, and how do you effectively >>>>> incorporate a library into your architecture? >> >>>>> -- >>>>> 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] >> >>> -- >>> www.twitter.com/acazsouza >> >>> www.acazsouza.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] >> >> -- >> Pete Otaqui >> [email protected] >> +44 7949 945542 > > -- > 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]
