Check in ImageManager

[yermol]

The current ImageManager code I have uses a number of different PHP scripts on the backend. The urls to these scripts are all hard coded in the client side.

Modify ImageManager so all requests go to a single backend script that then routes the command to the right function.

It is probably a good idea to standardize on some communication method between client and server to make the lives of server-side integrators easier. If the URL's are not hard coded it's much easier to replace the backend code.

I'm imaginging something like

http://somesite/xinha/plugins/ImageManger/backend.php?plugin=ImageManager&func=whatever

where func is whatever the function request is (view thumbnails, raise the editor, etc.)

We could even go so far as to create a single backend entry point for all plugins

http://somesite/xinha/backend.php?plugin=whatever&func=whatever&plugin_parms=whatever

The actual URL would get passed in as a config parameter with some reasonable default.

This would make doing global things like server side permissions much easier.

What do you think?

[gogo]

I think the single backend for all plugins (with plugins "plugging in" to the single backend's frontend ;)) is an meritous idea, I think.

The only thing is, PHP isn't all we have on our hands, we also have perl, and there are some asp based plugins out there somewhere (and I don't know if they are all vb, or pl or jscript, or what). So I guess that means we need a seperate single backend for each of the languages. And modifying each of the plugins' current backends to use the new combined backend "framework".

I dunno, I like to keep things simple, and I'm worried that perhaps we are making things more complicated than they need to be (as I am almost always guilty of).

Maybe you'd like to create an experimental branch to try out some ideas so that we can all comment on them?

svn cp svn://xinha.gogo.co.nz/repository/trunk svn://xinha.gogo.co.nz/repository/branches/combined-backend

[yermol]

Cool. I'll do that. Having a single backend script for each language is probably a good idea. I'm a big fan of single entry point designs.

Alot of these ideas come from the formVista framework I've been developing over the last several years. I'll be putting up some demos before too long. I think some of the ideas there may translate well here.

I'd still like to propose that within each plugin we use the single entry point with query variables approach. I think each plugin should have a "backend.php", "backend.pl", etc. that then routes the commands to the separate features. Obviously the name "backend" would just be a default that could be overridden by the config.

I think this will solve a real problem. Consider a artificial example; you want to tag every URL request coming to your server with a hash. h=<some_hash>. You use Xinha. Now you have to go through every pluging and every url that makes a request back to the server and add the h=<some_hash> query variable. There are quite a few places in ImageManager, SpellChecker etc which do independent queries back to the server to separate URLs.

Makes adding a query variable a real pain. (I end up doing something very similar to this every time I integrate a new version of Xinha into the formVista framework.)

If, at the very least, each plugin has a single entry point and the backend URL can be passed into via the Config it would just be a matter of adding ?h=<some_hash> to the backend URL passed into the config and then it would get propagated through back to the server without any further modifications.

If all the plugins do this per-plugin single backend approach then the single-overall-plugin-backend doesn't require any changes in the javascript code .. it'll just be a different backend config setting ..

So, in summary, instead of having something like SpellChecker doing requests to spell-check-ui.html, spell-check-logic.php|cgi, spell-check-savedicts.php|cgi, it would do requests to a single backend script backend.php|cgi and pass it

plugin= name of plugin we're talking to (for future expansion and flexibility) f= function being called (ui, logic, savedicts) etc whatever other query vars the given function needs.

Then if you want to change the language, the implementation, whatever you just pass in a different backend URL. As long as it implements the same interface you're golden.

Since you don't have an ImageManager plugin I'll submit the modified one that I've put together; before someone else does. ImageManager is a real pain for me to integrate .. so having one setup the way I need will save me alot of hours of work.

For the rest I'll create a fork in SVN.

[yermol]

Checked in modified ImageManager with unified backend. By defualt it's set up to use a small demo_images directory.

Updated full_example.html

[gogo]

Sounds good, I think a single central "plugin backend" for each language is best

plugins/backend.php plugins/backend.pl plugins/backend.asp plugins/backend.cfm

With the given backend including some controlling logic from the target plugin and leaving it to do the switch($_REQUEST['_function')).

The only thing I'd suggest is the use of __plugin= and __function= instead of plugin= and f= reason being simply that perhaps the plugin developer wants to use a query parameter named plugin, and f isn't a very good variabe name ;)

Also follows the PHP scheme of having double-underscore stuff be "reserved" for the system.

Look forward to seeing what you come up with in the branch.

[ns@…]

I know this ticket is allready closed but please keep in mind too that some plugins might be used standalone!

Best example is the ImageManger? - currently we use the standalone-version of wei's ImageManager in our cms.

[yermol]

I changed the parameter variables to plugin and function. I also made the config use PHP_SELF so it should just work out of the box.

As far as the standalone image manager goes, I have that integrated into my formVista framework as well in the same kind of single backend entry point design; I could package up a version of that once I get a free moment.

Standalone ImageManager isn't really relevant to Xinha ...

[Niko <ns@…>]

[quote] Standalone ImageManager? isn't really relevant to Xinha ... /quote Thats true of course... But it would be very nice to create a standalone-version out of the same code-basis!

[yermol]

The changes I've made to ImageManager are fairly trivial .. just changed all the links to point to a single backend.php file and expanded the config file a bit.

I've done a very similar thing for the standalone version. I can merge my latest changes into that once I get a chance, or maybe combine the two, like you said, to just have one code base.

but I'm completely swamped right now so it's going to be a while ...

[Niko <ns@…>]

i don't need it now... i just want that you keep this in mind...