quick design question for those that are interested. as we start to add
more paging capabilities we can decide how we want that paging to be
controlled. right now there seem to be 2 possibilities ...
1. accept 2 query params, offset and length. the offset determines the
point in the collection to start from and the length determines how many
values to show in the view. i.e. /<weblog>?offset=10&length=10 would
show the second page of a 10 items per page view.
2. accept 1 query param, page. the offset and length are calculated
internally based on the page number. i.e. /<weblog>?page=2 would be the
second page
we can do either, however in the urls proposal and in my mind i have
been opting to use #2 for these reasons ...
1. we already know the length for any page, its' defined by the
weblog.entryDisplayCnt attribute. so we can easily calculate the
offset/length with this single parameter.
2. allowing direct use of the offset/length params could be more
dangerous considering that some users may attempt to hack those
variables and use obscure values like offset=12 and length=777.
3. i think using a single page param is easier on us and makes the urls
a little easier to read.
4. it's also a bit easier to allow users to define a max # of pages to
allow for any collection, like how many pages back in time they would
want someone to browse their recent entries.
so, anyone have any reason why we shouldn't just stick to using the
single "page=X" query param to do paging?
-- Allen
- paging query params ... offset/length vs. page Allen Gilliland
-
