* Becky Alcorn <[EMAIL PROTECTED]> [2004-06-18 10:57]: > At this point the module is HTML specific.
That's why the suggestion includes a ::HTML specifier. > The javascript library that we're using only works in browsers > as far as we know, Yes, but even if it might not be possible to use *this* library in SVG, that doesn't mean JavaScript::Tooltip is the wrong place, because that name does not make any assertions about the library in use (or indeed, if one is used at all). I don't believe that is important either, so JavaScript::Tooltip::HTML is perfectly fine. If for some reason it was important, then that piece of information does not generalize the name somehow, rather it is a specialization of the module and so would require *further* specification of the name: JavaScript::Tooltip::HTML::Frobnitzer so a conceivable alternative HTML-specific JS tooltip library called Veeblefitzer would lead to JavaScript::Tooltip::HTML::Veeblefitzer > and as far as our development goes we think of this kind of > functionality as a natural extension of what the CGI module > does for us. The HTML generation code in CGI.pm is misplaced. I remember even Licoln Stein saying that much himself; he wrote somewhere that CGI.pm really shouldn't have been a huge monolithic module with all sorts of only indirectly related functionality, but that it was too late to change that now. Unfortunately, I can't find a reference right now -- if someone knows, please help me out here. Anyway, my point is that there's no need to perpetuate the mistakes made with CGI.pm (of which there are a lot; except at the time, noone knew any better. Now we do). > It seems that there is some overlap between the Javascript, > HTML and CGI namespaces. The suggestions we have so far are: > > CGI::Tooltip I vote against this. > HTML::Tooltip Could (barely) live with that, if you must pick this, but it would IMHO be mistaken. > JavaScript::Tooltip::HTML See previous mail and above explanation: this is perfect. > There is even a HTML::Widget and a HTML::Widgets namespace > which might apply also (although which would you use?). Those have very different goals from your module. The idea is to get away from generating HTML directly, and think in higher level terms in the app. They're attempts an an entire paradigm of writing a Web app UI. Their goals are orthogonal to those of your module. Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
