Why do we actually need jtable

[Edric Navarro (enav)]

Hello

im being exploring the joomla code of com_content and i found that the model calls a jtable object to do operations in the database. 

I do wonder why joomla needs to add this "extra layer of complexity" why not just put all that jtable code inside the model. 

I mean it seems to me that all inside that jtable is perfectly fine to be inside a model. I may be missing something important if that is the case please guide me.

Thanks

[Niels Braczek]

Am 07.04.2017 um 21:27 schrieb Edric Navarro (enav):

> I mean it seems to me that all inside that jtable is perfectly fine to be
> inside a model. I may be missing something important if that is the case
> please guide me.

Look for "Separation of Concerns". JTable (following the Active Record
pattern) is not perfect, but way better than polluting the whole
codebase with database stuff.

Regards,
Niels

--
| New Stars on the Horizon: GreenCape · nibralab · laJoom |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[chris....@gmail.com]

I agree with the OP and in my extensions I don't use JTable. Life is simpler without it.

[Walt Sorensen aka photodude]

>  why not just put all that jtable code inside the model?

Simple,  follow DRY coding. i.e. do not repeat yourself. Sure for a single model component, you could get away with putting it in your model. But as the number of models increases, the more you need something like JTable. and when building a CMS with multiple components you definitely want to avoid duplication (duplication means more bugs, more updating, more problems, more wasted time, etc)
Additionally, not every model (or component) needs JTable like interfaces to the database. So following Separation of Concerns in the MVC pattern, you keep the Active Record and CRUD (Create-Read-Update-Delete) methodology stuff that JTable does in a separate class.


JTable does need work, but it's better than not having it. (handling of multiple primary keys is an area where it needs work)

[Todor Iliev]

The Active Record is ORM anti-pattern. We should avoid it.
It will be better if we see JTable replaced with Domain Driven Design patterns in Joomla 4.
It should be replaced with Entities, Repositories and Data Mappers.

The entities must depend on abstraction, not on concretions (database layers, services, etc.)
The architecture of Joomla 4 should follow S.O.L.I.D and DDD principles.

Nowadays, we are trying to do complex platforms using Joomla. We need better architecture to achieve our goals.

I am going to give you an example...

I was trying to do web services that send JSON data from Joomla website to a mobile application.
I was planning to do the web services via Laravel. I found that, I had to write the whole business logic and domain models. I had to reinvent the well.

It will be great if we see much more abstraction in Joomla 4.
For example, in my case, I would be really happy if I was able to download CMS library via Packager to my Laravel instance, just like other Joomla Framework classes.

So, I will only be able to do Laravel repository that will load the content from database. Then, I will use the Data Mapper from Joomla CMS libraries to create an object or collections. It will not be necessary to reinvent the well.

$dbAdapter = new Database();

// It should be possible to use any database layer. It should follow Dependency Inversion principle
$repository = new Cms\Content\Repository($dbAdapter);

// It will return Cms\Content\Article ( Entity ).
// The repository will load the content form database and will create an object Cms\Content\Article, using Data Mapper.
$articleId  = 1;
$article    = $repository->findById($articleId);

// Save the article.
$article->setTitle("New Titile");
$repository->save($article);

// It will return Collection.
$userId     = 2;
$articles   = $repository->findUserArticles($userId);

As a result...
We will be able to use Joomla objects and data everywhere where we need - via Simfony, Laravel, Zend Framework, Lumen,.. Joomla CMS could be used as a website. The popular framework could be used for web services, micro services or other enterprise solutions using Joomla libraries.

Here you are more information.

ORM Is an Offensive Anti-Pattern
ORM anti-pattern series
Are there good reasons not to use an ORM?

Domain-Driven Design in PHP
Domain-Driven Design: The Repository
Domain-Driven Design: Data Access Strategies

Rich vs Anemic Domain Model
Anemic vs. Rich Domain Objects—Finding the Balance

[Niels Braczek]

Am 07.05.2017 um 23:40 schrieb Todor Iliev:

> The Active Record is ORM anti-pattern. We should avoid it.
> It will be better if we see JTable replaced with Domain Driven Design
> patterns in Joomla 4.
> It should be replaced with Entities, Repositories and Data Mappers.
>
> The entities must depend on abstraction, not on concretions (database
> layers, services, etc.)
> The architecture of Joomla 4 should follow S.O.L.I.D

> <https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design>
> and DDD <https://en.wikipedia.org/wiki/Domain-driven_design> principles.

That's exactly what we're doing with Joomla!X. Joomla!4 can only be a
step in that direction. If we change too much too fast, our developers
will probably not be able or willing to follow - that would not be good
for the project.

[Michael Babker]

Responding to this part specifically...

On Sun, May 7, 2017 at 4:40 PM, Todor Iliev <tosho...@gmail.com> wrote:

I would be really happy if I was able to download CMS library via Packager to my Laravel instance, just like other Joomla Framework classes.

Odds are at this point the stuff that isn't already in our Framework stack probably won't be abstracted either because it is too coupled to or is very specific to the CMS environment (i.e. JHtml or JDocument are too coupled, our extension installer and updater are app specific) or are resources that at this point there are much more mature options available in the PHP ecosystem (I wouldn't recommend copying JTable to a Framework based project at this point, I'd just use `joomla/database` and do all the "hard" work myself or use something like Eloquent, Doctrine, or one of the numerous other ORM systems).

[Todor Iliev]

I agree with you Michael.
Furthermore, main components like User, Access, Rules are coupled to the CMS and it is impossible to be used in other environment.

I see, you are going to refactor many of the CMS classes. I would like to ask you to decouple the domain models from the persistence layers. You should do the domain models much more abstract.

So we will be able to reuse the code in other environment.
It should be easy to authorise users in Laravel or Simfony. I will only have to do a repository that will load the data from database and will create an object User.

$repositoryContent = new Joomla\Cms\Content\Repository;

$articleId = 1;
$article    = $repositoryContent->findById($articleId );

$repositoryUser = new Joomla\Cms\User\Repository;

$userId  = 1;
$user    = $repositoryUser->findById($userId);

if ($user->authorise('core.edit.own', 'com_content')) {

     if ($user->getId() === $article->getUserId()) {
        //....
     }
}

If you would like, you can do Content domain model ( Joomla\Cms\Content ). It will be the first piece of the new architecture. The production team will be able to follow that model in future refactoring and implementations.
Furthermore, the developer will be able to follow this model for their extensions.
You can deprecate JTable to prevent its use in future projects.

[chris....@gmail.com]

"You can deprecate JTable to prevent its use in future projects."

... Another reason why I don't use JTable. Everything in Joomla eventually gets deprecated. Far better to use your own code.

[Hannes Papenberg]

Sorry, but that is just bullshit. Joomla has not removed code for the
last 5 years and the main parts of J framework code have stayed the same
for the last 7 years. If you developed code for J (and followed good
practice), your code worked for roughly 5 years without any major
maintenance. So spreading such a statement like yours is just false and
results in "clever" developers writing their own code, which then breaks
on each update and people start complaining that Joomla is at fault.
Stop doing something like that and stop claiming Joomla would change to
fast or remove code to often or constantly break or anything of the
above. Joomla actually is a remarkably stable (development) platform.

Hannes

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cm...@googlegroups.com>.
> To post to this group, send email to joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/d/optout.