Re: More HTML_AJAX

Alan Knowles wrote:

Is this going to be broken into HTML_Javascript_JSON? The whole AJAX side is kind of trival to implement, and over-complicating a simple solution. The actual JSON encoder will be broken out if its author pushes his proposal forward, im not going to do that though. Plus JSON is actually a pretty small part of it, and its the piece that can be easily replaced, either by xml or some other encoding solution we haven't heard of yet.

And I don't think its all that trival to implement a correct solution, its trival to implement the basic use case, but the trival implements end up being hard to maintain. Anyhow if you think the basic cases are hard to use let me know, and i'll try to think of ways to make the basic use simpler.

The JS lib's look potentially usefull, however the present bundling of them into a single file make it difficult to follow (and please put usage examples in the comments above the code..) There is still some more refactoring to do on the jslib, i'll add examples but because you have to download javascript comments I don't think its a good idea to put large amounts of comments in them.

The code will be distributed in single and multiple file, the single file is just there for convienvce, i think some examples actually use the multi file approach. This is also the same approach i've seen every other major (JPSpan, prototype) javascript lib take.

I would like to hear better ideas for how to deal with JS in PEAR - just bundling them in a package seems rather counter to distributing and maintaining PHP libraries.. I saw http://www.openjsan.org/ the other day and although it uses horrible Perl comments and '.' as the namespace seperators - It made me wonder if PEAR_Server could be used somewhere to host this seperately... - Quality JS code with Standards..?! The big argument for shipping it in PEAR is that you can make things work out of the box.

-josh

Regards Alan On Tue, 2005-07-19 at 10:22 -0700, Joshua Eichorn wrote:

I've talked to Luca and we agree that the way forward is from my code. The main reason for this is that in PEAR a library that covers a greater number of use cases, by using drivers for encoding input and output and other optional features. So if we can move on with some technical discussion on the code at http://bluga.net/projects/HTML_AJAX/ I would like to get to a proposal soon but that will take a day or two so Luca has time to pull his down, and I'll need a bit to get things packaged, since Greg has always done it so I have no clue how. The one big thing I could use help on is where does JavaScript belong in a PEAR package. Also how do you guys manage doing development from a cvs checkout, I'm on windows at the moment so I can't do symlink tricks, and all the includes rely on the full path. Also I added some new features last night, the biggest one being driver based serialization (right now just JSON and Null) and proxyless operation. -josh