Brian, I highly suggest rethinking your strategy if you can. You're headed down the road of instability and an unmaintainable application.
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.
Sencha Premium Member
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.
15 May 2012, 11:46 AM