PDA

View Full Version : Preventing Namespace Collisions



brian428
9 May 2012, 12:11 PM
Hello, I'm new to ExtJS and had a question about namespaces. I understand the reasons to use them (for organization and to prevent class collisions within an application).

In Java, the norm is to create packages with very specific names. These can often be long, e.g. "com.mycompany.widgets.gwt.myapp.controller", etc.

The reasons for this are probably obvious, since building a Java app essentially merges all of the namespaces of all of the libraries in use, so careful thought must be given to prevent overlap and collisions.

When it comes to Ext namespaces, is this as much of a concern? If a single web page has separate iframes or windows in it (like a portal), is there a danger that namespaces across separate apps/frames can collide?

Basically, I'm wondering how far people take the namespaces.

scottmartin
10 May 2012, 3:53 PM
Here is a good article on our class system that provides info on name spacing conventions:
http://www.sencha.com/learn/sencha-class-system/

Regards,
Scott

brian428
11 May 2012, 5:50 AM
Thanks, I had read that but it doesn't say much beyond the fact that packages organize your code. I'm trying to get deeper and determine what the benefits are beyond organization. Mainly, under what conditions will namespaces conflict (in the same application? In the same frame?), how concerned I should be about this, and what is the best way to avoid it.

friend
11 May 2012, 6:08 AM
In your daily development duties, namespacing is mostly an organizational practice. The only real-world scenario I've come across where namespaces were important is when I had to integrate some Ext code into a page which already used a 3rd party Javascript framework.

Having said that, I still think namespacing helps keep you from stepping on your own toes as an application grows in size and scope.

brian428
11 May 2012, 6:22 AM
Great, that helps. So to clarify further, the only real danger of namespace collision is if your application is using some external code with the same namespace? And if you're running your app in a portal (like a "widget" in its own iframe), there won't be conflicts with apps in other iframes? In other words, each iframe would be self-contained from a namespace perspective because they're all separate apps running on separate pages.

Thanks,

Brian

friend
11 May 2012, 9:55 AM
Yes, you generally only have to worry about namespace collisions on Javascript objects which are operating in the same document scope.

If memory serves me correctly, every page has its own javascript environment and its own global variables. You can explicitly reference items in child iframes with some parent.frames["frameName"] trickery, but in general iframe Javascript namespaces are protected from each other.

jay@moduscreate.com
13 May 2012, 4:38 AM
Technically there are no namespaces in JavaScript. Everything is either lexically scoped or globally scoped. We use the word "namespace" but it's not truly.

Ext is a globally scoped reference. You can test this by doing window.Ext.getVersion().version == Ext.getVersion().version :).

That said, you should not have to worry about collisions if you use a unique namespace identifier (Global reference) for your applications. Couple that with lexically scoped references, and you should be OK

brian428
14 May 2012, 5:45 AM
Thanks, Jay. This may just be my lack of familiarity with JavaScript (I built Flex apps for about 8 years before making this switch), but does that apply to iFrames? Since an iFrame is really rendering a separate page, if you run 2 Ext apps in 2 iFrames in a single browser window, does that still mean there is only one Ext instance in use? Or would there be two in this case (one for each iFrame)?

Regards,

Brian

jay@moduscreate.com
14 May 2012, 6:02 AM
Thanks, Jay. This may just be my lack of familiarity with JavaScript (I built Flex apps for about 8 years before making this switch), but does that apply to iFrames? Since an iFrame is really rendering a separate page, if you run 2 Ext apps in 2 iFrames in a single browser window, does that still mean there is only one Ext instance in use? Or would there be two in this case (one for each iFrame)?

Regards,

Brian

You're partially.

Each iframe is its own "sandbox", where they each have their own global pool of references. So, you can have N number of instances of Ext JS running on a single page with frames. I highly discourage that practice, as it's inefficient and extremely difficult to debug.

Ext JS was not designed to deal with multiple frames.

brian428
14 May 2012, 4:42 PM
Hmm...now I feel like I need to dig a bit deeper. We're working on an application that is essentially a portal. There is a "shell" application (which happens to be an ExtJS app) where users can manage their portal and add "widgets" (basically, portlets) to their workspace. These are written in a range of ways: some are ExtJS, some are Flex, some are GWT, etc. Each widget is loaded into an iframe from where ever they are hosted (they may be coming from a range of locations internal to the enterprise). The different widgets only communicate with the outer "shell" application (or with each other) through a very specific API that is very generic (since it has to be usable by many different widgets using different technologies).

The portal seems to handle all of this just fine. I'm really just trying to make sure that different ExtJS apps loaded into separate widget iframes aren't going to step on each other in some way. They *should* all have different application names anyway, but since they're running in separate iframes it seems like this should isolate them completely.

If that clarifies my situation enough, can you confirm?

Thanks,

Brian

jay@moduscreate.com
14 May 2012, 5:23 PM
They shouldn't step on each other. I will warn you however, that the architecture is not really optimal. Think about how much JavaScript the browser has to utilize for one widget. An entire framework for one small set of functionality.

Brian, I highly suggest rethinking your strategy if you can. You're headed down the road of instability and an unmaintainable application.

brian428
15 May 2012, 5:20 AM
Thanks for the confirmation.

The architecture isn't something I have control over; the client manages that side of it and we're tasked with building a number of the widgets that will be used in the larger container.

There are downsides, but size isn't an issue (client memory and bandwidth are high). They are much more interested in being able to consolidate a wide range of apps and data sources on servers across their infrastructure together into one interface. This is a pressing need for them since currently many of these systems are underused because of the sprawl across their network. So for the client, a consolidated interface essentially trumps any of the negatives for their selected approach.

mark0978
15 May 2012, 7:22 AM
In this case, it seems like a single extjs instance in the browser using divs for the portlet regions would make the most sense from a memory standpoint. If each portlet has its own namespace (and maybe makes use of a common namespace for utility functions) it should be easy to build and remain sane.

I'm doing a similar project right now and that is the path we have chosen, our portlets though are much more tightly woven than yours though, essentially being different ways of looking @ similar data. I'm figuring several of our stores will common and then each little portlet will be its own "app" within the wrapper app.

jay@moduscreate.com
15 May 2012, 11:46 AM
Thanks for the confirmation.

The architecture isn't something I have control over; the client manages that side of it and we're tasked with building a number of the widgets that will be used in the larger container.

There are downsides, but size isn't an issue (client memory and bandwidth are high). They are much more interested in being able to consolidate a wide range of apps and data sources on servers across their infrastructure together into one interface. This is a pressing need for them since currently many of these systems are underused because of the sprawl across their network. So for the client, a consolidated interface essentially trumps any of the negatives for their selected approach.

Understood. I just thought i'd share my $.02 as a community member :)