There and Back Again

AJAX webcast presentation on May 26th

I’ll be presenting an updated version of the presentation I gave last night at AzPHP as a free webcast for php|architect on May 26th. The major change will be a new technical introduction centered around getting you started with JPSpan and building a simple widget.

The live talk will begin at 1:00 PM EST (10 AM PST, 6PM GMT), space is limited so if your interested you’ll want to sign up today.

7 thoughts on “AJAX webcast presentation on May 26th

  1. Jim

    I’m signed up for the webcast, looking forward to it!… after playing with jpspan I must say it adds a great deal of complexity to ajax applications. I’m hoping you will go over why the goal and/or need for jpspan over just xmlhttprequest post operations or creating a soap client in JS with PHP posting the data on the backend to a server.

    Also curious if IIS support will be integrated into JPSpan in the near future. 🙂

  2. Joshua Eichorn Post author

    Jim great to hear you signed up for the webcast. I’m not sure what complexity your talking about, I like how it reduces complexity by automating the php to javascript mapping.

    There as some areas where it doesn’t do quite a good enough job of hiding the complexity (managing multiple conncurrent requests, serializing deep associative arrays) but those are mainly due to bugs then overall design.

    As far as soap goes I don’t see what you gain, it decreases performance for the exact same model, or maybe worse if you javascript client doesn’t support proxy objects. What exactly do you find more complex.

    I think the only thing that keeps JPSpan from working in IIS is the path_info stuff it does, so im guessing someone just needs to create a version of the postoffice server that doesn’t rely on path_info, i have cvs access to jpspan so I can put a patch in if someone writes one but I use Apache2 on windows so I don’t really have a need for it myself.

  3. Jim

    hey Josh, thanks for the reply…
    I’m just not sure of the overall goal jpspan is trying to achieve. IE what is the problem is it trying to solve? is it for allowing you to re-use your existing PHP classes by making them available in JS? I’m definatley not knocking it, I’m just trying to get my brain around the big picture.

  4. Joshua Eichorn Post author

    Jim: You’ve pretty much got the goal of JPSpan.

    Of course i wouldn’t say its just to reuse php classes in javascript, since they don’t always fit into that context in a meaningful way.

    You might describe the goal as allowing javascript programers to use a php backend directly in there scripts in a completely transparent fashion.

    Or maybe to allow php programers to implement ajax without writing any code to move data between php and javascript.

    Overall its a very remote scripting type approach, you can thing of it as custom javascript to php rpc. Now this approach doesn’t always make sense, especially in cases were your data or document centric, in those cases consuming your content directly in javacript might make more sense. At some point i’ll write a bit about doing ajax like that.

  5. Patrick Allaert

    PHP5 already made a very great job with the class SoapServer who is able to delegate the main responsibility to a class using SoapServer->setClass().
    What about a JavaScript SoapClient ? This way, we don’t have to create a specific server to serve XML requests for JavaScript and another one for an accessible SOAP API…

    My feeling is that the W3C already made an excellent job with SOAP and WSDL with rock-solid standards, shouldn’t AJAX techniques rely on W3C standards ?

    JPSpan create a hook between JS and PHP classes but this is already done at server side by SoapServer and it is possible to write a SoapClient in about every languages (PHP, Perl, Python, C/C++ with gsoap, Java, .NET, Ruby,…) … but JavaScript?

    Looks like we are missing something…

  6. Joshua Eichorn Post author

    Soap is overkill. It doesn’t work well for non-typed languages like javascript or php (ie your adding types to stuff when neither side cares) and its a lot slower.

    Standards are great if you need intereoprability, but were really just talking about moving data between php and javascript whats the point of bringing in baggage of a standard based around the needs of java.

    The JPSpan website has a more through discussion of this: http://jpspan.sourceforge.net/wiki/doku.php?id=discussion:vswebservices