http://www.ashleyit.com/rs/

For a demo of what we are using it for, see the cascading menus that auto-update at:

http://phplens.com/lens/ex/ex960.php

PS: The iframe does get added to the document, but is invisible, unless you enable debugging.

Why there are not standard libraries or at least standard interfaces for these things has always baffled me. There are just not that many ways to solve these problems in Javascript. Standard interfaces would give us a standard to code to.

I think if the PHP community came up with some basic interfaces for Javascript libraries the problems you mention would be reduced. Then there would be the target for interoperability. Libraries would then compete on performance, stability and error handling.

Simply to make the point that there were efforts to make a common API for Javascript to all browsers.

For DynAPI, as far as I know, its still under development, but has slowed right down. My biggest thing for creating a rich client was a drag drop interface, but couldn’t get it working the way that I wanted.

I have yet to find a nice unobtrusive DHTML api that doesn’t require me to create interfaces “their way”. The key for me is that I still want to have to API’s at my disposal without have to create the interface in a way dictated by that API. For example, to get drag drop running under DynAPI, I cant enable it for relatively positioned elements, only absolute.

Maybe we should be posting some of these concerns in the DHTML blog to see if those guys can shed any light on the matter?

I am interested in the direction of the examples shown above. I don’t think we need classes built by reflection as much as just solid classes to do the things we need on the client side. The problem with the Javascript sample above is that it magically assumes that there is solid code to do the communication and to display the values. I think we need to start with those libraries. Then it will be easy enough to wrapper them to reflect our PHP framework.

I think a set of coherent libraries that dealt with things like:

- graphic positions and display
- events (timer, keyboard, etc.)
- inter-frame communication
- window/document control (open, close, set, etc.)
- layer management
- forms data access and validation

On top of those you could build things like drop down menus whose items could change based on a remote data call.

I think Harry is more interested in the layer above these, but it would be interesting to do a survey of available Javascript libs to see of a coherent client side framework could be pieced together. Something specific to PHP that PHP applications could target just like Dreamweaver or ColdFusion target their own Javascript libs.

One of the problems I see is that javascript tends to spread out. Your wactjavascript_autoComplete example demonstrates this. It has the Javascript function in the , but the data array and the specific form field onKeyUp= code is down in the HTML.

My experience is that the stuff in the should be done first, all the while building a list of the javascript code that needs to be included in the . Then after the is finished you build the required javascript for the . That also eliminates multiple declarations of the same javascript functions by the generator when several things in the use the same functions.

I do like the way wactjavascript_autoComplete accepts a data array. Receiving most/all of the data via parameters is one key requirement for a PHP centric library.

The problem with the Javascript sample above is that it magically assumes that there is solid code to do the communication and to display the values. I think we need to start with those libraries.

Agreed. All this has got me thinking I need to release what I’ve done so far and see where it goes.