I've got some ideas but they seem a bit convoluted for this situation. So please share any experiences that you might have in this situation.
Perhaps you should flush out more what you mean by compiled. What exactly is being compiled? Do you have backend scripting sprinkled throughout your js files? Have you isolated dynamic content in these files? I think if you flush out the details a little more on what you're doing you'll get better input.
When the server is done, the browser can load the "Module." At this point, the "Module" does whatever necessary to get the job done. The "Module" has the tab's "id," so it knows where to render everything. The "Module" can also take advantage of the shared classes in our "Core."
This simple architecture has worked very well for us. Several of our Modules are very complicated. Perhaps there is more to your application which makes this architecture unsuitable.
What about your application needs to be generated at runtime?
Each application "component" has a JSP which describes its UI, and a servlet to which it submits requests.
The JSP is Ajax-loaded, returns a JSON object which is evaluated and added to the Viewport's center region.
It corresponds with its servlet during its lifecycle by sending and receiving JSON.
Each JSP is only loaded once because it does not encapsulate data, only UI information, so the client framework caches the returned objects by URL, so next time you invoke that application Component, it's available immediately with no server request needed.
@harley -- I've got the core handled which is simply included on page load. There's not much that YUI and ExtJS doesn't cover so this is the easy part. Hard part becomes the modules side where if kept as flat files will grow to the hundreds. We've got multiple developers so visibility is also a key to keep code from being duplicated. To give an example, the purchase order screen uses the supplier.js file which is used by four other "modules" so its critical this supplier.js file can handle all use cases but be dynamic so that unneeded functionality is not loaded to the screen when it will never be used. To do this with flat files, currently the supplier.js file would have to be split into 5 different files.
@Animal -- Thanks for the link. I've got something similar currently to handle loading flat files. My question is how do you manage, control, and provide visibility for hundreds of js "modules" in a high paced development environment so that the organization is scalable to the nth degree and is easily understood by multiple developers. In my mind, the only solution is to organize these into xml documents and use one xslt file per tab to "compile" modules and then cache these in the middle tier. Seems convoluted but to me its the best way to keep "files" in a heiarchal format and keep them centralized not to mention dynamic. What do you think?
We have set of Component enums. Each Component defines its JSP page and its handling servlet.
When a new Component is written, a new enum is created.
We have a single servlet handler to handle routing HTTP requests to the Components which just takes the Component's name or ordinal, finds it from the enum class, gets its JSP, and forwards it to the JSP.
When submitting data for processing to the servlet, it goes through this same single servlet asking for the some component, but with a command, so it gets routed to the Components processing servlet.
All JSP files are converted into servlets by JASPER, and exist solely as servlets.