Before we endlessly argue together on what these scripts are meant for and on what a
sliding clipper might be, and therefore before going on like deaf men who speak each other void words, I'd presume the best way to grab immediately what a sliding clipper might be, is to just scroll to the
test form below and click the first
Trigger Test button you see.
After that we can talk on how this script works and on how you can implement it. The only two things I'd like to say is that the script performs
Dynamic Html tasks, and relies on my ULMA dhtml; therefore it needs, in order to work,
all the ULMA functions (which can be found
here).
Moreover, since it can perform a sliding not on one single clipper but by picking a clipping method from a pool of about 8 different and suitable clipping methods (on
the clipper page I included about 20 clippers, but
only a few of them are suitable to be employed for a sliding process: for instance there are some on which a sliding process would be meaningless, for it would just result into an emulation of another... clipper visual effect!), the script featured here also needs a subset of the so called
ULMA Clippers which can be found
clicking here: in other words, depending on which
ULMA Clipper you chose to run the
slidingClipper test with, you'd then (obviously?) need
to include the specific chosen clipping script for that clipper too (still in other words:
here you have the script which slides, but you need also at least one of the suitable scripts which clip to have and implement a...
sliding clipper).
Anyway, for your highest convenience, you do not need to view the clippers page to get the codes you may need: you'll find in the
test form a textarea where even the codes of the
clipper related with the
sliding engine (script, that is) can be viewed without leaving this page.
Let me stress again that none the less, you still need ULMA basic subroutines, which must necessarily be grabbed by reaching the above linked
ULMA main page.
I have to insist.
Some things are certainly easy to envision. It doesn't carry as a consequence they're easy to implement; I see: you find this a platitude, and you are crossed by an unsaid idea that such sentences are hopelessly flawed, the rhetoric flourishing of an impotent mindset you've been used to listen to when you were, maybe, at school (although I must say, since I shared this very same impression otherwise I couldn't guess it, that between the trascendentalism as it is explained by a teacher and the transcendentalism as it is written by Waldo Emerson there is a remarkable difference that you fully appreciate only in case you've not been definitely spoiled and made barren by the teacher to the degree you never get the impulse to fetch the actual book and check for yourself).
Let me make an example to you: you envision to put one car on top of another: no special reasons you should plan such a thing, but the stress should just go on this: it doesn't appear difficult
as an idea, does it? all you have to do is to lift it and put it on the other one.
Well, as you know, that simple idea demands for a full fledged technological aid!
Analogously, every
dhtml setting wants some coding: you're going to find persons that would put 5,000 lines of codes in one web page. You're lucky, you need much, much less.
But since such tasks are remarkably complex, I have produced a bundled set of code snippets which accomplish some typical
dhtml tasks in a smooth way, and this lot is called
ULMA: so give up, and if you're going to use this script, instead of using your own
dhtml branching, use mine, use Ulma: you've got my word (and like the Julius Caesar
I'm a honorable man) you certainly are not going to stumble into inconveniences greater than those you would have put yourself into by insisting using your own!
So yes: you need all the
ULMA subroutines (scripts, that is); I don't mean you've to read all that long file, I just say you need to copy those scripts and paste them in your page
after the <BODY> tag.
Then you have defined in your page (you have, havent' you?) your layer(s): let's imagine one of such layers id's is: "
theLayerID", and it's the one you wish to implement a
slidingClipper onto.
You initialize your variables following the typical ULMA scheme:
var aName;
aName= new layerManager("aName", "theLayerID");
aName.abilitate();
//now be sure you've pasted in your code also the
slidingClipper code. If so:
aName.enable("slidingClipper")
You're now ok and I can start explaining to you how this
sliding clipper can be implemented and what it does.
It works using some defined clippers: clippers are those
Dhtml scripts that can crop the margins of a layer.
One last bad news for you: you have to copy them too, but not all of them: the
slidingClipper has been built to work on whichever of them, but once you've elected to use only one of them, you have to paste in your script only its specific code. You don't need the whole family, this is. Moreover, the
slidingClipper script would enable those clippers by itself, you don't even have to enable them by yourself in the way you had to enable the
slidingClipper itself.
You can get the codes for these clippers also in this page (see the
test form); if by chance you want to see all of them, also those that wouldn't have been suitable for a sliding process, you can
find them all here.
The suitable clippers the
slidingClipper can work with are:
- offTB: the clipper which gradually removes from your sight the layer from its Top towards the Bottom.
- What happens to it with slidingClipper applied on?
While it gets clipped, it also gets moved upward: it thus looks like something is clipping off its head, whereas the difference by the mere offBT is that offBT would still keep the top edge still, but would cut off from bottom.
- offBT: the clipper which gradually removes from your sight the layer from its Bottom towards the Top.
- What happens to it with slidingClipper applied on?
While it gets clipped, it also gets moved downward: it thus looks like something is clipping off its legs, whereas the difference by the mere offTB is that offBT would still keep the bottom edge still, but would cut off from top.
- offLR: the clipper which gradually removes from your sight the layer from its Left towards the Right.
- What happens to it with slidingClipper applied on?
While it gets clipped, it also gets moved leftward: it thus looks like something is clipping off its left, whereas the difference by the mere offRL is that offBT would still keep the left edge still, but would cut off from the right.
- offRL: the clipper which gradually removes from your sight the layer from its Right towards the Left.
- What happens to it with slidingClipper applied on?
While it gets clipped, it also gets moved rightward: it thus looks like something is clipping off its right, whereas the difference by the mere offLR is that offBT would still keep the right edge still, but would cut off from the left.
-
sliceTB: the clipper which simulates a loophole shifting from Top to Bottom.
- What happens to it with slidingClipper applied on?
It would seem still, as if it were rolling under the surface.
Switching on or off the properties named end, start you can change the way it behaves at the beginning or at the end: test on the test form whereas end/start are two select option menus.
This last description applies also to all the slice clippers below.
-
sliceBT: the clipper which simulates a loophole shifting from Bottom to Top.
-
sliceLR: the clipper which simulates a loophole shifting from Left to Right.
-
sliceRL: the clipper which simulates a loophole shifting from Right to Left.
The main properties you have to set for the
slidingClipper are as follows:
FUNDAMENTAL PARAMETERS: |
PROPERTY NAME [ case sensitive ] |
TYPOLOGY |
WHAT IT DOES |
clippingMethod |
String (or Object) |
It must be the name of the clipper you mean to use, passed in between apex: example:
"offBT"
Do not forget to set this, or the slidingClipper won't even start. Names are case sensitive as usual when scripting.
|
speed |
Number |
Number representing, milliseconds as usual for javaScript: 500 is half a second, but I suggest speeds not higher in value than 120 milliseconds.
|
amount |
Number |
The amount the clips must go on by.
|
size |
Number |
Does something actually only on the slice type: sets the measurement the max visible slice must have (width of the scrolling slit). If set anyway for non slicing clippers, won't make any harm though.
|
start |
Number |
Affects only the slice type clippers: changes the behavior the clipper undertakes upon the beginning (test them...).
|
end |
Number |
Affects only the slice type clippers: changes the behavior the clipper undertakes upon finishing.
|
invisibleOnExit |
Number |
If set to 1 sets the layer to invisible when finished. happens before resizing if following point applies.
|
resizeOnExit |
Number |
If set to 1, it obviously resets the original dimensions the layer had before it underwent the clipping process.
|
reposition |
Number |
If set to 1, restores also the original top/left positions of the layer upon exiting.
|
Therefore the ULMA formula for passing such properties to the slidingClipper once enabled as a method of your layerManager can be (whereas aName is a placeholder for the name of the layerManager you chose):
aName.slidingClipper.setAttributes(
"clippingMethod", "sliceLR" ,
"speed", 70 ,
"amount", 3 ,
"size", 50 ,
"start", 0 ,
"end", 0 ,
"invisibleOnExit", 0 ,
"resizeOnExit", 0 ,
"reposition", 0
);
//when ready to start:
aName.slidingClipper.run();
If you want to know (for instance in order to see whether an onClick event should let a new sliding clipper process run, namely to ascertain whether there is still an ongoing process), you may want to remember that the slidingClipper has a property named isRunning which equals to zero (0) when inactive, and to one (1) when still busy running:
aName.slidingClipper.isRunning
|
KNOWN ISSUES:
The
slidingClipper engine has to perform two main actions in order to accomplish its goals:
- Clip the layer.
- Move it upward or downard (or leftward or rightward) accordingly to the clipping current settings of the layer.
Now, you only (only and exclusively) have two ways to achieve this:
- You first clip, then you move (relocate) the layer.
- You first move (relocate) the layer, then you clip.
My personal judgement is that procedure 1 is the correct one, at least as long as we won't have
quantic computers capable of performing two actions simultaneously as we humans can move at the same time two hands; until then, compuers are linear machines: one thing at a time, although at light speed each.
This bears a consequence which is not a script's shortcoming: if you set a very high
amount for the clipping process, the layer is going to be first clipped, then moved: it would appear as sobbing, and maybe the action #2 (namely repositioning the layer) might appear as lagging behind, for
very (very) high amounts, to the degree at times it may seem missing one beat.
Therefore be aware that if you set clipping amount which are considerable, you may encounter such visual problem: the layer gets clipped, appears shrinking, then gets moved but the move appears as a big
leap, for it has to make up for a big amount of clipping, which deprives the process of its appearances of being smooth, even.
Yes, I have also tried to first move, then clip: it bears even worst problems, for the relocation coordinates would still cause the same problem (with the difference, for instance, that the "big leap anyward" might be upward instead than downard); and, at any rate, my personal judgement is that it is more correct if you first clip, then move: if you first move and then you clip, you have to anticipate what the layer clippings are going to be, which adds coding to coding in order to
foresee what's going to happen (how much it's going to be clipped next, that is) instead of relying on the data of the facts: the clipping which has
already taken place.