1. #1
    Ext JS Premium Member
    Join Date
    Jun 2010
    Posts
    100
    Vote Rating
    11
    h.wagner@telekom.de will become famous soon enough

      0  

    Default Using variables for URLs in ExtDesigner?

    Using variables for URLs in ExtDesigner?


    Is it possible somehow to use variables in ExtDesigner for the URL properties, of e.g. DataStores?
    I couldn't find one .
    I know that it's possible in Preferences to set a URL prefix, but unfortunately this doesn't help with the problem of the changing (or not pre-hardcoded) context of a webapplication (e.g. for Java based webapps), or simply allot of situations when paths need to be more flexible.

    It would be nice if when the URL property in designer is filled with e.g.:
    $variable + /my/path/to/the/resource.jsp
    this wouldn't be transformed to:
    ...
    url: '$variable + /my/path/to/the/resource.jsp',
    ...
    but to something more useful like:

    ...
    url: $variable + '/my/path/to/the/resource.jsp',
    ...

    Thanks in advance.

  2. #2
    Ext JS Premium Member
    Join Date
    Sep 2010
    Posts
    50
    Vote Rating
    0
    extjs@araneum.nl is on a distinguished road

      0  

    Default


    so why not put the url in your .js files?

    so

    1) turn of autoload in your store
    2) load your store manually with your custom url example

    Code:
    var myStore = this.myGrid.getStore();
    myStore.load( {
        url : my_own_url
    });

  3. #3
    Ext JS Premium Member
    Join Date
    Jun 2010
    Posts
    100
    Vote Rating
    11
    h.wagner@telekom.de will become famous soon enough

      0  

    Default


    Quote Originally Posted by extjs@araneum.nl View Post
    so why not put the url in your .js files?
    so

    1) turn of autoload in your store
    2) load your store manually with your custom url example

    Code:
    var myStore = this.myGrid.getStore();
    myStore.load( {
        url : my_own_url
    });
    Unfortunately I can't. The UI's and stores are made by other users that define also what URLs with what params should work. Also autoload is required.

    Right now I have no idea how to solve this except post-process the files before deploy by replacing the wrongly added quote by the designer.

    Fact is: there are many other places in the designer generated output where "variables" would be required (I mean for non-trivial use cases). It would be really nice if the designer would allow/recognize them , or even better manage them - e.g. by defining in the preferences of a project those allowed variables.

    Thanks in advance.

  4. #4
    Sencha - Desktop Packager Dev Team jarrednicholls's Avatar
    Join Date
    Mar 2007
    Location
    Frederick, MD
    Posts
    1,747
    Vote Rating
    7
    jarrednicholls will become famous soon enough jarrednicholls will become famous soon enough

      0  

    Default


    Hi Holger,

    Variables (defines) would be a good feature request for a future release. With that said, I fail to understand the problem here. The URL Prefix preference is available to allow you to load data from different origins, but maintain the same configured relative path in your store configurations.

    For example, let's say you are developing on http://localhost/myapp/, but need to deploy to http://www.mycompany.com/apps/myapp/. You would configure stores with a relative URL e.g. my/path/to/resource.jsp (no leading slash). When you run your application from either localhost or www.mycompany.com, the store's URL is relative to where the application is running and will be fine.

    In Preferences, the URL Prefix would be in this case set to http://localhost/myapp/, so when you wanted to right-click and Load Data into the store, the Designer will request data from http://localhost/myapp/my/path/to/resource.jsp. In other words, the URL Prefix preference supplies the "origin context" for the store load, thereby mimicking running from http://localhost/myapp/ in a browser. But the url configuration supplied to the store should almost always be a relative path, so it can switch from a development environment to a production environment.

    If the above still doesn't satisfy, then you can turn off "Instantiate Stores" in the project Preferences and instantiate your stores with the dynamic URL elsewhere. The "other users" can still configure the urls, but then you can just undo what they did and instantiate the stores with appropriate urls.

    Code:
    new MyStore({
        url: someUrlPrefix + '/my/path'
    });

  5. #5
    Ext JS Premium Member
    Join Date
    Jun 2010
    Posts
    100
    Vote Rating
    11
    h.wagner@telekom.de will become famous soon enough

      0  

    Default


    Quote Originally Posted by jarrednicholls View Post
    Hi Holger,

    Variables (defines) would be a good feature request for a future release. With that said, I fail to understand the problem here. The URL Prefix preference is available to allow you to load data from different origins, but maintain the same configured relative path in your store configurations.

    For example, let's say you are developing on http://localhost/myapp/, but need to deploy to http://www.mycompany.com/apps/myapp/. You would configure stores with a relative URL e.g. my/path/to/resource.jsp (no leading slash). When you run your application from either localhost or www.mycompany.com, the store's URL is relative to where the application is running and will be fine.

    In Preferences, the URL Prefix would be in this case set to http://localhost/myapp/, so when you wanted to right-click and Load Data into the store, the Designer will request data from http://localhost/myapp/my/path/to/resource.jsp. In other words, the URL Prefix preference supplies the "origin context" for the store load, thereby mimicking running from http://localhost/myapp/ in a browser. But the url configuration supplied to the store should almost always be a relative path, so it can switch from a development environment to a production environment.
    [/code]
    Thank you very much for your detailed response.

    Basically the stuff with related URLs is correct, however it's not working in practice for many projects due to different places in the hierarchy where the code is called. For projects that have only "one URL" (monolithic apps) this might be very simple, because from that point everything is relative to it, so the context shouldn't matter that much except how you described it. However in our apps, a store, or an UI can be included in various places in the hierarchy, and from those different places, the relative URLs don't work anymore .

    This is way, to avoid problems, as a general rule, there are in use always absolute paths prefixed by the context variable, so that the Servlet Container can fill itself the correct context. With this approach even after refactorings, the URLs still work since they're always absolute.

    To simplify the JS code, this context path variable is also available there too, so everything works fine with this approach... well except with code generated by ExtDesigner .

    Thanks in advance.

  6. #6
    Sencha - Desktop Packager Dev Team jarrednicholls's Avatar
    Join Date
    Mar 2007
    Location
    Frederick, MD
    Posts
    1,747
    Vote Rating
    7
    jarrednicholls will become famous soon enough jarrednicholls will become famous soon enough

      0  

    Default


    Sure, I understand that. If the deploy url is the same domain as the data url, you could use non-canonical urls as well. For example:

    Data Service URL: http://www.mycompany.com/data/users/index.jsp
    App URL: http://www.mycompany.com/apps/myapp/index.html

    You can set your store URL to be: /data/users/index.jsp (absolute path) or ../../data/users/index.jsp (non-canonical relative path).

    In any case, I know the idea of definable variables are super useful in a lot of areas, I'm not questioning that idea. However, I'm confident you can get your store urls configured without that feature Let me know how you fare.

  7. #7
    Sencha - Desktop Packager Dev Team jarrednicholls's Avatar
    Join Date
    Mar 2007
    Location
    Frederick, MD
    Posts
    1,747
    Vote Rating
    7
    jarrednicholls will become famous soon enough jarrednicholls will become famous soon enough

      0  

    Default


    Really the only time a prefix variable is needed would be one of the three situations:
    1. The prefix url changes dynamically all the time, in both dev and prod environments
    2. Your development environment is structured completely different from your production environment, you have no control over your development environment, and there's just no way to use the same relative/absolute pathing in the store url configuration that would satisfy both environments
    3. You needed to switch to SSL/HTTPS

  8. #8
    Ext JS Premium Member
    Join Date
    Jun 2010
    Posts
    100
    Vote Rating
    11
    h.wagner@telekom.de will become famous soon enough

      0  

    Default


    Quote Originally Posted by jarrednicholls View Post
    Sure, I understand that. If the deploy url is the same domain as the data url, you could use non-canonical urls as well. For example:

    Data Service URL: http://www.mycompany.com/data/users/index.jsp
    App URL: http://www.mycompany.com/apps/myapp/index.html

    You can set your store URL to be: /data/users/index.jsp (absolute path) or ../../data/users/index.jsp (non-canonical relative path).
    Almost, but there's the context there too (variable - it might be ROOT, so it's not there, or it might be whatever at deploy time is allocated) .
    Data Service URL: http://www.mycompany.com/<b>context<...sers/index.jsp
    App URL: http://www.mycompany.com/<b>context<...app/index.html
    And unfortunately this is just the simplified case.
    "non-canonical relative path" as you describe them are very error prone, because refactorings might brake them, or the form/panel/UI might be used in several pages so it can have several relative positions to it's datastores.

    Quote Originally Posted by jarrednicholls View Post
    However, I'm confident you can get your store urls configured without that feature Let me know how you fare.
    So far the "replace" post-processing trick seems the only ugly but practical solution to this problem

  9. #9
    Ext JS Premium Member
    Join Date
    Jun 2010
    Posts
    100
    Vote Rating
    11
    h.wagner@telekom.de will become famous soon enough

      0  

    Default


    Quote Originally Posted by jarrednicholls View Post
    Really the only time a prefix variable is needed would be one of the three situations:
    1. The prefix url changes dynamically all the time, in both dev and prod environments
    2. Your development environment is structured completely different from your production environment, you have no control over your development environment, and there's just no way to use the same relative/absolute pathing in the store url configuration that would satisfy both environments
    3. You needed to switch to SSL/HTTPS
    Thank you for your time and your very detailed responses.

    Well, I can give you common scenarios that happen all the time (at least with Java based development):
    1. Prefix:
    - development URLs are http://localhost:8080/variable_context/all/pages, but the app should be callable by others too for quick view of some feature (so with http://my.local.ip.number:8080/varia...text/all/pages)
    - test URLs are http://some.other.ip.number:80/varia...text/all/pages
    - production https://sub.domain.com/variable_context/all/pages

    Having variable_context, also ensures that several instances of the application can run at the same time on the same machine (e.g. to try/show some new features, etc. ).

    2. Environment:
    - because of the variable context, it's not possible to use hardcoded absolute urls. Relative is also not working for the reasons specified in the previous post.

    Basically this is how all Java based webapps should be developed : to be context agnostic (hence the Servlet method: request.getContextPath(), to ensure that correct absolute URLs can be simply build at runtime).

    3. SSL - production has it (for some of the pages), test too, but development almost never. Also it is decided by the external SSO solution what resources will go over https and what not and when.

    Even if all the above and from the previous posts sounds a little complicated, they're not . At least in Java based webapps this is "best practice" that ensure robust applications, and it's supported by most good web frameworks too.


    Thanks in advance.

  10. #10
    Sencha - Desktop Packager Dev Team jarrednicholls's Avatar
    Join Date
    Mar 2007
    Location
    Frederick, MD
    Posts
    1,747
    Vote Rating
    7
    jarrednicholls will become famous soon enough jarrednicholls will become famous soon enough

      0  

    Default


    Thanks Holger for your explanations. We'll take variable definitions as a feature request for sure.

    Hopefully in the meantime, you should be able to do something like this without editing the store classes directly:

    Code:
    function fixStoreUrls(store) {
        var somePrefix = '/variable_context/';
        store.proxy.conn.url = somePrefix + store.proxy.conn.url;
    }
    Ext.each([
        Ext.StoreMgr.lookup('store1'),
        Ext.StoreMgr.lookup('store2'),
        Ext.StoreMgr.lookup('store3'),
        Ext.StoreMgr.lookup('store4')
    ], fixStoreUrls);
    or simpler:

    Code:
    function fixStoreUrls(storeId) {
        var store = Ext.StoreMgr.lookup(storeId);
        var somePrefix = '/variable_context/';
        store.proxy.conn.url = somePrefix + store.proxy.conn.url;
    }
    Ext.each([
        'store1',
        'store2',
        'store3',
        'store4'
    ], fixStoreUrls);
    There is always a way that doesn't involve editing the exported files directly...
    Last edited by jarrednicholls; 4 Feb 2011 at 9:48 AM. Reason: simpler version

Similar Threads

  1. ExtDesigner for ever ?!?!
    By Biggy28 in forum Ext Designer: Bugs
    Replies: 1
    Last Post: 30 Dec 2010, 6:28 PM
  2. ExtDesigner + Codeigniter and session variables
    By DrZog in forum Ext Designer: Help & Discussion
    Replies: 2
    Last Post: 27 Oct 2010, 6:06 AM
  3. RowEditor in extDesigner
    By tbaenziger in forum Ext Designer: Help & Discussion
    Replies: 4
    Last Post: 20 Sep 2010, 6:03 AM
  4. ExtDesigner Invoice
    By adrianprogjv in forum Ext Designer: Help & Discussion
    Replies: 2
    Last Post: 1 Jun 2010, 6:54 AM
  5. How was ExtDesigner developed?
    By jarryh in forum Ext Designer: Help & Discussion
    Replies: 2
    Last Post: 22 Apr 2010, 11:20 PM

Thread Participants: 2

Tags for this Thread