User tests: Successful: Unsuccessful:
In a move that helps with #96 and #115 these are the first steps towards dropping the use of Joomla\Factory
and implementing DI code.
Essentially, for what is being used in the codebase currently, we don't actually need to register anything to Joomla\Factory
, so our first version of DI is a hybrid Factory/DI implementation (similar to that David & Don use in Cobalt) and the application and database objects are registered as service providers and globally accessible via JTracker\Container::retrieve($key);
. Other objects can be refactored out of the application and into the DI structure if this works for everyone, and as the parent Framework completely shifts Factory out and embraces the DI Container, we can shift away from our hybrid solution to a more pure implementation.
There's also a few miscellaneous admin tasks included here:
JPATH_BASE
(similar to what I just did with the Framework)Definitely can do some documentation this weekend. Doesn't have to be set in stone on this being how we use it, I've just found this is one of the easier ways to do it without refactoring everything to pass the DIC around or build objects using the DI code (like I said, it's based on some logic on how David & Don do it in Cobalt and I did something similar with another project).
So I spent a sunday afternoon on this and since we have no docs, and I don't know Cobalt.., I feel I did something wrong. It just feels too simple, yet it works..
First question: What is the purpose of the alias method of the tracker container. As far as I can see the full class name is also just used as a key.
So I first did an application provider for the CLI app (that might be used also by the web app) and then a config provider that is used in both apps.
Since this felt too simple, and being a DI noob ;), I'd like to know if I missed a crucial design point somewhere...
Ya, so I need to find another 12 hours in the day to get to everything I said I need to work on. But it really is simple to make it work once you have it working.
Cobalt is actually using a different (& what I'd consider better) DI container which includes the extension Don added specific to them which allows aliases. If you used the DI purely as it should and not as a glorified Factory, building objects from the DI wouldn't work well because the Joomla DI uses the type hinting as defined and can't traverse the chain (check if what's being provided is an instance of the type hint). So the alias works around that.
So this is how we are going to use this new toy. Would it be possible to add some words to the Documentation ?