[uf-discuss] Tutorial on AHAH (such a cool technology!)

[Paul Wilkins]

Mike Schinkel wrote:
> Strange; S5's intro[1] DOES print correctly in outline mode, but Roger's
> AHAH slideshow does not. 

Now that *is* an interesting problem.
It appears that Roger uses a separate print stylesheet that forces the 
page break after each slide. Naughty Roger.

>>At least some of them allow you to supply extra info to
>>help narrow down and pleed up the search, like
>>http://www.dustindiaz.com/getelementsbyclass
> 
> That looks like a good middle ground.

It is a good middle ground. Let's make the code smarter so that the job 
can be performed faster.

> I don't know if you are aware, but I made a big deal about that issue on
> this list several months ago but it seemed that most people didn't feel like
> my concerns were going to be an issue. So rather than beat a dead horse, I
> moved on to work in other areas.  I still monitor this list occassionally,
> but not in real time.

Well it'll be a shame to lose your voice on this, because often it is 
the pressure of limitations (such as trying to use less class) that give 
rise to the inspiration for a creative solution.

>>They *are*are at more of a risk of breaking, but it's the
>>best solution we have at the moment.
> 
> Actually, there are solutions I've proposed I think are better, but they
> fell on deaf ears on this list. I can dredge them up again if you like.

Oh yes please, do tell.

>>Sure thing. Take for example the case where some
>>webmaster decides to specify the relevance of outgoing
>>links. He may have a script that goes through adding rel
>>tags to certain known links and domains, and leave empty
>>those that it doesn't know about.

> Well, that would break all of Microformats and sounds like the problem is
> the rogue webmaster not realizing that existing rel tags need to be
> maintained.  I can see a potential for such a problem, but in the same
> context I can see that webmaster creating far greater problems than just
> upseting rel="ahah."

That's right. It was a good reminder that the page as coded isn't the 
same page that ends up with the user. Similar issues are where links are 
given class attributes by some script to achieve different effects, but 
this in turn breaks the class="url" attribute that was on it.

That attribute is still needed, but it does mean that the people writing 
these scripts, and those of us using them, will have to be more careful 
in how they're applied.

> Here's a thought (more of a Javascript issue than a microformat issue; we
> can take offline is anyone objects): would it be possible to pipeline in a
> common file with a single scanner that any such widgets could attach to? (I
> don't know Javascript well enough to know the answer to that.)

Yes, it is possible. Instead of getElementsByClassName, you could set up 
an array structure with two elements, the names to be looked for and 
some function to be applied to them. A final script after all the others 
would activate the search so that the page can be processed for the 
items in the array, and then acted upon

So yes, it is possible.

>>It would be a heavy burden, so I'm suggesting that the
>>javascript code he talks about is moved into the function
>>itself, so that the content author just has to bring in
>>the code and apply a rel attribute and a few id
>>attributes.
> 
> I don't see it.  Can you give code examples?

The code he talks about is where the function accepts arguments which 
contain the elements to be worked upon.

The code sample he gives is
<script>
...
var parent = document.getElementById('foo');
var elements = parent.getElementsByTagName('a');
var Fantacy = new Fantasticulator(elements);
Fantacy.init();
...
</script>

The thing is, we don't want to content author to have to write this 
code. If the content author isnt to write the code, then the code will 
have to try and find the appropriate parts itself, which will be less 
efficient but still workable.

In our AHAH case, we can have an init section that find the elements and 
passes them on to be attached. The ahah attribute may be attached to any 
anchor, so we need to get all of them from the page.
     var els = document.getElementsByTagName('a');

Then we find any with the rel="ahah" attribute,
     Array.forEach(els, function(el) {
       if ('ahah' == el.getAttribute('rel')) {

and pass those elements on to a function that does the dirty work of 
attaching the event.
         this.attach(el);
       }

Here's some similar code from before that demonstrates this.

ahah = {
  init : function() {
     var elements = [];
     var els = document.getElementsByTagName('a');
     Array.forEach(els, function(el) {
       if ('ahah' == el.getAttribute('rel')) {
         this.attach(el);
       }
     }
   ),
   attach : function(el) {
     var href = el.getAttribute('href');
     var id = 'ahah-' + el.getAttribute('id');
     addEvent(el, 'click', 'function(){ahah.get("'+href+'", 
"'+'ahah-'+id+'")');
   }
);

>>The biggest issue at hand is if this stuff is happening
>>after the page finished loading, that the user received
>>feedback on when these things have finished and the page
>>is ready for use. When a page appears on the screen
>>people expect to be able to use it immediately. If there
>>is some 5 seconds of waiting required (without feedback
>>of some kind) before everything is ready, that's where
>>the trouble lies.
> 
> 
> 5 seconds is a lot!  Maybe there are better techniques, like having the
> links be inactive and greyed-out until available?

When the DOM has finished loading 
http://www.javascriptkit.com/dhtmltutors/domready.shtml (and 
before/while images are being accessed) the scripts for the page can be 
run while the images are being downloaded, so there should be no 
noticable delay.


-- 
   Paul Mark Wilkins
New Zealand Tourism Online
pmw57 at xtra.co.nz <mailto:pmw57 at xtra.co.nz>
109 Tuam Street
Level 1
Christchurch 8011
New Zealand
+64 3 963 5039