On 18/06/12 12:16, Chris Green wrote:
E.g. it should be possible to have a high-level/parent process that both serves the pages (my Wiki software - called by apache) *and* collects the reply when the user sends it back such that one can run a conceptually single-threaded process to both ask the question and handle the reply with some sort of common environment etc.
I don't think it would be too hard to do something like this in principle. However, you have to remember that you have no control over how long it takes the user to "answer". It could be seconds, minutes, days, or they might never answer. Having a single thread "waiting" for that answer doesn't scale very well. So you could create a framework that helped you develop "apps" for "home use", but I don't think you could do it in a way that would work on a web server out there on the Internet - it would be too easy to bring it to its knees.
As it is it's messy. My PHP plugin code doesn't really lend itself to being run as the form action because it depends on quite a lot of the environment etc. provided by the wiki generation, it can't easily be run stand-alone. Thus the form action has to be a separate stand-alone script of some sort that reloads the wiki page with some sort of parameter/data indicating the user's reply.
I think this may be your problem here; the framework you are using (the wiki) is making this harder than it would otherwise have been.
You might want to look at AJAX approaches; that way your interaction between the server and client can be restricted to just the questions and answers. So to use your colour example: you get the page that asks the user for their favourite colour as you described. But the answer isn't submitted by the browser requesting a new page, instead it's done through Javascript and your code just has to send back the information required to update the page accordingly (whilst also storing it in the users preferences for future use). The "information required to update the page" would, in the simple case, be the content of whichever DIV needed updating.
Indeed, you could do a lot of the work you're trying to do client-side in JavaScript, and just submit the answers back when you have them all. That scales, because you're pushing the work to the client end so as the client count grows the system doesn't get any substantial increase in workload.
NB: When I talk about AJAX, I really mean pick a suitable Javascript library/framework (jQuery comes to mind) but do all the PHP interaction with it yourself. Because the responses from the PHP side will only be affecting the parts of the page you already control in your plugin, they no longer need to be Wiki "aware" in the same way that your plugin itself does.
Mark