Coding Strategy - lack of isomorphism with components

[konchog]

I'm still very new to Joomla, and maybe this is the wrong place to talk about it, but I'm pretty confused by the behaviour some of the core classes of Joomla.

I love the MVC, and HMVC pattern. When dealing with modern OOP environments, they work so well, and Joomla's commitment to MVC is fantastic.

What I am mystified by are things like setting constants in the middle of a Helper class method.
cf. JComponentHelper / renderComponent(). lines 313-315.

What these lines imply is that Joomla expects only one component to be rendered per http request.
So, all the work of getting classes to render themselves using the existing context is all burned up, and instead coders are expected to author their own views, and use loadTemplate() etc. as a means of rendering objects.

Likewise there is an issue in JViewLegacy (which doesn't expose itself if one only ever renders one component per request) - the getView() method there uses it's own mini-cache, but the cache signature is keyed solely by the component name, regardless of whatever context is given. Because the cache (static $views) is defined within the method itself, there is no access to the cache, or any ability to force a 'no-cache' on the method call.

The development strategy of Joomla is good - isomorphism is used all over the place (eg, components, menu-items, menus, are all isomorphic) - so why is there no isomorphism regarding the component(s)/request relation?

I may be doing nothing but demonstrating my extreme ignorance - but some kind guidance on these issues would be very welcome.

[pe7er]

What I am mystified by are things like setting constants in the middle of a Helper class method.
cf. JComponentHelper / renderComponent(). lines 313-315.

What these lines imply is that Joomla expects only one component to be rendered per http request.

I don't fully understand your question as I a not familiar with the term isomorphism,
but in Joomla you can have only one component "running" at a page (request)

If you switch SEF off totally, you can see URLs like: /index.php?option=com_content&view=x...
$option retrieves the component (in this case com_content) and the component then will take control over what it should do. The controller (or controllers) within a component define which behavior(s) are possible in that component (edit, save, delete etc). Components can have multiple modi that are triggered by the "view" variable (display a list of items, display one item, display a form of one item).

So on a Joomla website you cannot have two components running at the same time.

[konchog]

I didn't mean isomorphism, I meant orthogonality. Sorry.

on a Joomla website you cannot have two components running at the same time.

To be frank, when you say 'same time' you don't mean 'concurrently' - as PHP doesn't really support concurrent processing - you mean 'during one http request'.

But this issue begs the question of why there are request-level caching aspects to component rendering. A request-level cache for something which cannot be rendered more than once per request is meaningless additional work.

Also, can it not be seen that the request is not the only driving force for rendering components? If I wish to render a menu-item object as a part of another request, then the strong binding to requests precludes that ability, needlessly.

Components that are 'one-shot' lose their efficacy and power - and yet Joomla has worked hard to make it easy to manage, render and deliver components - more than anything else.

Your answer merely tells me what I discovered - that Joomla is designed to deliver one component per request. You explain how this is the case (mentioning the dependency of the URL). What you don't do is to explain why Joomla development have decided limit components to this - why they thought it was a good idea, and why anyone would want to commit to that decision.

[pe7er]

To be frank, when you say 'same time' you don't mean 'concurrently' - as PHP doesn't really support concurrent processing - you mean 'during one http request'.

Yes, that's what I meant.

But this issue begs the question of why there are request-level caching aspects to component rendering. A request-level cache for something which cannot be rendered more than once per request is meaningless additional work.

Also, can it not be seen that the request is not the only driving force for rendering components? If I wish to render a menu-item object as a part of another request, then the strong binding to requests precludes that ability, needlessly.

I suppose that you can better ask this question at https://groups.google.com/forum/#!forum/joomla-dev-cms because that's mostly used by Joomla CMS developers.

Your answer merely tells me what I discovered - that Joomla is designed to deliver one component per request. You explain how this is the case (mentioning the dependency of the URL). What you don't do is to explain why Joomla development have decided limit components to this - why they thought it was a good idea, and why anyone would want to commit to that decision.

I guess that it's part of the Mambo legacy and that this approach has been decided in the early 2000s.
Because components are so fundamental to the functionality of a page, I don't think that this can and will be changed easily.

If you want to run other parts of code at the "same time" (= during different stages in the process) of the component, then you can use plugins. Components have different events (or hooks) that can trigger a plugin.

E.g. the content component has 13 different events that can trigger a plugin. Combined with the system plugins that always run (and which have 8 different events) you have a lot of places where you can add functionality (= run your own code "alongside" a component).
More information: http://docs.joomla.org/Plugin/Events

[konchog]

Peter, thanks for your thoughts. I don't want you to think for a minute that I am moaning about Joomla - I think that it has a lot to offer.

I am already very familiar with plugins, but the very first website that I've been developing, there is an overarching need to render different components (as defined by their presence as menu-items) on a single request.

I managed to develop solutions for doing exactly this, but the process was deeply complex - and made so by the above constants in the middle of code, using internal caching and so on - so I had to extend or rewrite some core classes (and inject them via the plugin mechanism) .

The thing that I like about components via menu-items is that they 'render themselves' using all sorts of overrides as a part of the process (including the plugin events) - which is the 'why' of it. The ability to render components freely, regardless of the current request, brings an incredible depth of ability to Joomla.

I will follow your suggestion and rewrite / repost my thoughts on the other forum.

Thank-you again for your support.

[pe7er]

I don't want you to think for a minute that I am moaning about Joomla - I think that it has a lot to offer.

No, constructive criticism is welcome.

I managed to develop solutions for doing exactly this, but the process was deeply complex - and made so by the above constants in the middle of code, using internal caching and so on - so I had to extend or rewrite some core classes (and inject them via the plugin mechanism) .

Nice! I suppose that you've probably found out yourself already that you can use a plugin to override some of the core classes:
load your alternative classes (with same core class name) before Joomla does load its own core class.
Joomla's use of require_once / include_once won't load its core class again after your version has already been loaded.

[konchog]

Nice! I suppose that you've probably found out yourself already that you can use a plugin to override some of the core classes.

Yes indeed, this is nice when it works. However, it is very frustrating when it fails! For instance, JComponentHelper cannot be overriden because it is loaded before the onAfterInitialise injection point.

[konchog]

What I was looking for (but in the wrong place) was the FOF Library, especially as found in
https://www.akeebabackup.com/documentat ... /hmvc.html

[konchog]

What I was looking for (but in the wrong place) was the FOF Library, especially as found in
https://www.akeebabackup.com/documentat ... /hmvc.html

Actually, it turned out that this wasn't so useful either, as fof only works with fof.
In the end, I managed to get Joomla! core to deliver what it was that I wanted, although the current version has some pretty big problems. (such as the aforementioned constant declarations in a member function.