1. #1
    Sencha User
    Join Date
    Nov 2008
    Posts
    35
    Vote Rating
    0
    mjack003 is on a distinguished road

      0  

    Default Scalable Application Backend Storage

    Scalable Application Backend Storage


    This post is not directly related to javascript or ExtJS for that matter but this is the perfect audience to pose this question to...due to the large number of application minded web developers rather than the "website" oriented. I'm currently in the process of migrating a larger companies proprietary desktop based ERP system to a fully customizable and open source web based application using an Oracle 10g back end (existing from previous application...of course not open source), j2EE middletier with spring as the core framework, and ExtJS as the primary client side library. The quantity of javascript classes and css fragments is continually growing as segments are migrated to the new system. My question to this forum is, what are the current practices being used out there as far as a dynamic javascript and css warehouse that is easily scalable and manageable and can be combined, minified, and compressed with the smallest impact on overall performance?

    The scenario that brought upon this question is, John Doe logs into the system, a session is created and managed, application roles are loaded, and his main desktop is returned to the screen. Obviously not all components are loaded, but when items are opened from the main navigation bar, each component loaded has its own list of required resources and these are loaded using ajax. This segment works great, what does not work currently however is these components need to be "compiled" server side at runtime rather than pre-configured javascript files sitting on the webserver or multiple calls to collect individual resources (which currently can be up to 20 files with the potential to be more).

    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.

    Appreciate any input.

    Mjack

  2. #2
    Ext User
    Join Date
    Jul 2007
    Location
    Florida
    Posts
    9,996
    Vote Rating
    5
    mjlecomte will become famous soon enough mjlecomte will become famous soon enough

      0  

    Default


    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.

  3. #3
    Sencha User harley.333's Avatar
    Join Date
    Mar 2007
    Posts
    286
    Vote Rating
    4
    harley.333 is on a distinguished road

      0  

    Default


    Our UI is not generated at runtime.

    We've been using a "Core + Modules"-based system of JavaScript files. Our "Core" consists of ExtJs and other shared JavaScript classes. Each "Module" represents a screen (a Use-Case). Our main navigation is driven by a Ext.tree.TreePanel. And the majority of our content resides in a Ext.TabPanel.

    When a tree branch is clicked, it expands using Ajax. When a tree leaf is clicked, a new tab is created on the TabPanel with an "id" generated using Ext.id(). The tree leaf knows what server-side resource to request, and passes the tab's id to that resource. The server-side resource usually generates a single SCRIPT tag (invoking a "Module" JavaScript file).

    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?

  4. #4
    Ext User
    Join Date
    Jul 2007
    Location
    Florida
    Posts
    9,996
    Vote Rating
    5
    mjlecomte will become famous soon enough mjlecomte will become famous soon enough

      0  

    Default


    Harley:

    Are you eval'ing in those resources, adding them to the head tag, or something else?

  5. #5
    Sencha User harley.333's Avatar
    Join Date
    Mar 2007
    Posts
    286
    Vote Rating
    4
    harley.333 is on a distinguished road

      0  

    Default


    When creating the new tab, I use the autoLoad config option. I set "scripts" to true and let ExtJS do the rest.

  6. #6
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,483
    Vote Rating
    35
    Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    I've posted frequently about the approach we use here.

    We're JEE+Hibernate.

    We have gone for a single page web application which transports JSON once the main page has been loaded.

    I have a little explanation here http://extjs.com/forum/showthread.ph...005#post256005

    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.

  7. #7
    Sencha User
    Join Date
    Nov 2008
    Posts
    35
    Vote Rating
    0
    mjack003 is on a distinguished road

      0  

    Default


    @MJ -- Sorry I left it so open ended. I really didn't want to lead in a particular direction...but I could have been a bit more descriptive. To give some more information, we're developing a single page application using ajax and spring webservices as the middle tier. Currently I have a bunch of flat javascript files that is continually growing as this is a moving project that will continue to be developed after put into production so I was looking for ideas of how people organize their javascript and css files in a HUGE project where the end size is unknown. The application layout is similar to the aptana or eclipse IDE where the main navigation is on the left, and all the other regions are dynamic drag and drop tab panels. Each panel/screen covers a business object (purchase order,material requisition etc etc.) which has its own access rights based on application roles. To me it doesn't make sense to have "pre-configured" javascript/css files that are already gzipped and minified when certain functionality does not need to be loaded to the screen or in some cases selected user options need to be injected and on the flip side in a project of this magnitude it becomes difficult to manage multiple files that are branched to handle all functionality not to mention code duplication is almost a guarantee with multiple developers. I hate to lead but in my mind I was headed towards storing my javascript and css within the database wrapped in xml to cover all situations and as long as xml tags are placed correctly, xslt can be used to combine these "files" and handle any possible logic that may come up. That's what I meant by "compiled". Combine modules, inject if needed, minify, and gzip before sending to the browser. These can then be cached in the middle tier for this session or multiple sessions with the same access.

    @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?

    Mjack

  8. #8
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,483
    Vote Rating
    35
    Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    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.

  9. #9
    Ext User Yoris's Avatar
    Join Date
    Dec 2007
    Posts
    36
    Vote Rating
    0
    Yoris is on a distinguished road

      0  

    Default OB

    OB


    Openbravo is not your best choice according to what you say pal, you should just start over a new app.

  10. #10
    Sencha User
    Join Date
    Nov 2008
    Posts
    35
    Vote Rating
    0
    mjack003 is on a distinguished road

      0  

    Default


    Are you referring to the existing web based ERP system Yoris? If so, this thread has nothing to do with it. We're developing an in-house solution...from the ground up.

    Mjack

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar