Add pager element to browser tab forms [#692618]

Comment #1

aaron CreditAttribution: aaron commented 28 January 2010 at 22:51

Status:

Active

» Needs work

OK, so I have the pager in there. Unfortunately, since it's an AJAX page, all the returned page links display json on the screen...

Log in or register to post comments

Comment #2

aaron CreditAttribution: aaron commented 28 January 2010 at 22:53

maybe going through drupal's ajax framework would help, and/or ensuring drupal behaviors are called. or maybe using PUT rather then GET, and/or sending a 'js' query parameter so we know whether to send as json or html...

Log in or register to post comments

Comment #3

aaron CreditAttribution: aaron commented 28 January 2010 at 22:53

Issue tags:

+alpha blocker

Log in or register to post comments

Comment #4

JacobSingh CreditAttribution: JacobSingh commented 29 January 2010 at 06:34

can we discuss this design change?

-J

Log in or register to post comments

Comment #5

aaron CreditAttribution: aaron commented 29 January 2010 at 14:37

there are four alternatives that i can think of to handle 10k files on a system:

1) display them all.
2) use a pager.
3) use a button to load the next dozen (see http://www.flickr.com/photos/mverbaar/3635449850/in/set-72157620755726297/ )
4) autoload them on scroll like bing does.

take your pick :D

Log in or register to post comments

Comment #6

aaron CreditAttribution: aaron commented 29 January 2010 at 14:39

when we have exposed views filters integrated, that'll be another option of course.

Log in or register to post comments

Comment #7

JacobSingh CreditAttribution: JacobSingh commented 29 January 2010 at 17:43

I like #4 personally, I think open to whatever... I also want to just make sure that we've got the right approach and that we do any browser refactoring first. But don't let that slow you down, just concerned from your earlier posts that it might be getting kludged in, and I want to make sure we've got something flexible enough to do what you're thinking.

Best,
Jacob

Log in or register to post comments

Comment #8

aaron CreditAttribution: aaron commented 29 January 2010 at 19:35

i really, really want to build this with FAPI -- it would offer greater flexibility, i believe, in be in line w/ everything else in drupal. (especially so as to more easily allow things like filter/sort/etc, as in http://www.flickr.com/photos/mverbaar/3847955749/sizes/o/in/set-72157621... )

i'll start on a new tab as a proof of concept, and keep out of the current default library tab for now.

Log in or register to post comments

Comment #9

JacobSingh CreditAttribution: JacobSingh commented 30 January 2010 at 05:43

I'm okay with that, but also, we have something that works. I don't want to supplant it with something that doesn't or 1/2 works or looks radically different. And, I want to ensure a few things:

1. That we can pass settings and callbacks in via JS. I feel that's really important for flexibility. You start trying to pass settings for every plugin via GET params to the main iframe and it is chaos.

Also, we need to not make a lumbering giant on load, so that means ajax callbacks, and callbacks happening intelligently. If we're 100% certain that this is always just tabs, it's easier to envision. But I'd like to have at least a hybrid approach wherin you have some hardcoded display login in PHP, but the option of attaching JS classes which can respond to events and/or override the callbacks that being made is very powerful.

I know that most Drupal stuff likes to define anonymous arrays, hardcode the markup that they will generate, and *then* load JS around that HTML for animations, etc. This is one approach, but not the approach most JS-based applications take. Wherein the application framework is in Javascript, and callbacks happen only when you need to get/set some content on the server.

I don't see where FAPI brings any improvements other than people being able to form_alter the markup before it comes out. I'm fine w/ working on a prototype, but please consider my feelings on it, since I spent a lot of time getting this *working* and working pretty well.

Also, I suggest if you are prototyping, start with the hardest tab first (the library).

Best,
Jacob

Log in or register to post comments

Comment #10

aaron CreditAttribution: aaron commented 31 January 2010 at 18:01

My overarching concern is for things like http://groups.drupal.org/node/36970#comment-123464 where I'm concerned that if the API is too difficult to extend, it will stay dead in the water from the standpoint of attracting future development.

Additionally, I want to do a simple thing like Vertical tabs, such as with http://www.flickr.com/photos/mverbaar/3847955749/in/set-72157621994336405/ and am finding it virtually impossible.