View Full Version : [CLOSED] Store urls *must* be strings starting with http(s):
6 Mar 2012, 3:15 PM
7 Mar 2012, 7:37 AM
Hi, Can you add details about the issue?
7 Mar 2012, 10:36 AM
I wrote the post but as I wrote it thought I'd addressed the issue (so deleted the comment) but now realize I've not resolved it. So here I go again...
Strictly this issue is about the url of a proxy associated with a store.
The designer requires the url property to be a string and one that must start with http(s). This constraint is not one required by ExtJS. It is only a designer constraint. In my view, this constraint makes for brittle applications because hard-coded paths must be entered in the body of an application. If an application is being developed for in-house deployment on one server this would be OK. But if it is being developed for use at multiple client sites or in an environment where the correct server to use as a source of data will be determined at run-time this constraint is problematic. Sure, I can fix the code by modifying the url configuration manally (for example to use a function to return a valid url) after the designer has generated code. But now I have a code maintenance problem as I must remember to make the change to the url configuration after each code generation.
I deleted the original post because had believed I'd fixed the problem by assigning the url in application controller's 'init' function. However it turns out that aTreeStore request to retrieve data is issued by ExtJS before the init function is called and (here's where it becomes an ExtJS issue) even when the store autoLoad property is set to false.Surely that cannot be correct. It seems the TreeStore will issue an ajax call whenever a root node is set regardless of the autoLoad setting so now I'm trying to set the root node in in the init function to solve my problem.
Even so, I would not have to worry about: autoLoad; or setting the url property in the init function; or be concerned about deployment issues; if am able to set the url property to be a function.
Why does the designer care so much how I provide the url? The answer is because you want the designer to be able to retrieve data at design time. My interpretation of this scenario is that the interest of *mandating* the designer should be allowed to retrieve data is outweighing my alternative interest in having a maintainable application. Please consider making this setting more flexible.
7 Mar 2012, 10:44 AM
Setting absolute URLs is pretty uncommon (except for JSONP proxys doing cross domain requests).
You should be setting relative urls like data/foobar.jsp or even an absolute /data/foobar.jsp. You should not be including the http(s): server portion of your request in this configuration.
This is best put into the url prefix which can be configured under project settings.
7 Mar 2012, 11:04 AM
<<Setting absolute URLs is pretty uncommon (except for JSONP proxys doing cross domain requests).>>
I agree. Except in this case I am going cross domain. An analogy might be displaying Flickr or Picassa images based on user preferences.
<<You should be setting relative urls like data/foobar.jsp or even an absolute /data/foobar.jsp. You should not be including the http(s): server portion of your request in this configuration>>
I agree again. However when I exclude the protocol and host I see an enforcement notice demanding I use a prefix.
(http://s3downloads.lyquidity.com/ExtJS/proxyrul.png)For the reasons stated in the earlier post I'd like to be able to set this configuration property with a function. I wrote about the problems using functions in another post. However at least there I am able to reference a property of the 'Ext' object. Here, I'm completely stuck.
7 Mar 2012, 1:15 PM
You are using a JSONP proxy. This is a cross domain request. YOu need to specific where the server is.....
If you didn't need to specify where the server is and wanted to do this via a function you could do it via an override.
7 Mar 2012, 1:34 PM
<<You are using a JSONP proxy. This is a cross domain request. YOu need to specific where the server is.....>>
I agree, I appreciate this and outside the designer I am able to do this setting the url using a function.
<<If you didn't need to specify where the server is and wanted to do this via a function you could do it via an override.>>
Sure. Can you give me an example?
My workaround is to set the required url on all stores within a controller's 'init' function also set the root node of treestore instances at the same time.
While the workaround appears to work I'm a noob at this. Bear in mind that without worrying about the designer I already had this code working by resolving the url using a function, a solution which is simple and obvious (to me at least). The only reason for taking the extra time to figure out an alternative is to be able to generate 'finished' code from the designer. However to get to this point I've had to learn more about ExtJS than I care to.
My observation is that by so severely constraining the value possibilities of the url (and other properties) when using the designer you are forcing the user into a treasure hunt for the correct events to override or functions to use. Great if you know. If you don't its really time consuming and defeats some of the benefit of an otherwise excellent tool. It not clear to me why the property value is so severely constrained when the underlying ExtJS has no problem taking a function.
7 Mar 2012, 1:41 PM
override initComponent and set the url with a function
this.url = this.getMyFunction;
What type of complex things are generating your url? Do you need to execute the function immediately or later?
7 Mar 2012, 2:25 PM
I would *really like* to override initComponent for this and other scenarios but it's not clear to that I am able to do so. Maybe this lack of knowledge is at the root of my problem. The linked image shows what I see in the designer when editing any component.
(http://s3downloads.lyquidity.com/ExtJS/InitComponent.png)The dropdown contains only Base class/JSON/Implementation + any basic functions and overrides. initComponent does not appear as an overrideable event. If this is a trick I am missing, please let me know.
<<What type of complex things are generating your url? >>
There's nothing complicated. The application presents information about corporate financial and regulatory risk. Depending upon the preferences of the user they will need to access information from different sources. We can place scripts on the source servers to parse the request and return appropriate JSON but we cannot dictate the address of the server or the path to the scripts. Based on their preferences, the path relevant to a location is included in the index page in much the same way the direct API is included in the index page. This url needs to be applied to the proxy's url at run-time.
<<Do you need to execute the function immediately or later?>>
I'm not sure I understand the question (or I can see there may be more than one answer). Our app will want to retrieve the relevant information pretty much immediately. One of the challenges of figuring out how to set the url has been learning that the treestore appears to ignore the autoLoad flag as it will auto load as soon as a root node is set regardless of the autoLoad flag. This is an example of needing to learn more about ExtJS than I care to. If the designer would accept a variable then the url is set by the time the root node is applied by the tree view and everything just works.
For all my niggles, I do think this tool is a great way to see how to correctly configure ExtJS code and I continue to look forward to new releases. It will be great when it's at the point I am able to ditch a third party editor and can edit/generate/launch browser all in the designer.
7 Mar 2012, 2:36 PM
The dropdown contains only Base class/JSON/Implementation + any basic functions and overrides. initComponent does not appear as an overrideable event. If this is a trick I am missing, please let me know.
Upgrade to 309.
You can then create specific overrides for your generated class.
7 Mar 2012, 6:36 PM
At the risk of stating the obvious, yes, that works. The upgrade to the application went without a problem.
Powered by vBulletin® Version 4.1.5 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.