dojox/app needs to support application data in the url to allow urls to be shared. about dojox_application

[edchat]

Eric Wang suggested the following regarding this:
I think current dojox.app has no support for this requirement, so if we want to support, we should update the code to support it.

In my mind, to support this, we need to update History and Transition controller, maybe the View if we want to store the parameters in View instance.
When do a transition, the History controller will get the url detail with the parameters, see

1. program style

var transOpts = {
        title:"List",
        target:"items,list",  // show transition views
        url: "#items,list&parameter=..." // you can add url parameters in url property.
    };
new TransitionEvent(domNode, transOpts, e).dispatch();

2. template style

 <li dojoType="dojox.mobile.ListItem" clickable="true" transitionOptions="{title:'generate',target:'generate',url:'#generate&parameter=...'}">
       Simple Form Generate
</li>

3. in History controller (onStartTransition()), the transitionOptions will store in history state by HTML5 pushState
4. in onPopState(), we can get the paramters by url=evt.state.url, by comparing with evt.state.target, we can get the parameters in url
5. add a transition parameter in Transition controller, so we can trigger the transition like:

// transition to the target view
            this.app.trigger("transition", {
                "viewId": target,
                "parameters" : parameters in url,
                "opts": lang.mixin({reverse: false}, evt.detail)
            });

steps 3~5 is the same to HistoryHash controller, but in HistoryHash, we store the parameters in:

this._historyStack.push({
                'hash': currentHash,
                'url': window.location.href,
                'detail': {target:currentHash}
            });

so be careful with this _historyStack because HistoryHash only maintain the stack in one application lifecycle. (DO NOT refresh the browser, that means browser's history stack out of _historyStack, this is the HistoryHash controller's limit.

[msmiths]

Hi Ed,

I think that we need to be very clear about what is being proposed here since the parameters look very much like URL query parameters.

I assume that we are NOT proposing to add these as URL query parameters since the resulting structure of the URL would not conform to the syntax defined by RFC 1808, as follows:

    <scheme>://<net_loc>/<path>;<params>?<query>#<fragment>

In other words, the fragment portion of the URL must occur at the end of the URL. Also, only the fragement portion of the URL is not considered to be part of the URL... which is why programmatically modifying the fragment is not considered to change the location. Obviously, the query portion of the URL is considered to be part of the URL and modifying it would force a browser request.

So... as long as we are not proposing using URL query parameters then I think that this could work.

[edchat]

Hi Martin,
Thanks for the feedback, you are right, it does look like a query parameter, but it would be part of the #. Do you think it too is confusing? I think it is ok, but maybe we should we use something other that & for the &parm1=xxx if it is confusing.

[cjolif]

I guess the syntax is really an "internal" thing? People are not supposed to interpret themselves the # fragment, so having the syntax a bit confusing should not be too bad?

[edchat]

Well it is not really internal, the developer would create his transition with something like this:

        var transOpts = {
            title : "repeatDetails",
            target : "repeatDetails",
            url : "#repeatDetails&cursor=" + index
        };
        var e = window.event;
        new TransitionEvent(e.srcElement, transOpts, e).dispatch(); 

So they have to know that adding &cursor=" + index will end up giving back index for this.parameter["cursor"] inside the view.

[cjolif]

Shouldn't we have an API to build the URL for him?

[edchat]

I guess we could what did you have in mind?
Note that the transitionOptions can also be set up declarative. like this:

                <li  data-dojo-type="dojox.mobile.ListItem" clickable="true" class=mblVariableHeight
                    data-dojo-props="onClick: function(){todoApp.showItemDetails('#{this.index}');}"
                    transitionOptions='{title:"Detail",target:"details,EditTodoItem",
                                    url: "#details,EditTodoItem&itemId=#{this.index}"}'>  

[msmiths]

Hi Ed,

So I have no problem that it looks like a query parameter since this will be familiar to most people.

I am concerned that we want to handle the list of view names differently to the way that we handle application data, i.e., a comma separated list as opposed to a name/value pair. I have mentioned to you via email that I am not keen on the fact that the "application structure" appears to be built into various aspects of the implementation, e.g., the way that view ids seem to be generated based on the configuration such as serviceRegistryMobileApp_charts_list. The list of views that get included in the URL fragment is also an example of this. If we could assign unique ids to each view in the configuration then we could specify this as a name/value pair and declare the corresponding parameter name to be reserved by the dojox.app framework, e.g., xyz#viewId=ChartsList&param1=value1&param2=value2, where viewId would be reserved for use by the framework.

Thoughts?

[edchat]

I created another pull request #45
So with this update the transitionOptions can have an optional params object with the params which we will build into the url, and if the url is not passed it will be created from the target.

        var transOpts = {
            title : "repeatDetails",
            target : "repeatDetails",
            //url : "#repeatDetails", // this is optional if not set it will be created from target   
            params : {"cursor":index}
        };
        var e = window.event;
        new TransitionEvent(e.srcElement, transOpts, e).dispatch(); 

[edchat]

msmiths,
I am not sure I understand your point about the viewIds being generated, I am not sure where you are seeing that generated id, maybe we need another issue to look into that?

   Regarding adding a name/value pair for the views, I am ok trying to adding viewId for the views (assuming I can get it working), but we need to support child views as well, so I guess we could have more than one viewId="vid".  So I guess we could have something like this:

xyz#viewId=ChartsList&param1=value1&param2=value2,viewId=ChartsItem&itemparam1=itemvalue1

In a conversation with dmachi he suggested this to be able to specify which view params go with, so that is probably something else that would be good to add.
#view(params),secondView(params)

dmachi What do you think about trying to use name/value pairs for viewId to specify the view?

Thanks,
Ed

[msmiths]

Hi Ed,

So I see the generated id when I am debugging my application... and I have also had to write a helper function to allow me to find a given view within my application, starting at the application level since I know the name of this global.

In the Chrome Developer Tools debugger, I can see that id of the view is constructed using the id of the application and the ids of the all of the views in the chain. This is also used as the key in the associative array used to store the views in the "children" attribute of the objects. So, my helper function looks like this:

_getView : function(app, childViewName) {
    var view = null;
    if (app && app.children) {
        for (var name in app.children) {
            if (name == childViewName) {
                view = app.children[name];
                break;
            } else {
                view = this._getView(app.children[name], childViewName);
            }
        } // FOR
    }
    return view;
},

I can also see that the "name" attribute for the view objects is just as it appears in the configuration... so I could have implemented the helper function to take an array of view names and used those to walk the hierarchy of view objects, but I thought that using the id was simpler.

Either way... my assertion remains that I should not have to understand the structure of my application in order to construct the id for a given view, I should be able to specify the id that I want to assign to each view as part of the configuration for that view. Also, I should not have to implement my own helper functions to navigate objects in the framework... the relevant application and view classes should provide the relevant functions that allow me to find views (or other framework objects such as models or stores) within the hierarchy.

Thanks.
Martin.

[edchat]

Hi Martin,
I have copied you previous comment into #47
So we can discuss that in Issue #47, and the app data params support here.

After talking to dmachi and jolif about this, I will make some changes to the implementation, basically instead of mixing the params into the View when it is created, and setting them on the view during a Transition, we will call view.update(params) on the view so that if the view wants to do something when update is called it can override the update and handle it as needed. I will create a default update function in View which will set this.params = params;

I have not made any changes to the url to identify the view in the url because once we got into a discussion about the viewId the number of changes grew, for now I have left it like this for now:
#repeatDetails&cursor=2
So for one with a child view, it would be something like:
#details,EditTodoItem&listid=1&itemid=3
I could try to do something to match the params to a view, but I don't think I want to try to specify a view id for the view for now. So something like viewId= probably does not make sense, I guess I could do view=, so it would end up with something like this:
#view=repeatDetails&cursor=2
#view=details&listid=1,view=EditTodoItem&itemid=3

[edchat]

I have made updates in this branch, but I don't think this is ready yet.
https://github.com/edchat/dojox_application/tree/urlAppData

[msmiths]

Hi Ed,

The W3C Technical Architecture Group which monitors the evolution of the Web architecture has recently published a summary of Best Practices for using hash URIs.

http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20111201

I believe that this is very relevant to this discussion. One of the quotes states:

"... in many cases, the use of query parameters along with the new HTML5 functionality mentioned above is preferable to fragment identifiers to identify application state."

Thoughts?

Thanks.

[edchat]

I think the last thing we need to verify is that it is possible to have params for multiple views, and see how that would be managed by the app. We need an example showing how to set params for multiple views, and we need to doc it.

[edchat]

Support for params for a specific view has been added now. So I am going to close this.