<FromGitter>
<nsuchy> I mean I was just gonna make a bootstrap pagination list based on the size of the array and bundle the methods into Amber::ECR::Pagination or something
<FromGitter>
<nsuchy> this is still being worked on, it's a list of customer transactions
<FromGitter>
<nsuchy> only thing pagination needs is a page count
<FromGitter>
<nsuchy> you'll have to tell Granite how many skips to run using offset (btw @Blacksmoke16 can I add a psuedomethod named skip, it makes more sense than offset, it can literally pass the data to the offset method, it'd be nice activerecord style method)
<FromGitter>
<nsuchy> I have ⏎ ⏎ ``` page_number = 0 unless page_number = params[:page_number].to_i64``` ⏎ ⏎ But still get the error `The page_number param was not found, make sure is typed correctly.` if I don't send the param [https://gitter.im/amberframework/amber?at=5df67c3042784416abf198e3]
<FromGitter>
<nsuchy> Is there any way around this or will I have to update my links to include a page number
<FromGitter>
<Blacksmoke16> is it a query param?
<FromGitter>
<Blacksmoke16> id also add buttons to go to the first/last pages
<FromGitter>
<nsuchy> @drujensen this seems pretty generic to me. The user needs to provide the following information: a page_count variable and support using ?page_number in the query. Then on the Granite/ORM side they will need to add a limiter and keep in mind the page number to know how many rows to skip. That's not really an issue for the pagination library to worry about though
<FromGitter>
<nsuchy> Think I could add it as a PR to Amber so there's built in pagination to the view engine
<FromGitter>
<nsuchy> Even if it was just a new partial added to the default generator
<FromGitter>
<nsuchy> The problem really goes back to this is up to the user to implement
<FromGitter>
<nsuchy> Inexperienced coders might not think of adding a limit or choose to ignore it if it's not handled for them as it takes up additional development time and they don't see the security benefits
<FromGitter>
<Blacksmoke16> im not sure i agree on not doing something just so inexperienced devs dont have to think
<FromGitter>
<Blacksmoke16> the implementation would just have to be an upper limit, with a dropdown that has like 10, 20, 50 in it or something
<FromGitter>
<Blacksmoke16> i.e. pagination should accept any between min and max
<FromGitter>
<Blacksmoke16> but the dropdown is there just as a shortcut
<FromGitter>
<Blacksmoke16> i dont really care either way, just my 2 cents...
<FromGitter>
<nsuchy> but it's bad if a miscoded dropdown list resulted in the entire app being breached
<FromGitter>
<nsuchy> it's the reality of many PHP apps that don't use ORMs
<FromGitter>
<nsuchy> they forget to escape / limit inputs
<FromGitter>
<nsuchy> and the apps get hacked
<FromGitter>
<nsuchy> let's not make our framework resemble the problems of PHP
<FromGitter>
<Blacksmoke16> right so make it optional, or have a configurable default?
<FromGitter>
<Blacksmoke16> worst case here is the current behavior no?
<FromGitter>
<Blacksmoke16> where all the results get returned versus being paginated
<FromGitter>
<nsuchy> I mean, right now all the pagination element does is track the current page and build an element based on the page count
<FromGitter>
<nsuchy> what you do database wise is up to you
<FromGitter>
<nsuchy> yes, I changed my github username
<FromGitter>
<nsuchy> seperating work stuff from personal life
<FromGitter>
<drujensen> gotcha. :-)
<FromGitter>
<nsuchy> so currently it's up to the developer to choose a limit and implement and all that
<FromGitter>
<nsuchy> they can still make a bad decision, adding the dropdown might encourage it, I'm not convinced providing a choice is necessary, let the user choose a reasonable default, whether that's 10, 100, 1000, or anything
<FromGitter>
<Blacksmoke16> that would be the mvp route
<FromGitter>
<drujensen> I agree.
<FromGitter>
<nsuchy> but uh adding the _pagination partial would at least reduce the amount of work devs need to do when using amber
<FromGitter>
<nsuchy> there is not a pagination shard at this point
<FromGitter>
<nsuchy> I could make one but I don't think we need a dedicated shard when a good partial can do the same thing
<FromGitter>
<nsuchy> the user just needs to make sure two variables exist and do some counting in the controller
<FromGitter>
<drujensen> nope. It makes sense to add this to our default templates imo
<FromGitter>
<nsuchy> yeah that's the goal of my PR
<FromGitter>
<nsuchy> I might need help with the slang template later on
<FromGitter>
<nsuchy> I've never used it and prefer HTML with variables
<FromGitter>
<nsuchy> I'm old school like that lol