On Mon, Jun 18, 2012 at 01:00:01PM +0100, Mark Rogers wrote:
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.
Yes, I think you have hit the nail on the head. Many/most of my applications of this sort of thing are for my own use (with maybe a few family members as well). I realise that for a web server handling hundreds/thousands of requests it's not a realistic approach.
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.
Yes, probably, but the Wiki allows me to create lots of useful web information quickly and easily. I've not found any other way of putting information up that's anywhere near as quick and efficient.
However there's nothing to stop me having a separate way of creating interactive (i.e. forms) pages withing the mostly Wiki hieararchy.
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.
Yes, I have played a little with jQuery, I'll maybe do some more playing with it and see how I get on.
Thanks all.