By Private Profile fd6a0afe on 2018-05-18 17:47 in GSoC 18 Webservices in Joomla

Date: 10th May 2018

Time: 16:30 (CEST)

Meeting was attended by:

• George Wilson

• Andrei Isac

Meeting venue: Hangouts

 

Summary

The scope of the project was discussed, following my questions regarding the project(see below). The purpose of the meeting was to define the next steps I should pursue in the beginning. Various sources of inspiration for the Active Record pattern have been proposed. A short introduction about current Joomla implementation of the Models and Database Driver has been presented to be by George.

Questions

 

1. Where to start?

 

2. populateState. How is this avoided in the current API implementation? How do we solve the problem? I am not sure if some kind of dependency injection will solve the problem.

 

3. Model vs Table? What is the intended purpose for each of them? Do we need to change anything in the implementation or in the architecture?

 

4. Item, List Models merge, before or after the implementation of the Active Record pattern?

 

5. What would mean to implement the Active Record Pattern in the current state?

 

6. Active Record pattern means we have one Model per table, how do we map this to Joomla?

 

7. What is the difference between components Models and MVC (library models)? MVC model only works with Stats, while component model query the database?

 

8. Changing to the Active Record pattern would mean, rewriting every Model in every component, right?

 

9. How do we get Laravel mapping and querying functionality into Joomla?

 

10. Eloquent Events. Needed in Joomla?

Minutes of Meeting

Install lib api branch and install some sample data and you should be able to access urls via e.g.

 

http://localhost/~george/joomla-cms/api/index.php/article/2

 

Plugins register the available API routes e.g. https://github.com/joomla-projects/gsoc18_webservices/blob/lib_api/plugins/webservices/content/content.php (first parameter is route in string, second parameter is the controller name in the extension, third parameter is additional variables to set into the input object (e.g. component name))

Models

Populate state is a problem for us because it gets data directly out the application (input and session) and then stores it directly into the model. This pretty much couples directly to the frontend html page it represents. Ideally we want to start sharing model code between frontend, backend and API (the models may not be exactly the same but will likely share the majority of code with some permission changes). Dependency injection of state would solve a lot of this problem.

 

The library code is methods that facilitate getting data out the db and the component models contain methods focussing on the entity itself (e.g. the specific db query etc).

Table

Can only deal with single items and can only deal with non-related data. If either of those two things are required then you build db queries up in the model yourself with a query builder. If that’s ok (e.g. hits, simple load queries etc) then your model “proxies” the request to the Table object

New Solution

So we want to merge list models and item models and tables into a single active record model pattern that will live alongside the existing library code (and convert all core components across to the new system).

 

At the moment all our models are database aware. It would be nice (but totally a bonus) to change that and have a high level base model class that doesn’t depend on the database at all (it would just have a few top level model methods to help deal with state etc).

 

Laravel adaptations to Joomla have been done before e.g. https://github.com/akeeba/fof/blob/development/fof/Model/  The reason we can’t use laravel outright is because Laravel enforces a PDO connection - we don’t have one available.