Showing results for 
Search instead for 
Do you mean 
Community Home Request Access Read Blogs Share Your Ideas Search Community View My Settings
Reply
Highlighted
Copper Super Contributor
Posts: 29
Registered: ‎10-14-2010

Interesting thing about the Mobile Client's Edit Pages

I was fighting a problem on Friday that I just figured out today. It looks like the querySelect in the Edit screens isn't actually used on the HTML5 mobile client. Instead, it just uses the same query from the related Detail form. I have a few situations where I want to show other info to edit on the Edit form than what I'm showing on the detail form. I realized it kept coming up blank because I wasn't including these items in my querySelect on the detail form.

 

Is this a bug or is it intended behavior?

- Geek -
Highlighted
Bronze Contributor
Posts: 95
Registered: ‎07-11-2011

Re: Interesting thing about the Mobile Client's Edit Pages

That is the intended default behaviour. A typical Edit view would be accessed via: Detail -> Edit, or List -> Insert.

 

If it is the List to Edit (Insert) then Edit view makes a SData $template request for the entity's default values - querySelect is used here for this request.

 

For the Detail to Edit, the SData entry from the Detail is passed in the navigation options. In typical cases another request would be duplicating what was already requested -- so this approach cuts down bandwith usage (which is key for mobile).

 

In the special cases where an Edit view needs an extra one or two properties then I'd just add them to the Detail view request, this keeps it to one trip to the server with the least amount of overhead. The entire response is stored and passed along so even if you don't display the data in the Detail view anywhere it'll still get forwarded.

Highlighted
Copper Super Contributor
Posts: 29
Registered: ‎10-14-2010

Re: Interesting thing about the Mobile Client's Edit Pages

I thought that might be the reasoning behind it. Thanks for the response.

- Geek -