In Uploader, we have a nice little mini-component that handles the
vertical scrolling of an overflow element. Based on some code that I
wrote a long time ago, it does what we need for Uploader; initialize
it with a container, pass in an element, and it will ensure that the
element is scrolled into view.
I started to think about how to expand the functionality: mostly
adding the ability to specify elements by index, and adding some
predefined literals for relative position (next, previous) and
absolute positions (first, last, top, bottom, etc.)
However, there is a jQuery plugin, scrollTo, written by Ariel Flesler
(of the jQuery team). Nice bit of code. Also does everything that we
need in Uploader. Doesn't have the predefined literals that I wanted
to add, but it does handle elements by index. It also handles a lot of
stuff that we don't currently need, such as scrolling by pixels,
animation, vertical and horizontal scrolling and window scrolling. So
there is a lot of functionality that we could use in the future.
It does all this with barely double the weight of our code.
What it doesn't do, which our scroller doesn't do yet either, is wrap
an element that currently doesn't scroll in the markup that would
allow it to scroll. Easy to add to our code. To add it to the jQuery
scrollTo plugin, I'd probably want to wrap the code in our own initer
as opposed to extend the scrollTo code ourselves.
Anyway, I have three choices before me:
1) Continue to expand our own code as we need new functionality. There
really isn't that much more to do to support what we already have.
2) Use the jQuery scrollTo plugin, out of the box. Use the
functionality we need and ignore the rest but know that it's there for
the future.
3) Use jQuery scrollTo plugin but wrap it in our own initer so that we
can create new scrolling elements on the fly.
I'm leaning towards #2. I think that there is great benefit in
leveraging great bits of functionality already out in the world.
Nothing precluding #3 in the future, I'm just not sure that we gain
that much by doing it now.
So I put it to the group. Any reason in this case to grow our own?
Thanks,
Eli
. . . . . . . . . . . . . . . . . .
.
Eli Cochran
user interaction developer
ETS, UC Berkeley
"Do not solve the problem that’s asked of you. It’s almost always the
wrong problem."
- Don Norman
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
