sharing code across components

30 views
Skip to first unread message

Richard Slabbert

unread,
Mar 31, 2021, 9:38:42 AM3/31/21
to Joomla! General Development
Hi there,

I am building two similar components that share quite a bit of code.  Instead of having duplicate code, what is the best practice for sharing this code between the two components?

Kind regards,
Richard

Roger Creagh

unread,
Mar 31, 2021, 10:32:50 AM3/31/21
to joomla-de...@googlegroups.com
I second this question! I have the exact same situation. In my case each component has to be able to stand alone, but they are frequently installed and used together (they share some data tables as well).

As far as I can see the best answer is to put the shared code in a Library - but I am not clear how best to share language strings and css. There are a lot of common language elements and I can't see how to put language files in a library. Same for style sheets.

I found this on how to use a library extension: https://docs.joomla.org/Using_own_library_in_your_extensions

I guess you then package the library extension with each component in a pkg zip.

An authoritative answer would be much appreciated.

I'm also grappling with the best way for each component to know whether the other is present or not both for runtime actions on the shared data and also if a component is uninstalled - there being no pre-flight for uninstall it is difficult to for the component being uninstalled to know if it is the last one and thus safe to uninstall the shared data table. 

RogerCO
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/joomla-dev-general/62e47e41-3e57-447b-b105-fcb910c3f864n%40googlegroups.com.

Richard Slabbert

unread,
Mar 31, 2021, 11:15:52 AM3/31/21
to joomla-de...@googlegroups.com
Thanks Roger for sharing your insights. Those are valid considerations I hadn't thought of. 

It will be great to get an authoritative opinion on this. 

Richard



You received this message because you are subscribed to a topic in the Google Groups "Joomla! General Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-general/jtbFd1CL4oc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-gene...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/joomla-dev-general/ab269340d59688248b77f3248afe5b42297a1634.camel%40gmail.com.

Polyna-Maude R.-Summerside

unread,
Mar 31, 2021, 12:34:22 PM3/31/21
to 'Roger Creagh' via Joomla! General Development

You don't package the same library with multiple different components.

The basis of a library to install once and be used by many.

Regarding the use of language strings, there's already good documentation on this subject.

You can check inside Joomla table to know what components are installed and manage dependencies this way.

To view this discussion on the web, visit https://groups.google.com/d/msgid/joomla-dev-general/ab269340d59688248b77f3248afe5b42297a1634.camel%40gmail.com.
--
Polyna-Maude R.-Summerside
https://www.polynamaude.com/

-Be smart, Be wise, Support opensource development

Mise en garde concernant la confidentialité

La présente communication est confidentielle et transmise sous le sceau du
secret professionnel. Si vous n’êtes pas le destinataire visé ou son
mandataire chargé de lui transmettre cette communication, vous êtes par
les présentes avisées qu’il est expressément interdit d’en dévoiler la
teneur, de la copier, de la distribuer ou de prendre quelques mesures
fondées sur l’information qu’il y est contenu. Si vous aviez reçu cette
communication, par erreur, veuillez nous en aviser immédiatement par
téléphone (frais virés) et nous retourner l’original sans tirer ni garder
de copie, soit par la poste à l’adresse ci-haut mentionnée.

Confidentiality Notice

The information in this transmission may contain
privileged and confidential information and is intended only for the use
of the person or corporate entity to which it is addressed. The
confidential nature of this communication remains regardless of whether or
not you are an intended recipient. If you are not an intended recipient,
please notify the sender immediately and destroy this message and all
attachments, without making a copy. Any distribution or reproduction of
this message is prohibited. We assume no liability for the interception of
any Internet communication or the transmission of computer viruses.

CP 99900 FJ 782 595
SUCC ST- DOMINIQUE
MONTRÉAL QC H2S 0E3

Roger Creagh

unread,
Mar 31, 2021, 1:23:24 PM3/31/21
to joomla-de...@googlegroups.com
On Wed, 2021-03-31 at 12:34 -0400, Polyna-Maude R.-Summerside wrote:

You don't package the same library with multiple different components.

Well if the component depends on the library, you have to package them together - you are not going to require the user to install the library first separately. What I see big developers doing is have a mechanism during install preflight to check that the install will not downgrade an existing library install, and if the version in the package is later than what (if any) is currently installed then go ahead and install it over the top (upgrade) of the earlier version.

Does  mean you have to tack care to ensure new versions of the library are backward compatible with anything that might be in the field.

The basis of a library to install once and be used by many.

Yes, but see above

Regarding the use of language strings, there's already good documentation on this subject.

Well I've not been able to find where to put language files that are independent of any one component. I suppose you could create a dummy component with just the language and css files and package that with each individual component (again with version checking on install) then all of the components could use the dummy component language files (and media/css) but that seems a bit clunky

I've not been able to find how to access a language file in with library that is not tied to a specific component. I think it is possible for css, but JText and JHtml expect language files to belong to an extension don't they? Or can a library include a language file reference in its xml - but where will JInstall put it so that other extensions can access it?

Can you point to the relevant document please?

In my case there are a small number of strings that are specific to each component, and a vast number that are common across components. So each component has to have its own language file in the normal way; but it seems very wasteful (and difficult to maintain) to have all the common stuff be duplicated in each component's own language file.

You can check inside Joomla table to know what components are installed and manage dependencies this way.

Yep, but when I tested it it is between 10 and 100 times faster to check a session variable than to hit the database to look up if an extension is installed and enabled every time you need to (which may be fairly often if you are sharing a data table between components). So I try and check the database only once per session and set a session variable unless I have to be absolutely sure that the other component hasn't been changed in the meantime (although regular install/uninstall does change the session variable but something silly might happen)

Roger

Polyna-Maude R.-Summerside

unread,
Mar 31, 2021, 2:35:45 PM3/31/21
to 'Roger Creagh' via Joomla! General Development

See answer below...

On 2021-03-31 1:23 p.m., 'Roger Creagh' via Joomla! General Development wrote:
On Wed, 2021-03-31 at 12:34 -0400, Polyna-Maude R.-Summerside wrote:

You don't package the same library with multiple different components.

Well if the component depends on the library, you have to package them together - you are not going to require the user to install the library first separately. What I see big developers doing is have a mechanism during install preflight to check that the install will not downgrade an existing library install, and if the version in the package is later than what (if any) is currently installed then go ahead and install it over the top (upgrade) of the earlier version.

Does  mean you have to tack care to ensure new versions of the library are backward compatible with anything that might be in the field.

You said the solution in your own question...

What you called "big developer" are simply "developer using library".

Yes if you change stuff on your way, and end up with outdated library you'll have problem later on if you don't make sure of compatibility.

This is the basis of all complex software solutions. And one reason there's a thing called "Dependency hell" in Windows !

Maybe it's not worth saving some disk space for making your system overly complex if you don't master all of the development practice related to dependency management.

I don't see that many Joomla components / modules / etc using library and those who do (example JD Social Login / JD Social Share) are mostly using outside library that don't interface directly with Joomla.

You can always add some abstraction layer if needed, that's called a shim.


The basis of a library to install once and be used by many.

Yes, but see above

Regarding the use of language strings, there's already good documentation on this subject.

Well I've not been able to find where to put language files that are independent of any one component. I suppose you could create a dummy component with just the language and css files and package that with each individual component (again with version checking on install) then all of the components could use the dummy component language files (and media/css) but that seems a bit clunky

I've not been able to find how to access a language file in with library that is not tied to a specific component. I think it is possible for css, but JText and JHtml expect language files to belong to an extension don't they? Or can a library include a language file reference in its xml - but where will JInstall put it so that other extensions can access it?

Can you point to the relevant document please?

In my case there are a small number of strings that are specific to each component, and a vast number that are common across components. So each component has to have its own language file in the normal way; but it seems very wasteful (and difficult to maintain) to have all the common stuff be duplicated in each component's own language file.

You can check inside Joomla table to know what components are installed and manage dependencies this way.

Yep, but when I tested it it is between 10 and 100 times faster to check a session variable than to hit the database to look up if an extension is installed and enabled every time you need to (which may be fairly often if you are sharing a data table between components). So I try and check the database only once per session and set a session variable unless I have to be absolutely sure that the other component hasn't been changed in the meantime (although regular install/uninstall does change the session variable but something silly might happen)

No doubt it's faster to check a session variable than to check something in the database.

But we are getting really far from the initial talk here.

You check for component installed and dependency (in this case the library) at the moment you install them or remove them.

So there's not much of a issue on the time it take. Because anyway, the installation of a component require interaction with the library.


Roger

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

Polyna-Maude R.-Summerside

unread,
Mar 31, 2021, 5:44:55 PM3/31/21
to 'Roger Creagh' via Joomla! General Development

Hi !

Maybe you wanna explain better what you are trying to build ?

If you give me example I could better give you a answer.

For example when is it better to simply reuse code and when is it better to go for the library options.

What else is possible to do (custom hack)...

I felt my first answer may sound a bit rude...

Sorry for this.

Don't hesitate if you got questions.

If you want, I can leave you my professional website (Running Joomla).

It's quite ugly but if you go there and register then we'll be able to exchange private email.

I just don't want to leave my email here because I know some scanning robots may pick it up...

https://www.polynamaude.com/

https://www.polynamaude.org/

I know it's ugly but I'm really not a web designer, everything that seem close to be artistic is quite hard for me. I'm a more into code development and for a while being doing security assessment (PCI-DSS).

Hope this help you out.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

Richard Slabbert

unread,
Apr 1, 2021, 2:03:21 AM4/1/21
to joomla-de...@googlegroups.com
Hi,

Please cc me in to those emails if possible!  I am interested in this conversation.  richard.slabbert94 at gmail.com

Thanks!
Richard

You received this message because you are subscribed to a topic in the Google Groups "Joomla! General Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-general/jtbFd1CL4oc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-gene...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/joomla-dev-general/2f0265a3-d3ca-af82-e918-b57b052cff32%40gmail.com.

Roger Creagh

unread,
Apr 6, 2021, 10:04:09 AM4/6/21
to joomla-de...@googlegroups.com
Hi Maude,
Sorry for delay replying, been a busy weekend. I didn't think you were rude at all, maybe terse but that's ok. 

In slightly less brief detail:
Two separate components either or both of which may be installed and both of which use the same data table (details of persons - name etc) as well as several other data tables of their own (including their own many-to-many link tables between the persons table and some of their own tables.

Both the main components get installed with a separate component (com_people) that handles creating and editing people info in the common persons table. Each of the main components can be installed on its own with the common people component or both can be installed (which opens some additional functionality in the main components as they are aware of each other).

Separating out the people handling bits into a separate component was my first pass at facilitating the sharing of the people data between the two main components. For example the categories and tags have to be shared between the main components, so the separate com_people enables that to work seamlessly whichever of the main components is installed.

I find that a fair amount of code is common between the main components (often identical with only data table names changing in some functions which could be passed as parameters to a library function). Also language strings and stylesheets are very common between all.

Originally I was trying to maintain it so that each main component could be installed on its own without the common people component, but now I think it is better to require the common com_people component and simply have the two main components use the language and css from that - thanks for the link to the extra article on sharing language files by the way, I had missed one of those that contains the key info needed to get it working.

So I guess the only issue remaining now is to move the shared code (much of which is already in individual helper files for each of the three components) to a library - and then each of the two main components would come as a package containing the main component, com_people component, and the library extension.

That seems easiest from the site admin's point of view. I just have to make sure updates are backwards compatible.

Do you agree? Is there a better way you can see?

RogerCO
Reply all
Reply to author
Forward
0 new messages