Session BG functionality removed

[hrvbid]

Today that was my 1st successfully setup of a 1.8.x and the install and setup gave me no essential issues. Congrats so far. Running the site with jquery/ui 1.9.1/1.10.3 there were a lot of issues caused by these versions and probably the most js stuff on board else is yet not compatible and flips out. So I changed back to jquery/ui 1.8.2/1.8.24 to have some more fun. One issue that most affects me is the absence of the sessioned BG ajax processing. That prevents any further test with my mods (including ngboost). Any ajax call replys the whole index page instead of the echoed plain data from the process. Let me point to what happened up to 1.7.x: If any mod wants to communicate async, the (plain or json) post data are placed in session bg. The central index php checked if session bg exists and in that case ignores / cleans any layouted output else and echoes only the content of session bg (the echoed data are replied to the js e handler waiting for a response). How ever a solution in 1.8.x is implemented, such kind of logic is needed. To handle async data via a session bg has some charme because that is all a programmer has to do to.

[jtickle]

I have to be honest here: I had no idea what that entire BG thing was for.

We do have a new means of doing this through the new Module class and Request/Response system. It should not require very many changes to your module code, and it might simplify things a bit for you. As soon as I get the bugs worked out, I'll post some documentation.

[jlbooker]

Using session storage is not the proper/maintainable way for this behavior to be implemented.

In the future (with the new Request/Response @jtickle mentioned), we'll be using a proper Mode/View/Controller (or something closer-to-proper). Modules will be able to return one of many different views. A view can encode the output for Javascript/AJAX and not be wrapped by Layout. A different view could return HTML to be decorated by Layout. However, both of these could be different views of data in one Model object. The Response object will be responsible for determining whether or not the output is returned as json or html.

[hrvbid]

1st (@jtickle), the entire BG thing was explained at the asu track wiki, that you successfully removed from the public view (like all notes I had written there). The BG thing was only a very very little code of lines in the central index php as an option to have most small and plain replies from the server as an ajax communication will require. That is now lost. Probably no one else than me was using that (for expl with ngboost, and the explanations why sth like ngboost was urgent required and boost self is most at the end was also explained in - see above). Started with 1.6.3 over the 1.7.x road, web2 techno was a most essential stuff I use(d) in all my mods. I cannot believe in a future without such.

2nd (@jlbooker), yes, a plenty of alternate and better concepts are sure to imagine. To have none at the moment simply breaks compatibility to the past.

[Stardog]

Let's not break compatibility with a version release without a chance to smooth over into a new system.

[jlbooker]

According to the versioning and comparability plan in #102...

I agree, let's restore this ASAP (in a minor bug-fix release) with the understanding that it is deprecated and will be removed in the next major release.

[jlbooker]

@hrvbid Please see the above commit. Pull the latest and test it out. Let me know how it goes. If all is well we'll do a 1.8.2 release soon.

[hrvbid]

Tried today, but without success enough. The minor impacts are the new standard jquery / jquery_ui versions (switched back to jq1.8.2 and jqui1.8.24). Theme switched back to simple. Even than, the async communications works a bit only (that is the major impact), but too often feeds back some content not useable with bg tasks (feedback starting with the doctype).

Conclusion at the moment is, I do not have enough knowledge about the ways where and how pws goes on the 1.8.x+ roads. The most concepts on a general level sound well or acceptable, but until no concrete api docs available, until js handling (beyond or with a jrequire) is well defined, the whole test and examine scenario is too time consuming. The differences between 1.7.x and 1.8.x are very very drastic, and I am in doubt if compatibility is possible anyway.

I do not want to appear penetrant, but let remark, the mission to handle and control the async C/S communications is not limited by to differ a layout output against some plain response where IMO json belongs to. Instead, a module or any other code part working async will normally use some or more api stuff from core and other mods. When a mod wants some service from another mod by using that api, the called mod will not know or cannot imagine, if the calling mod needs the service for a fg interactive or bg async task. The simple example for the problem is, a (called) mod can complain about sth wrong and does - yes what ? - feedbacks a complain back as result, as a true/false, as a message via layout by assuming there is something, or whatever else. Also to keep in mind is the logic of a true interaction (a user calls sth) and the side activities (like runtimes). Any solution to serve async communications should not be sure that each part of the whole system is working with best discipline. That was the main reason for me to control the flow in such way to put anything in the bin except that I really want to have, and that was simply forced with the bg session var and the ob cache. But that obviously worked because I knew how the logic of pws with core and layout was working (in past).

Sorry I found no better response for now.

[jlbooker]

@hrvbid What else is being output besides your AJAX/json response? If you can give me a test case that is reproducible, I'll work on finding and silencing the extra output. It may just be that the output buffer is not being turned on early enough and some warning or notice is being output.

In the end, we don't want to break compatibility until the phpws 2.0 release.. So, any trouble you're having with this should be treated as a bug and fixed accordingly.

[hrvbid]

Again, no success.

It appears that the module call (the ajax call) is influenced by something and not arrriving the mod. The condition is best to test with module ngboost you have included in git and using firefox firebug.

An example is, to make a check for any mod in ngboost: the modal display works, but that is yet part of the js. After closing the modal display, an ajax call is fired with the url http://.../ngboost/action/admin/xaop/ml/authkey/78...68. As to see, it uses a shorthand url notation instead telling explicit the index.php module ... etc. The response now is <!DOCTYPE html PUBLIC "-//W3 .... etc, thus a more or less layouted feedback like any interactive action. Definitivly, the call did not arrive ngboost.

[jlbooker]

Ok, I installed ngBoost and noticed several things right away:

1) The tab-panel content initially loads, but is replaced by an AJAX request which ends up showing the home page of the site inside the tab content. It looks like your javascript code is making the following request:

Request URL:http://localhost/phpwebsite/
Request Method:GET

Since there are no query string paramaters, and no POST data (since this is a GET request), returning the homepage is expected here. You are correct is saying that this request is never reaching the ngBoost module, but that's because there's no ``?module=ngboost" on the query string of the HTTP request.

2) There are javascript errors thrown right from the start. It looks like the jqModal library isn't compatible with the newest version of jquery. This is causing the error: Uncaught TypeError: Cannot read property 'msie' of undefined in jqModal.js, line 61 The browser.msie attribute was deprecated in jQuery 1.3, and removed in 1.9. See a similar Stack Overflow question

This seems to indicate that the problem is unrelated to the $_SESSION['BG_MODE'] functionality and the routing of requests to modules. The problem looks like it is in the ngBoost javascript somewhere, and is resulting in the GET / request with no parameters. It's likely a compatibility issue with jQuery 1.9. Please try using the jQuery Compatibility Plugin and see if that fixes anything.

[hrvbid]

2nd item 1st, see #83 (up to jquery 1.8.2 no problems). 1st item: each Get in 1.7.x was eligible to be written as a index.php?module=mod&more=whatever or in a shorthand notation (via webservers rewrite) as ./mod/more/whatever and the query strings are solved best both ways. That worked with each mod and I have only seen one exception with pagesmith that could use a ./pagesmith/8 (instead of a ./pagesmith/id/8 according the just said). The rewrite mechanism was: "index.php?module=" was not required, starting with the modname and then each query pair (&name=value) as a name/value shorthand.

[jlbooker]

I'm going to go ahead and close this issue then for two reasons:

1. The BG Mode functionality has been restored, which was the original topic of this issue.
2. The ngBoost javascript is currently not compatible with the jquery version included in phpws 1.8.1. This makes the request routing problem non-reproducible. Once you update the javascript to be compatible, you can open another issue for the request routing problem.