By Private Profile fd6a0afe on 2018-06-11 08:22 in GSoC 18 Webservices in Joomla

Date: 28th May 2018

Time: 21:30 (CEST)

Meeting was attended by:

• George Wilson

• Andrei Isac

Meeting venue: Hangouts

 

Summary

Various issues have been discussed regarding current implementation, with the main focus on what features are needed when comparing to the Eloquent project.

 

Minutes of Meeting

 

1. Collection

Issue: Do we use/reimplement Eloquent “Collection”, or use simple arrays for managing multiple row results?

Solution: George: I’d like to have a collection sooner or later - but priority for now is to get single entities working and then thinking about relationships on entities. We might need a formal collection object for relations to work well - we’ll figure it out as the implementation progresses. Arrays are definitely fine for now whilst we work on the single entity implementation though

 

2. Dates

Issue: How to we handle dates? Eloquent uses something called Carbon. How is this dealt within the Database project?

 

Solution: Currently we have our own Date package split between https://github.com/joomla-framework/date (similar to the Date class in Joomla CMS https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Date/Date.php ) and https://github.com/joomla-framework/datetime (which was actually an old gsoc project). But as of our blog post last week https://developer.joomla.org/news/726-state-of-the-framework.html the plan is to move these to Carbon. So for now just do Carbon support - but we might go back and add support for the framework date package at a later point.

 

3. snakeAttributes and appends functionality

George: I don’t think we need snakeAttributes although I can’t see obviously what it’s for either (I guess normalising entity properties across relations?)

 

In the future we might want appends as helper methods for developers. But for now let’s leave it out. Keep things relatively simple.

 

4. mutatorCache

 

George: This is caching the results of the mutator just by storing it in a static class variable - parsing public methods even in native php isn’t very efficient. For development for now we can drop it - but almost certainly we’ll want to have this back in the finalised version.

 

5. Hiding attributes, Serialization, ArrayableAttributes

These three are all strongly related

 

George: You want to skip displaying certain attributes from an entity (e.g. passwords in a User Entity). We definitely want to have hidden attributes - however given that in core we’ll probably use JMS Serializer for the ‘day to day’ stuff in webservices - I don’t think we need the entity to have such complex support. Just having the concept of hidden attributes is fine without visible ones.

 

6. Json Editing

Issue: Do we support Json editing? I guess we do. This is such a nice feature.

 

Solution: George: Yes

 

7. mutateAttributeForArray

George: Mutations are required for reasons we’ve already kinda explained. I assume Arrayable is there so that when you have relations you can turn the relation into an array

 

8. Guard Attributes.

George: I need to think about this one - leave it out for now - but we’re going to need some sort of variation of it - it depends exactly how our entities integrate with the controllers

 

9. HasGlobalScopes

Scopes are a nice to have feature - but not part of the MVP for this package. Having relations and Collections is much higher priority. We can go back to them later on if we have time.

 

10. DatabaseDriver Dependency Injection

George: We’re going to inject the full JDatabaseDriver instance in the constructor. In our ‘framework’ entity package we don’t need to worry about how that is set up - it’s down to the implementer. In the CMS it will come from the DIC - database driver is configured here: https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Service/Provider/Database.php (retrieve via \Joomla\CMS\Factory::getContainer()->get(‘db’) or similar - depends on what exactly is db aware).

11. Events

Yes. But not for now.