View duplication when using URL Parameters.

Hi Rodrigo,

Currently, the behavior you observe is by design. Kendo UI Mobile treats different URLs (although different only in the query string parameters) as different mobile views, and performs a new HTTP request to fetch the data. This approach makes sense in case you are using the query string parameters on the server to return new content. 

However, what you expect also makes sense. We are considering changing (or at least providing some sort of a configuration option) in order to handle it in the manner you expect.

Regards,
Petyo
the Telerik team

Hi Petyo,

This is not the way it used to be in versions of KendoUI before 2012.2.913.
This new behavior breaks our current application since our elements are duplicated and our bindings get applied to the old view, not the new one.
How do you suggest we remove the old view prior to generating the new view? Or prevent the addition of a new view and the hiding of the old one?


I would like to provide an example of how we currently do things.
We use query parameters to return new content from the server but these are served from within our application by using a datasource's read functionality.

The following function illustrates the process:

The actual app URL is used solely for navigation and "remembering" a user's choices in case of refreshing.
Each view's content depends on a selection made in the previous view, so if a user refreshes they would arrive at a view with no content. If that is the case our app reads the URL that it is at and uses the parameters in it to run the refresh function posted above as well as making the appropriate selection in each view.

This is an example of how different view's urls might look in our application:
app/index.html#view/view1.html?Id=1234
app/index.html#view/view2.html?Id=1234&Id=5678 app/index.html#view/view3.thml?Id=1234&Id2=5678&Id3=90

But if a user were to select a different option in view 1 then view 2 and view 3 might look like this:
app/index.html#view/view2.html?Id=1234&Id=1234 app/index.html#view/view3.thml?Id=1234&Id2=4321&Id3=87

(These parameters are unique IDs created by the server for each selection available.)
Essentially making a call to the server and setting our URL are two different processes within our app.

I hope that makes sense.
Looking forward to your advice.

Hi Rodrigo,

We have numerous forum posts regarding the same issue with Q1 and Q2 releases. In addition to that, I am responsible for that implementation, so I am certain that this behavior is not something we have introduced recently. 

Back to your question - as you use DataSource to fetch and refresh data in the same view, I would recommend making this view a local one. Ajax calls are quite slow and resource demanding on a mobile device, and having two ajax calls for a single page can make a difference. 

Using a local view will still preserve the URL requirement you describe, as the URL changes to reflect the current local view id. 

Kind regards,
Petyo
the Telerik team

I apologize, the behavior of creating a new view with different url parameters does not occur in version 2012.2.913 but it does occur in 2012.2.1002.
Before 1002 the data-url attribute of a view does not have query parameters. After 1002 that attribute does have query parameters.

I appreciate your advice, however we have already taken that into account. The only time an ajax call is made is when the first parameter changes (which is not often). All data needed to run the application is downloaded with that first parameter. The rest of the parameters are used for navigation only.
As you can see in the example I provided, the view is a remote view but it is still stored locally, no external ajax calls are made for its content.

Without a build step, is there a way to use local views in separate files?

We have a lot of views, so putting them in one file would be unwieldy.

Hello Rodrigo,

Even if the view is stored locally, an ajax call needs to be done to fetch it (from the local filesystem). 

Do you need any additional information regarding the subject? I hope that the change we introduce in Q1 would help in your case. 

Jonathan, a build step is a good option for the case you describe. 

Greetings,
Petyo
the Telerik team

Hey Petyo,

No, that's alright. I appreciate the advice, just one more question.

By the change in Q1, are you referring to what you said earlier on your first post?
"However, what you expect also makes sense. We are considering changing (or at least providing some sort of a configuration option) in order to handle it in the manner you expect."

If so I'll find a work around for the time being.

Thanks.

Hello Rodrigo,

Yes, this is the change I refer to. To clarify, our current vision looks like this:

- A remote view with the address foo.html?bar=baz is requested
- Next, a remote view with the address foo.html?bar=qux is requested

Right now, this leads to duplicate DOM elements as two indentical views are created. What we are going to do (and this will most probably be the default behavior), is to remove the previous view from the DOM before inserting the new one. This is not a perfect solution, because the remote view response may contain

- other (secondary) remote views, (what should happen to them?)
- Script and style elements - we read those too, and re-inserting the same scripts in the DOM may have unexpected effects. 

The other behavior, which has also been requested by some customers would be to treat the remote view as a local one, and just update its parameters, without performing additional ajax requests. As far as I understand, this approach would work in your case too. 

Hope that this makes sense.

Kind regards,
Petyo
the Telerik team

Hi Petyo,

I actually thought of implementing that first proposal as a temporary work around.
The second option is what would work best for us.

Thank you for your attention,
Rod

"treat the remote view as a local one, and just update its parameters, without performing additional ajax requests"

Keeping the behavior consistent for local and remote views is important to maintain simplicity and avoid the issues you mentioned.

One remaining problem I see is how do you manage cache busting?

I propose a third option:

Expose a method on the application object to determine whether or not to fetch a view. It would be passed the new url (and maybe old one) and return true or false. By default, have it setup so it ignores url parameters (like the local view / behavior described above).

Hi John,

Thanks for your suggestion. We will consider it when we start implementing the feature. 

Regards,
Petyo
the Telerik team

I have introduced a build step which integrates the views into the index page (so they are now local views), but I now have an issue where it thinks they are remote views.

The highlighted line of code removes the hash from the url which makes the showView method think it is a remote view:
local = url.charAt(0) === "#"

So it tries to fetch the view remotely (even though it is local).

NOTE: element = container.children("[" + attr("url") + "='" + url + "']"); is also a problem it should be 
"[" + attr("url") + "='" + local ? urlPath : "#" + urlPath + "']"

Hi,

I think that you can resolve that problem by setting the data-url attribute of the remote view when you inject them as local. You may do a little reverse engineering and examine how the remote views are detected. 

Please notice that such approach is not officially supported by the framework, so the implementation may change in future versions. 

Regards,
Petyo
the Telerik team

There is one change in the kendo source needed for local views with the data-url attribute.

In the latest build (2012.3.1304) there is a fix to ignore parameters for local views, but I believe you missed a place.
should be

Hi Johnathan,

The exact change you describe is already applied, but will be available in our next release, where the behavior we discuss here will be implemented. 

Meanwhile, feel free to patch your version in the described manner. 

Kind regards,
Petyo
the Telerik team