Re: Re: Data_Pagination

Andrian It is best to communicate with the developer of PAGER and work alonside an already published package, maybe your code should be incorporated into the PAGER package to allow a lighter interpretation if possible, or suggest areas to the PAGER developers where they can lose some methods that add bottlenecks. Also PAGER is inherited by quite a lot of other packages such as Datagrid. The proof however is in the pudding - do some Benchmarking please on using your package and then using the PAGER package, I certainly am very keen on finding the quickest ways to do the simple jobs, as these are usually the ones that are used the most. Also small point I use Slider in all my paging :) Ian Andrian Zubko wrote:

yes, i saw this package before, and not insist on my.. ps: i only readed in PEAR FAQ about competitive packages, and has think, what is not bad idea to put package, what solves a same problem, but with another ideology..

Justin Patrin:

I'm glad you read it. :-) Could you explain what is different about your package's ideology from Pager?

difference is simple. my package was maked with general ideas of: - using minimal arguments/properties/methods without needed functionality lost. simple API is more easy to understand and use;

      only 18 items (4 arguments and 14 properties) and in the same time possible to construct navigation panels with little more functionality then Pager (pageOfPrevSet, pageOfNextSet) *

- using only customized output via template processor (or same PHP);

      sure, it possible to output HTML in the same place with logic. but, IMHO, it less correct way

- name of package, arguments/properties/methods names and other things, should not confuse the programmer to use this package in other (not web sites) applications; - it should be not "monster" package.

      if calculation of some parameter is very simple, then no need to create more methods/properties. as example, i have removed 2 properties (what was before): shownFrom and shownTo. becouse it the same to: startOfSlice + 1, endOfSlice + 1. IMHO, it is a good way to make simple and light API.

--- (*) - i making comparison only with Pager "jumping" functionality, becouse Data_Pagination don't have Pager "sliding" functionality. IMHO, it not demanded. but, if i wrong, then adding this functionality to Data_Pagination will be very easily. for programmer will be on one, optional, argument more in constructor, all code for working with this package no needs to change.