Comments (16)
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
- program style
var transOpts = {
title:"List",
target:"items,list", // show transition views
url: "#items,list¶meter=..." // you can add url parameters in url property.
};
new TransitionEvent(domNode, transOpts, e).dispatch();
- template style
<li dojoType="dojox.mobile.ListItem" clickable="true" transitionOptions="{title:'generate',target:'generate',url:'#generate¶meter=...'}">
Simple Form Generate
</li>
- in History controller (onStartTransition()), the transitionOptions will store in history state by HTML5 pushState
- 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
- 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.
from dojox_application.
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.
from dojox_application.
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.
from dojox_application.
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?
from dojox_application.
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.
from dojox_application.
Shouldn't we have an API to build the URL for him?
from dojox_application.
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}"}'>
from dojox_application.
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¶m1=value1¶m2=value2, where viewId would be reserved for use by the framework.
Thoughts?
from dojox_application.
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();
from dojox_application.
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¶m1=value1¶m2=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
from dojox_application.
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.
from dojox_application.
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
from dojox_application.
I have made updates in this branch, but I don't think this is ready yet.
https://github.com/edchat/dojox_application/tree/urlAppData
from dojox_application.
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.
from dojox_application.
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.
from dojox_application.
Support for params for a specific view has been added now. So I am going to close this.
from dojox_application.
Related Issues (20)
- Problem with a scrollable view where it scrolls down a little when transitioning to a view which was scrolled to the bottom. HOT 3
- Problem on IE with History and HistoryHash when transitioning back to the default view. HOT 2
- There is a problem with the has based config support on IE. HOT 1
- History should have a config option to automatically create the full url hash from the selected children on the app. HOT 1
- build system enhancements HOT 1
- The app build support was not updated to deal with the has-config support when it was added. HOT 4
- iOS VoiceOver Support HOT 1
- Preloader Application on first load and on View switches HOT 3
- borderLayoutApp test file name issue HOT 3
- Transitioning View Fails Randomly HOT 11
- There is a problem with the Transition controller when transitioning across nested views. HOT 1
- beforeDeactivate and afterDeactivate can be called for a view on the initial display without ever calling beforeActivate and afterActivate HOT 2
- app build support gets an error if a template file is used by more than one view.
- View beforeDeactivate, afterDeactivate, beforeActivate, and afterActivate are not always called correctly for nested views. HOT 1
- Problem with a multipart defaultView set on a child of a nested view. HOT 1
- Lazy-loaded views "flash" into view when initially placed HOT 5
- Check in transition to check for matching views can fail with nested views. HOT 1
- dojo 10.0.1 was released HOT 1
- dojo 1.10.3 release HOT 1
- ScrollableView issue on imageupload from Android
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dojox_application.