Pagination Macro

[TSG]

Has anyone successfully made a good pagination macro?

Thinking of adding it to the templates eventually, and limiting folders to 50/Page or something.

It will solve a limitation of jQuery I am finding, if there are too many files it causes some lag when you initialise a script, especially if more than one thing is happening at once. I have tried all sorts of methods and have managed to make my scripts run fine up to around 1000 files in a single directory (stupid I know, but searches might cause this). The browser can crash if it runs out of memory.

I can't be bothered programming it myself, but I have seen it done.  Also if this is in the wrong section, fair enough move it to the template board, but maybe its too complicated for that...

[rejetto]

do you think the default template has performance problem with paging?
i just tested with a 3k files. It's a bit slow.

[TSG]

The default template loads the entire directory then paginates it with javascript, if I am correct? I was more referring to real pagination, using the server and macro... I couldn't find anything related to it when I was looking.

Tested the default template, and its ok, but I don't think I could use that script with something like live... same page load time, and doesn't achieve the limitation on the poor javascripts! lol, If you have time I can show you what its like.

I would have thought a macro would be used to only load the limited number, maybe using ajax? Rather than loading them all.

[Mars]

I want to make a small reminder on the mode of pagination:

In the version which I had proposed, I used at most the possibilities of the macro by reading the entire directory. The main work of display making in the  browser for more fluidity.

I want to put back in memory of tsg ( without wanting to offend you  ) that to read a whole directory sets certain time by hfs and that the more this one is important, the more it lasts.

It is possible to use filters to feign the mode page, but the more the number of files not to be taken into account is important, the more the waiting time of the browser is long , and it is inescapable in the present state of the programming of hfs, any script so successful is will can nothing against that.

The only viable method at the moment is: we take the whole and we make the sorting later.

To the javascript programmer to be rather cunning to optimize the sorting. Naturally it is possible to increase the number of marks for every item to be shown to facilitate the work of the browser.

 

[TSG]

Haha, reading your translated posts are always interesting, but I get the idea!

This is true, the only solution we came up with was one with ajax, where each pagination link would call the entire directory but use the offset url var to only load in certain parts to the browser.

Other than this I can't think of a better way, unless rejetto creates a specific macro for pagination, that actually uses internal functions of HFS to break it into pages by a set limit, then prints out how many pages. Something like the breadcrumb macro, maybe it can use url vars, /?page=1.

Just throwing around ideas

[Mars]

Haha, reading your translated posts are always interesting, but I get the idea!

The reverse is true also for me

your post translated to french

Haha, lisant vos postes traduits sont toujours intéressant, mais j'obtiens l'idée!

C'est vrai, la seule solution que nous avons inventée était un avec ajax, où chaque liaison de pagination appellerait l'annuaire(le répertoire) entier, mais utiliserait la compensation url var pour seulement charger dans de certaines parties au navigateur.

En dehors de cela je ne peux pas penser à une meilleure voie, à moins que rejetto ne crée un macro spécifique pour la pagination, cela utilise en réalité les fonctions internes de HFS pour le casser dans des pages par une limite de jeu, imprime ensuite de combien des pages. Quelque chose comme le macro de miette de pain, peut-être cela peut utiliser url vars, / ? Page=1.

Juste lancement autour d'idées

and the reverse 

Haha, reading your translated posts are always interesting, but I obtain the idea!

It's true, the only solution which we invented was one with ajax, where every connection of pagination would call the directory ( the directory) integer, but would use the compensation url the Var to load(charge) only in certain parts(parties) to the sailor(browser).

Except it I cannot think of a better way, unless rejetto create a macro specific for the pagination, it uses in reality the internal functions(offices) of HFS to break him(it) in pages by a limit of game(set,play), prints then of how many pages. Anything as the macro of breadcrumb, maybe it can use url the Var,/? Page=1.

 

[bacter]

Even the best pagination macro or the use of ajax still needs to read (and sort !) the whole directory on the server with every request.

I think the fastest system will be to read the directory only once, and use on the server a macro that builds blocks with labels so that each block contains up to a number (18,22,nn) of file entries. Then on client side, with javascript all blocks but one have set the attribute hidden, and with the script you toggle on an index or with next/previos what block gets the attribute screen.

[rejetto]

bacter is right.
you should first find the bottlenecks, and see what can be truly improved.
i don't know if i should rework the whole thing just to optimize the use with thousands files in a single folder.
if DOM construction is taking long, then there is room for improvement, you can generate the list as a javascript array, and build only the few items needed for the page.
problem is: making it compatible with no-script.

[LeoNeeson]

Yes, I know TSG doesn't visit this forum since long time ago, but if he does, this problem it's still discussed here too. Maybe Mars has anything new to say...

[Mars]

yes Man, this is an old post, 6 years ago