What are reasons behind own AjaxModuleHelper instead of using native JModuleHelper and AjaxError?

Overall this feels much more right than current implementation

AjaxError for replace the default exception handler that Joomla! use libraries/cms/error/page.php ..
it need because, as you can see, it allow more simple handle the errors, and because default handler will render a HTML page, that no need in our case.

AjaxModuleHelper just small helper for prevent code duplication in the controllers.
Default JModuleHelper load the full modules list that enabled for a current page, that not very optimal, because for us just need to check the one module, and I not see big sense that the module should be exactly "for this page" or for "this language" ...
I think for us enough check whether module enabled and user have the access.

I have to say I'm not a massive fan of this. In this specific case I think splitting it up is creating more hassle than it's worth. I'm of the opinion for modules and plugins pretty much all we should support is json replies - and maybe raw if we are in debug mode. This seems like creating files for the sake of conforming to standards.

I support moving to JResponseJson (as in piotr's PR) but I think that's as far as we need to go.

I'd say this component will get removed as soon as we move to webservices (J5??) anyhow

@Fedik thanks for answers, this helps.
I'm not entirely convinced for the same reason as @wilsonge, on the other code has logic pattern now.

If we are going to do controllers let's do them new style for example just calll or callplugin, callmodule with options for format (and maybe even with options for plugin or module). The new style is designed for services and makes a lot more sense. Also use singular folder names so things autoload correctly and we don't need to mess around with includes.

@elinw there already task=module.call and task=plugin.call , and parameters format=raw, format=json also there.
Or I think I not very understand suggestion about "callplugin, callmodule".
Can you explain a bit more? :)

I know not to much about planed web-services, so I thought that extending the current realization by adding just a new controller in future, will be a cool idea ;)

and think, right, if do it compatible with web-services, then the current "trick" can be removed with the less pain in future when web-services will be ready ... but I know nothing about the plans around web-services :)
and whether web-services will allow interaction with the modules?

I appreciate the work that went into this PR, the code is well written and has some nice innovations like AjaxError. In no way do I want to discourage future contributions, but I'm also not convinced that introducing controllers is beneficial. @wilsonge is right in that it is very unlikely that we'll need to introduce other formats in the future and may introduce more maintenance than benefit.

I really see no problem with formats
check http://docs.joomla.org/Xml-rpc_changes_in_Joomla!_2.5
if need additional format, then just need add the new controller , and no need any changes in existing controller,

example for xml just need add module.xml.php where in the call method you can render xml, or use view for it

@Fedik Yes, you can do it in your own installation, but what about if you'd like to use formats like image or xml in a public extension?

answer is:

Another formats we can add in future, by request.

it can be added without big problem if it will be a really need ;)

but combination plugin + format=image can be problem (and maybe for other formats too), because the dispatcher can return multiple values ... but it a question how to call the plugin(s)

ok, added xml and image formats.
right, looks a bit "over coded" :)

Would it be safe to say that we can close this issue as there isn't consensus to the changes it introduces?

ok, changed to using new MVC,
and without change the request format, so can be tested with existing plugins/modules that already wrote for use com_ajax

thoughts? :)

new pull to staging #3071