HTML::PopupTreeSelect 1.0 is out. There's certainly room for improvement, but so far it seems to be working well as an xTree replacement in my current project. I've got a live demo of the code running here.
-sam
Re:Nice work
samtregar on 2003-06-04T17:07:47
Patches welcome. I know how to make it movable, but I think scrolling might require an iframe. I've had some bad iframe/CSS-positioning experiences in the past...-sam
Re:Nice work
wickline on 2003-06-10T03:19:36
you wantin your CSS for some outer-level div or something. (I haven't looked at the module's output, just read the discussion in the journal.)overflow: auto;
See the third example at
http://hotwired.lycos.com/webmonkey/98/15/stuff4a/overflow.html
This will work in css-compliant browsers, but probably have no effect in browsers which don't grok auto overflow. If you want to appease some of those older browsers, you'd have to do iframe, but if you go far enough back, iframe won't be understood either.
-matt
Re:Nice work
samtregar on 2003-06-10T03:23:55
Wow, that's cool. I just released 1.1 but I'm sure I'll put that into 1.2, at least optionally.Thanks,
-sam
I simply write one javascript file to create the layers and build functions, which neatly tie into DynAPI. Then I use Template Toolkit to loop through my hashes and sundry variables, which creates simple javascript calls in the HTML page, to those build functions in my javascript file. It all gets deployed once, no matter how many pages I use it on, which means I don't have to write tons of javascript and DIV tags in every page, thus polluting the web traffic with content that has previously been downloaded by the browser.
Looking at your caveats DynAPI has these tied down mostly. The select box bit can be done, even in IE. For browser/OS compatibility they even have a matrix (buzzword of the month
Doing things in Perl just because you can is not always a good reason to do it. Here is an Open Source project that is very reliably maintained and does just about everything you could want from javascript layers.
The actual tree navigation is great, but I would rather have a code snippet that handles just the tree and lets something like DynAPI cope with the layers themselves.
I have been accused of trying to do all things possible on occasions, and there are times when you have to think whether you doing too much. Perhaps spliting what you have into two modules, one that handles layers and another the provides the tree navigation, so that you're not tying anyone to one way of doing it. Perhaps HTML::Popup and HTML::TreeSelect, with the ability for HTML::Popup to include any other HTML snippet to be the content of the popup layer. This could then allow for perhaps a HTML::NewsTicker or other plugin widget.
Re:DynAPI
samtregar on 2003-06-19T18:09:02
No, I haven't. Checking them out now. Too bad there's no JSPAN... It's way to hard to find good open-source Javascript. I certainly looked!.Doing things in Perl just because you can is not always a good reason to do it.Did you think that's why I wrote it? Nope. I needed it and I couldn't find anything that would do the trick.
Perhaps HTML::Popup and HTML::TreeSelect, with the ability for HTML::Popup to include any other HTML snippet to be the content of the popup layer.Now who's trying to do stuff just because they can? I have absolutely no need for anything like that!
-sam
Re:DynAPI
barbie on 2003-06-19T19:12:44
It would be *very* nice to have a single JSPAN rather than the many javascript code sites that there are.Did you think that's why I wrote it?No, I kinda figured you might had a need for it, but just hadn't found the right tool for the job. Personally I'm always a bit wary of putting JS code within Perl, as it can be too easy to mess quoting up, let alone confuse another reader. Plus it can be a pain to debug sometimes.
My suggestion for splitting things up, was simply to point out that if you did want to have the layer code there, it would be better to split that away from the tree navigation code. Although you might not want HTML::NewsTicker or HTML:Foo, etc, there maybe someone else who does and it makes it alot easier for them to tie their modules into yours.
Having a single module that does all you want, might get less use than two modules that can work together or be used independantly for other tasks.