Webservices as a standalone application Take 2

wilsonge commented 9 years ago

This was a continuation of the work done in #13

This improves the abstraction between the soap and HAL classes by making a common Joomla\Webservices\Webservices class and attempts to try and break the integrations with Joomla out into the Joomla\Webservices\Integrations namespace so we can make future compatibility with Joomla 4 "simpler"

Large Item Todos:

[ ] Refactor away from Legacy MVC to some sort of new MVC
[ ] Decide if we want a JTable replacement or whether we want to drop everything into models (me and @mbabker have discussed this a few times but nothing really ever came out of it)
[x] Implement a session for enqueing messages into the application. Joomla's session v1 is pretty much unusable. v2 is got finished by @mbabker today: https://github.com/joomla-framework/session/pull/12 but isn't merged yet so I didn't bother
[ ] Routing (because I couldn't work out at a glance how the current routing system really worked)
[ ] Work out how the component is going to interact with this app (99% of the CMS classes are not going to be injectable into this thing)
[ ] Work out how the app interacts with the frontend and backend of Joomla (things like JApplicationCms::isAdmin or the JPATH_SITE/JPATH_ADMIN constants
[ ] JLayouts don't exist on the framework level so decide if we want to port them into our app or use something like Twig, Plates, Blade or Moustache through the framework Renderer (currently I have ported JLayouts over)
[ ] Deal with replacing JDocument (cause it's never gonna exist in the framework cause it's a CMS weak link as it is) - as a temporary measure I've ported a simplified version of it into the app structure
[ ] Structure of the app - currently I only have media + index.php in the root. We might want to rework this in the future as a lot of cheap hosts don't allow this (which is why Joomla is installed by default totally into the root)

Specific Todos:

[ ] JUri::base() has a dependency on the Joomla config object. When this is now a service provider orientated object suddenly things become really hard really fast because you've got to pass either the configuration or Container in and things don't work. Michael in his Joomla Next! Repo ended up adding in a setBase and setRoot methods (https://github.com/mbabker/joomla-next/blob/master/libraries/core/Uri/Uri.php#L123) - but it doesn't seem ideal either. For now I've removed that section and just used the autodetection but it needs to be fixed before we put things live.
[ ] Do we want an interface for changing the application config (currently things that were in the params of the system plugin

chrisdavenport commented 9 years ago

I think this is ready to merge, but before I do it, can you restore the plugin code? For the moment we still need to keep the plugin working otherwise the admin component doesn't work. We can remove it again at a later stage.

Thanks @wilsonge.

javigomez commented 9 years ago

What will be the workflow now?

I mean, for the tests before I did:

download Joomla
Install Joomla https://github.com/joomla-projects/webservices/pull/17/files#diff-eccf834bcae4ac520d748d03c927336dR14
install the webservices extension: https://github.com/joomla-projects/webservices/pull/17/files#diff-0c314fdf3b778869f6b2fc1e5417f90cR17 that includes the plugin
Enable the plugin https://github.com/joomla-projects/webservices/pull/17/files#diff-210fd930d36f66f71e6e2f4fe78f5f8fR17
Enable webservices in the plugin https://github.com/joomla-projects/webservices/pull/17/files#diff-210fd930d36f66f71e6e2f4fe78f5f8fR21
Enable joomla basic authentication
Install contact webservices
Execute API tests

Now that is an app what would be the workflow for the tests?