- are no provisions to make "group-by" views
- there are limitations to the Boolean operations in the url strings: for example with view criteria you can do much more
- the strings can become very long, complicating programming and possibly hitting built-in limits
- the url strings are shown in the browser
- it just looks sloppy
- it exposes some of the code logic
- it enables users to experiment with criteria changes in the browser, potentially exposing data he should not see
I'm suggesting new aspects when using
openUrl in deluge.
1. Offer a box to click to obfuscate the url string: In other words, the url would just appear in the browser as the application/view/form url. Server-side processing of the actual url is performed to deliver the customized view.
2. Offer a space to add code, much like we do with view criteria, to filter a url's view.
Items one and two are mutually exclusive and only work from withing the application context. Item 1 a feature that could be added to all openUrl's currently used in ZC code. I cannot think of any instance where complicated url strings are necessary to display in the browser window - maybe with the exception of iCal feeds. Item 2 can only work with views of data and may have to be a new deluge command, like openCriteriaUrl.
I'm also suggesting new aspects outside the application context. For example, if you email someone a link to a view (or form), it will necessarily display ugly url strings with criteria. There's only two ways to deal with this
3. Set-up a list with code numbers in one column and the intended url string in another such that the email's url looks something like
creator.zoho.com/admin/mydata/My_View/_zcParams=1357983 where code 1357983 would then present the user with a view (where the url criteria is hidden)
4. Upon clicking a criteria-laden url in an email (or website), ZC would immediately employ Item 1 above, essentially reloading the page with the criteria hidden.
Cheers,
John Whitney