davidjnelson / angular-table

An angular directive for a table with fixed, sortable headers, row selection, row even/odd coloring, which automatically stays the correct height relative to its container when the browser is resized. No javascript code required; the api is a 100% declarative dsl.
http://angulartable.com
174 stars 30 forks source link

Server-side pagination #9

Open tekumara opened 11 years ago

tekumara commented 11 years ago

This would be a great feature. Have you any thought on how this might appear in the DSL?

davidjnelson commented 11 years ago

Hi Oliver, for my app, my data is static and small enough that I can cache it in memory. my thinking so far is that if it gets larger, I can virtualize it (swap in and out of Dom, see issue 1), and add a filter on the data to allow searching through it. it might be useful to make it easier to specify a bound model that does filtering.

for data sets that change frequently, I could see server side filtering being necessary.

which style would you use in your app? thanks.

gdiazlo commented 11 years ago

Pagination is useful in more ways. For example, being able to link something like /table/4 to get page 4 of a paginated table, could be really nice.

davidjnelson commented 11 years ago

I see, being able to use it with routes. makes sense. would you use this feature in your apps?

gdiazlo commented 11 years ago

To get angularjs-table to work for my current application i would need filter, pagination and this one. I'm not proficent enough with angular to contribute code in the angular-table style :(. I like the angular-table idea and how it works, but can't use it as it is now.

tekumara commented 11 years ago

Hi David, sounds like there's some different use cases here. In my use case the data is relatively static, large, and expensive to generate the whole dataset on the server. So I was thinking of being able to fill the table with paged subsets generated by the server. Filters would also run on the server. Because it's relatively static, once fetched it could be cached on the client.

davidjnelson commented 11 years ago

thanks Everyone. this has gotten enough interest that I will certainly add it as a new feature (updated its status).

Let's have a quick chat about use cases and potential implementations and see what people would use.

@gdiazlo Currently you can filter the data in memory. Pass filter-query-model="filterQuery" with the expression you want to use for filtering to the angular-table tag. Do you need server side filtering too? Regarding being able to link something like /table/4, I think the best approach here is to be able to $broadcast an event down the scope which would load that table subset, and the outer application would manage the routes itself. What do you think? Also, are you saying that you would like the table to expose a ui for switching between pages in the table (ie: 1-10 as page 1, 11-20 as page 2), making an ajax call on your behalf each time the user clicks one of these?

@tukushan Cool, I dig it. There is issue #1 which covers paged sets. Regarding paged subsets generated by the server, that is an interesting idea. I'll think about the best way to do this (would love to hear your thoughts) and when I have a design I'll add it as a seperate issue.

gdiazlo commented 11 years ago

I'll llook again into the filtering thing, thanks a lot!

So you mean:

a) user GET /table/page b) angular route it to a controller which loads the data set selected in the route, or slices an already present array, etc. (right now i don't need server support, but its a posibility for near future) c) the user click on "next page", and the table code emits an event. The controller needs to listen for it, and update the data set accordingly.

Something like this would be fine. I would love a sample on how to avoid boilerplate in controllers related to table management. I have a lot of tables in the crud part of the application. And repeating the same code on each controller doesn't look like the best way to do it.

Regarding the UI part, I would need either pagination or inifinty-scroll-thing, the page needs to work on mobile devices, and huge invisitble tables are not a good thing generally, basically the thing is having a small dom if possible.

As i'm a newbie in web development, i can be totally wrong so I'm open to advice ;)

thanks a lot,

leoman commented 10 years ago

Hi David, I wanted to ask if this issue was likely to have some attention on it in the near future? I really like your implementation of angular tables after looking at yours, ng-table and smart table, yours seems by far the most robust. Your version currently does two out of three extra's that I require, sorting and filtering, and only requires pagination also. If this is unlikely to be added anytime in the future, I may attempt to fork it, but just wanted to check if this was already underway?

Thanks

Peter

davidjnelson commented 10 years ago

Hi Peter,

I haven't had much time to work on this unfortunately. When you say pagination, what exactly would you like to be able to do? There are a few approaches to this, which best fits your use case?

Thanks, David

jorgecas99 commented 10 years ago

@davidjnelson could you paginate like you do with ng-tables? I love the ability to control the table via markup but when dealing with a 2000 record table, it would be nice to enable the pagination and have a recordPerPage=num. I wonder how straight forward it would be to port the code from ng-tables to angular-table to allow pagination.

davidjnelson commented 10 years ago

Thanks @jorgecas99 , I can take a look at the api for how ng-tables does it. Great strategy, sounds like it would work well for your use case. It's looking like I may have some time soon to work on angular-table and fix a number of bugs and feature requests in the near future (fingers crossed).

coli commented 10 years ago

One way I done it before is for the table directive to support a data fetch function. Every time a page/sort/search occurs, it fetches the data. The server fetch path may not be compatible with the non server fetch path though.