SitePoint Sponsor

User Tag List

Results 1 to 15 of 15

Thread: Script Server

  1. #1
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Script Server

    Following what I was talking about here, some experimental code (attached)

    Be interested in hearing thoughts / ideas. So far it takes care of the basics of serializing data between PHP and Javascript, as well as a simple framework, for PHP, for responding to remote Javascript requests. Right now, for Javascript, it handles the core types but probably won't work if you try serializing something like a DOMDocument object.

    The basic idea is to make talking to PHP from Javascript as easy as possible. From my point of view, that means generating as much Javascript as possible. Ideally you should be able to "expose" some PHP objects and make it look like you can call them directly from Javascript.

    I.e. if you have a PHP class like;

    PHP Code:
    class Article {
        var 
    $title;
        var 
    $timepublished// Timestamp
        
        
    function Article($id) {
             
    // some sql or whatever here to fetch the article
        
    }
        function 
    title() {
            return 
    $this->title;
        }
        function 
    timePublished() {
            return 
    date('Y-m-d H:i:s',$this->timepublished);
        }

    You can "publish" it in some way via Script Server. Script Server then takes care of generating Javascript do you can immediately do stuff like;

    Code:
    <script type="text/javascript">
    function displayArticle(id) {
         var article = new Article(id); // remote request gets made here
    
         document.getElementById('title').innerHTML = article.title();
         document.getElementById('published').innerHTML = article.timePublished();
    }
    </script>
    
    <!-- in HTML body -->
    
    <a href="javascript:displayArticle(1)">Display Article #1</a>
    <h1 id="title"></h1>
    <div id="published"></div>
    [Note: Sitepoints BBCode replaces javascript : displayArticle(1) with java_script_:displayArticle(1)]

    The generated Javascript should already know about what URL to fetch the data from, how to fetch it and how to unserialize it.

    That's the idea anyway - none of this is implemented yet.

    Know this isn't very vogue of me, not using SOAP, XML-RPC or whatever but with the amount of grief those protocols cause, when used with XUL / XPCom, plus the general XML overhead, it's worth the effort re-inventing the wheel. XMLHttpRequest in Mozilla doesn't need any special security.
    Attached Files Attached Files

  2. #2
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Starting to get somewhere here I think. Attached is the latest (it's actually under sourceforge CVS @ sf.net/projects/xmlrpccom right now) and a new (completely hacked) XUL app: XULMail.

    The XULMail app is very crude (further hampered by XULPlanet being down) but meant to demonstrate the point of doing this.

    The work of fetching mail is all done by PHP (hopefully on or near the mail server) then passed to the XUL client, depending on what the user clicks. Compared to a typical web mail application, it means you're only loading the user interface once. After than only data is exchanged. That means reading mail over HTTP should be alot faster - you gain the advantages of a desktop email client with the flexibility of "HTTP anywhere".

    As far as getting PHP and Javascript talking to each other, pretty convinced now this is the easiest way to go (vs. XML-RPC, SOAP or whatever). The code is now at the point where you can generate a Javascript exception from PHP, for example. Have ironed out some other issues as well although not unit tests (shame on me) yet.
    Attached Images Attached Images
    Attached Files Attached Files

  3. #3
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Not following just now Are you suggesting that once PHP has been processed, then you could use Javascript alone to refresh the page with new data ?

    This is the sort of feeling I'm getting just now. Could be possible, but I'm thinking it wouldn't be easy without hacking.

    Harry, could you explain some more ? Thanks

  4. #4
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Are you suggesting that once PHP has been processed, then you could use Javascript alone to refresh the page with new data ?
    In fact suggesting more than that - the entire page is never refreshed but Javascript is used to "refresh" the data displayed by the page.

    Could be possible, but I'm thinking it wouldn't be easy without hacking.
    True - what I'm hoping for though is by generating as much of the Javascript used by the client as possible, there's only a limited requirement for manual coding.

    I used XUL in that example but it could equally apply to HTML in the modern browsers (IE 5+, Mozilla 1+). For sake of explaining, here's the "application lifecycle" using HTML.

    1. Script "ui.php" generates some HTML + Javascript (in fact it could be just static HTML - no need for PHP)

    2. Someone loads the HTML into their browser from "ui.php" and get's a "stand alone page".

    3. As the user clicks on links / buttons, Javascript in the page contacts "responder.php" (using the IE / Mozilla Javascript XMLHttpRequest class), sending the remote PHP script some data as a serialized PHP string.

    4. The request data sent by Javascript tells "responder.php" what to do (e.g. get a list of emails)

    5. "responder.php" get's the email list as an array and converts (serializes) it into a string which Javascript can "unserialize" with it's eval() function.

    6. The Javascript in the page loops through the email array it got back from PHP and adds the results to the HTML, using some DOM manipulation.

    Because Javascript and PHP are only exchanging "raw data", alot of the overhead of requesting a new page is gone, (plus the user get's the feeling that the application is always running).

    Also, with something like an email application, you'll typically only want to request the complete list of emails occasionally, the rest of the requests being for invidual emails. With a standard web mail app, it's common to reload the complete list each time you want to look at the next message in the list.

    Make some sense?

  5. #5
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes

    the entire page is never refreshed but Javascript is used to "refresh" the data displayed by the page.
    This is the idea that I got initially, thanks

    This is interesting, so I'm going to be following this discussion more.

    In the past,

    Javascript in the page contacts "responder.php" (using the IE / Mozilla Javascript XMLHttpRequest class), sending the remote PHP script some data as a serialized PHP string.
    This it's self would most likely have been achieved by refreshing a HIDDEN IFRAME. I've seen something like this done in the past using IFRAMEs and the DOM, and guest what ?

    It worked. A hack none the less, but it worked

    With 'Javascript XMLHttpRequest', you now no longer need an IFRAME I supect. You are correct about it not mattering what markup language your using

    Hell, could be XML and an XSL stylesheet for all it matters

  6. #6
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have done something similar to this I believe. Harry, you have seen my fake dialog boxes (div with js to allow for dragging and hiding). I have a "dialog" box with an iframe in it that when a user click a specific js link on the main page, it calls for a refresh of the iframe on the floating div.

    One other area I have made extensive use of js for generating html content is a "table-at-a-time" editing page with a 1-to-many relationship (bound list). If you have say 200 rows of data, and a bound list with say 50 options, you could have to output over 1000 <option> tags in total. I have significantly cut down the size of an html page by sending data for the options into a js array, and writing a js function that outputs the entire select/options combinations.

    Anyway...food for though.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  7. #7
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Have to say I've normally avoided iframes like the plague but what Jason does with divs + js is impressive.

    May be using direct HTTP request / response and serialization can lead to less hacking (would be interested to here your thoughts on the examples - the best simple example right now is probably the "roundtrip.php" script - you'll need to edit the two URL variables to point at the PHP "responders" correctly).

    I haven't got the point of generating the Javascript code for "networking" (just serialization so far) but the aim would be to generate a Javascript function getEmailList() which already knows exactly where to make an HTTP request to, what errors to handle etc. and simply hands you back the results as native Javascript variables, leaving you to focus on messing with DOM.

    One other interesting part of XMLHttpRequest is it supports asynchronous requests (although I haven't played with it yet) which means, in principle, you could have multiple "request threads" running in the background without forcing the user to wait until a response comes back.

  8. #8
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think I remember seeing an architecture a couple of years back where the individual set up a java applet (i.e. real java, not js) to handle the db connection stuff, and then use js clientside to handle the presentation and forward requests to the applet.

    It seems like you rarely see java applets in use these days...

  9. #9
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And very frankly, we do not want to anymore either IMHO

    I'm fed up with Java Applets breaking a browser, sick to the back teeth actually. Java is a fine language, but it's lazy or just plain bad programming that causes these applets to crash

    Not going to bring Flash into this topic but it does has some revelance I suppose in regards to leaving applets out of the web browser.

    What Harry is contemplating is a prospect that would offer PHP to more people, opening up more options.

    Can only be a good thing

    SweatJe, can we see some script by any chance ?

  10. #10
    SitePoint Zealot
    Join Date
    Dec 2003
    Location
    with my kids
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i just submitted an article to phpbuilder.com on using PHP, Javascript and IFRAMES to do Remote Scripting. (basic stuff. it hasn't been accepted/posted yet). it's based on this:
    http://developer.apple.com/internet/...nt/iframe.html

    it works really well on an intranet app i built a couple months ago.

    here's another popular/good library i've used:
    http://www.ashleyit.com/rs/

    and here's a java applet thing:
    http://www.onjava.com/pub/a/onjava/2...avascript.html

  11. #11
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Widow Maker
    SweatJe, can we see some script by any chance ?
    Well... I am thinking about working on another WACT tag to implement these "dialog" boxes on the fly. I need to look a bit further into some js container tags that Harry worked on recently and then it should be really easy to work with.

    In brief, it uses the x library (http://www.cross-browser.com/) and a bit of css and divs to do it's magic:

    PHP Code:
    <html>
    <
    head>
    <
    title>test dialog</title>
    <
    script type="text/javascript" src="/js/x/x_load.js"></script>
    <script type="text/javascript">
    var lastDragZ=1;

    xInclude('/js/x/x_core.js');
    xInclude('/js/x/x_event.js');
    xInclude('/js/x/x_drag.js');

    window.onload = function() {
      myxCenter('dialog1');
      xEnableDrag('dialog1Hdl', parentOnDragStart, moveParentOnDrag, nullOnDragEnd);
    }
    function myxCenter(ele) {
        xMoveTo(ele, (xClientWidth()-xWidth(ele))/2, xScrollTop()+(xClientHeight()-xHeight(ele))/2);
    }
    function parentOnDragStart(ele, mx, my) {
        pEleId = ele.id.substring(0,ele.id.length-3);
        xZIndex(pEleId, ++lastDragZ);
    }
    function moveParentOnDrag(ele, mdx, mdy) {
        pEleId = ele.id.substring(0,ele.id.length-3);
        xMoveTo(pEleId, xLeft(pEleId) + mdx, xTop(pEleId) + mdy);

    }
    function nullOnDragEnd(ele, mx, my) {}
    function popMe(ele) {
        xZIndex(ele, ++lastDragZ);
        xShow(ele);
    }
    </script>
    <style type="text/css">
    .dialog {    position:absolute; margin:3px; padding:3px;
            color:#000; background:#DDD;
              overflow:visible; visibility:hidden;
              border-style: outset;
            border-color: silver;
            border-width: 3px;
            text-align:left;
    }
    .close {padding:3; margin:2; float: right;
        background: silver;
        border-style: outset;
        border-color: silver;
        border-width: 2px;
    }
    </style>
    </head>
    <body>
    <h1>dialog box test page</h1>
    <a href="javascript:popMe('dialog1');">click me</a>


    <div id="dialog1" class="dialog" style="width: 250px; visibility: hidden;">
    <div class="close"><a href="javascript:xHide('dialog1');">X</a></div>
    <div class="close" id="dialog1Hdl" style="width:215px; float:left; position: absolute;">
    <b>Dialog 1 Title Bar</b></div>
    <div style="text-align:center; ">
    <p>&nbsp;</p>
    <h1>Hi</h1>
    I am a fake dialog box.<br />
    <input type="button" value="  Ok  " onClick="xHide('dialog1')" />
    </div>
    </div>


    </body>
    </html> 
    Beware of the board manglings of the javascript links they need to be the word javascript, all together, with a : immediatly following it, not the java_script_: that the board changes it to.

  12. #12
    ********* Wizard silver trophy Cam's Avatar
    Join Date
    Aug 2002
    Location
    Burpengary, Australia
    Posts
    4,495
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by HarryF
    3. As the user clicks on links / buttons, Javascript in the page contacts "responder.php" (using the IE / Mozilla Javascript XMLHttpRequest class), sending the remote PHP script some data as a serialized PHP string.
    Just quickly jumping in, I've used XMLHTTPRequest before in a page hosted online, but only for use within a school intranet. Being hosted online rather on the intranet itself wouldn't have helped anything but there was always a noticable freeze while waiting for the page to load. I don't know if it's an IE thing but the whole browser locked up until the remote files loaded.

    Although this wouldn't effect broadband users in the same way as it would effect dial-up users, it still something thing to take into consideration. Not sure how Mozilla handles waiting to receive the file though, never used much JS in Moz except the odd XUL experiment.

  13. #13
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    there was always a noticable freeze while waiting for the page to load. I don't know if it's an IE thing but the whole browser locked up until the remote files loaded.
    Likewise this "Mozmail" above but I think that's because I'm not using the aysnch functionality in XXMLHttpRequest - right now the code is sitting and waiting for the response and everything else must wait for the code.

    With asych calls you tell XMLHttpRequest what Javascript object it should give the response to (when it's got it) while the rest of the application continues running (no freeze in theory). Haven't tried yet though...

  14. #14
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Interesting stuff Was never too keen on using a HIDDEN IFRAME for something like this if it ever cropped up, but this could be a compromising solution

  15. #15
    I'll take mine raw silver trophy MikeFoster's Avatar
    Join Date
    Dec 2002
    Location
    Alabama, USA
    Posts
    2,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    sweatje, very nice use of the X Library - thanks

    This is a very interesting thread. I'm hoping to find some time to study this in more detail.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •