Joomla! Discussion Forums

I am working on a component that needs to transform content before it gets displayed to the user. Most of this transformation is identical independent of whether or not it's being displayed to a user or edited by an administrator. It's a non-trivial process that's attached to a fair bit of code.

The most logical approach to this seems to be to create a helper class, similar to those in com_content. But I don't want to create a copy of the code for each branch of the source tree.

It seems that what I'd like to do is to put common code into /libraries/joomla/components/com_mystuff, or maybe /libraries/components/com_mystuff to keep the joomla branch clean.

Does this make any sense? Is there a prescribed "best practises" place to put component-level libraries?

Would it be better to extend a given class, overloading the methods that you want to change?

I keep a /components/com_lqm/library/lqm/ directory for all of my common code.  Well, thousands of ways to do it really.  Just a suggestion.

Extending a class was the intent of course. It was more a question of where to put the base class(es). None of the core components use this strategy (although JContentHelper should, IMO).

I think your suggestion is a good one. I'm going to use it. Hopefully it will become a best practise! 

Thanks.

Arrg!  I was just thinking about this and was going to suggest that your's was better. 

For example, if I could put all of my common lib code in /libraries/extensions/lqm/, to load one of my libs all I would need to do is a jimport('extensions.lqm.something').  Actually for me this would create some problems because I would need to rename my files from lqm/variables/list.input.variable.php to lqm/variables/input/list.php, but not a big deal.  I have about 20 such files ( in addition to MVC files).  It would be easy for my component, module, or plugin to load the libraries, or the libraries of other extensions.

To implement this, there would need to be a new install tag that would be parsed by the installer.  Other than that, I can't think of any other implementation issues, can you?  I bet it would be less than a dozen lines of additional code.

In adapter class:

Code:

$this->parent->parseFiles($this->manifest->getElementByPath('libraries'));

In JInstaller::parseFiles() :

Code:

      switch ($element->name())
      {
         /* blah blah blah */
         case 'library':
            $extension = strtolower(str_replace(" ", "", $this->get('name')));
            $destination = JPath::clean($client->path.DS.'libraries'.DS.'extensions'.DS.$extension);
            break;
         /* more blah blah blah */

Edit: BTW, why does the installer contain so many parseX() methods which are nearly identical?  If the only difference is the destination, a method named getDestinationForElement() would be a lot clearner.

The idea of having a 'component' libraray sounds good to me. I did suggest somthing similar earlier, the idea of having seperate installers just for libraries. That way it would be possible to build up common third party libraries, for example a bbcode parse, and then add dependencies to components... But I didn't get any response .

I think I never considered component/com_mycomponent/libraries because I have this intuitive sense that "cross-talk" between /components and /administration isn't a good thing. I don't have a technical justification for this, it's just a gut feel.

What makes tcp's suggestion good is that it seems that there's no quick answer to this issue from the core development group (questions of this nature do seem to go unanswered) and I need to write code right now. Sticking stuff under the component is at least guaranteed not to cause conflicts.

A disadvantage is something webamoeba touched on: if you're building libraries for use by more than one component, then the /libraries tree is the right place to put the code. However without guidance from the core team, it would be a very bad thing to have hundreds of extension developers each pick a different one of the thousands of solutions tcp refers to.

I think that part of the problem is that we're pushing the J1.5 envelope a little bit. I think sometimes we ask questions about issues that have been deferred to J1.6 or even J2.0. As much as we demand more information from the developers, they're working flat out to get J1.5 beta 2 out the door and don't really have time for stuff that doesn't appear to be on the critical path. The flip side of this is that a spanking new final release of J1.5 won't be as impressive as it should be if extension developers don't have the resources required to build and release their work in a similar time frame. It's a tough situation to be in, and I feel for them, even as I ask for more and more information!

As far as handling libraries in the installer is concerned, I think "be patient" is the right thing. The core devs have indicated that there are good things coming, post J1.5. Details are scarce, but there was a Google Summer of Code project dealing with installers and dependencies. My bet is that a look at this in the developer forge will provide a hint of what's in store. Any ability to install common libraries is going to have to be aware of version restrictions and dependencies; it's far from a trivial problem.

Instance hit the nail on the head with this one.

We don't mean to be silent on particular topics... sometimes they go unnoticed... sometimes we don't really have good answers ... and sometimes to be honest I just don't want to write a lengthy explanation of something   Those times aren't too often thankfully

There are some interesting questions that arise of this topic and I will address things as best I can.

First:  Library installer... yes technically we could throw a new tag in that puts libraries in a given place, but we have opted not to do that for 1.5.  The reasons vary but the main one is that we feel VERY strongly that introducing library installation without a solid dependency system is a nightmare waiting to happen.  Research has been done on the topic and as instance points out there was a SOC project that did a lot of work in the area.  We absolutely will at some point support this fully -- and personally I cannot wait -- but we already have enough to do for this release finishing out the goals that we KNOW we need to put in 1.5

Second:  You guys are pushing 1.5 and I love that.  It is great to see people looking at this brand new code base and seeing all the possibilities.  It is most satisfying.  That being said do understand that we know our limitations as well.  Some are inherent and some are not.  Those that we feel can be helped we are certainly willing to work with you guys.  I think our track record has shown that

Third:  And this is the tough one... where do you put these common files?  I had brainstormed on the topic quite a bit with a few devs And I came up with what I think is a pretty good hybrid solution...  If you look at the diagram at: http://dev.joomla.org/content/view/1137/80/ you will see there are two items on the framework tier of the architecture.  Libraries and Plugins ... plugins are meant to extend functionality and/or add to functionality in one way or another.  So how about this for an idea... I will use com_test for an example:

com_test depends upon lib1.php lib2.php and lib3.php
mod_test also depends upon lib1.php

The best way of grouping files for the common libraries is as follows:

/libraries/lib1.php
/libraries/lib1/lib4.php
/libraries/lib1/lib5.php
/libraries/lib2.php
/libraries/lib3.php

Well... what you need is a way to load the libraries from anywhere... in a location in the architecture that is independent of any given component or module.... so... create a plugin.  The plugin doesn't even have to register itself to an event.  All the plugin helper does is include the file... it doesn't register the plugin ... plugins are self registering so this will be easy to do.



You would set the plugin to install into your new custom group test so that the base filestructure would look like:

/plugins/test/test.php
/plugins/test/test.xml
/plugins/test/test/libraries/lib1.php
...


This approach gives you some interesting possibilities.
* you could have different library sets if you wanted (probably not the best idea in most cases)
* you could actually have parameters for a given library set (i can't think of a good reason but someone might have one)
* you can check in your component/module whether a library set exists and what version it is by simply checking if your define is set and what its value is
* your libraries are now installable and independent of any other extension


Louis

... and live is good again

Wow.  I have no idea what this means.  :p

Otherwise, awesome.  Thanks for the feedback ( all previous posts ).  I'm glad that someone is brighter than I am and has thought about this already.

oooo, I like the plugins idea, I'll have to go and have a play with that later. My only concern would be that plugins don't have seperate folders, so you'd have to be careful with naming...

Thanks for the nice lengthy reply loius

I think having been working with 1.5 for a while it's easy to forget that it's still in beta and that live sites are all still using 1.0. Hence we always seem to be tyrying to get more out of it. Thanks for all the great work Joomla! teams!!!!

ps I think live = life :p

By default a plugin is only one file, that doesn't mean you cannot use a subfolder in the plugin directory to add more files too. For example you could add one directory with all your extensions specific libraries and then have a few plugin functions that can load libraries for you. Kinda like our JLoader but then in a plugin.

Yup, I realise that you can add folders.

What I was trying to get at was possible conflicts between two plugins. For example, the possibility of two plugins both defing a folder called 'lib'... The obvious thing to do is to name the folder the same as the plugin,as per lois example, but it's not infalable. If this type of methodology becomes the recomended way of building 'custom libraries', perhaps its worth considering seperate folders plugins, the same as  modules and components?

Indeed Louis, thanks for the detailed response. I think this makes a great deal of sense, as does storing common code in /plugins/my_plugin (although central name allocation is going to be a problem, maybe we should consider a reverse domain name hierarchy, as in plugins/com/ambitonline/whatever, like Java classes). Too bad the PHP guys think class namespace conflict management is something for PHP6.

You also have to install and publish a plugin for a single component that uses the library.  There may be many cases where a Joomla admin wants to use just the component and not other related extensions.  If libs where a plugin, the admin's "work" has now increased by 300%.

But overall this is a good solution and one that is already supported by the current framework.  Bonus!  I like the idea of being able to update the libs without reinstalling a component. 

I guess these would be system plugins.  Or, library

@instance: Yeah, I miss the java/perl namespaces.

@webamoeba: I would love to see plugins to go into folders as well.

This is a very interesting thread folks!  I'd like to take a stab at writing a sample library loader.

tcp

If you were really clever you could auto install/publish the library/plugin in the custom install script for your component install.component.php ...
similarly you could auto unpublish/remove it when uninstalling the component with the uninstall.component.php script.

Or the admin has to install a plugin.... it may be 300% increase (not sure how you are calculating that) but installing extensions is easy and not done often so I think the tradeoff is not bad.

I would use a new plugin group for each library set .... its not going to hurt anything and it gives you a good bit of flexibility.

for instance... if I am a dev with lots of extensions that use my common libraries ... and my website was http://www.foo.com I could create a new plugin group called foo

/plugins/foo/foo.php
/plugins/foo/libraries/*

eg. install file

....

  foo.php



this installs the plugin to the group foo ( foo subfolder of plugins folder ).

You could certainly be creative with how you structure it... this is just an idea

Louis

The foo idea is workable, although the only persistent problem I have with my own suggestion is that names of controlling/sponsoring organizations are a lot more dynamic that one would expect. Transitions such as Mambo/Joomla are surprisingly common, as companies change names, get acquired and so on. It's a pain to have to go through refactoring everything just because the marketing department decides that a new name will improve sales.

Ideally Joomla allocates guaranteed unique extension identifiers through a request on the site. Then we can use that identifier for install paths and incorporate it into public names. Assuming an identifier might be j followed by a number, com_j12_test might be a little ugly in a URL, but it beats trying to sort out three components called test. Typo3 does this and it seems to work well.

Joomla doesn't support different components with the same name ... you can have only one com_test so that shouldn't be a problem.

As for making sure that the libraries you expect are present..

just do a plugin import

// Import test libraries
JPluginHelper::importPlugin('test');

and then check for a define that you know to exist in your library set.  If it isn't there.. die gracefully

Louis

"Test" was a lousy example, sorry. I'm talking about two or more independent developers who all name their component "coolstuff", although each does completely different cool things. Then I decide I want to use more than one of them. Without some well defined way to arbitrate these sorts of name conflicts, they're going to become more common. If the first dev got a centrally assigned identifier of "j345" and the second got "j615" then the components would be called j345_coolstuff and j615_coolstuff and there would be no problem deploying them in the same installation.

I'm not sure if the mechanism described above is good or ugly; it's the concept that's important.

I've done it again; this should really be in a topic of it's own.

P.S. @louis: congrats, you just cracked the 1,000 post mark; you're a lifer!

Ah ... I see what you are saying now... and ya thats an idea that has been bounced around... but not something we are planning on doing at least for the 1.x series.  Would be a good topic for debate when the design process on 2.0 gets underway.

on the 1000 posts... i guess there is no turning back now *sigh*

Louis

Maybe a 1.6, 2.0 or simply post-1.5 forum could be created for all technical discussions that are out of scope for 1.5.
I'm thinking of a couple of ideas myself that might be nice later on. :-)

I've been posting my "out there" musings in "Wishlists and Feature Requests" http://forum.joomla.org/index.php/board,38.0.html

I;ve been writing mine on small bits of paper, and burning them on a fire, I'm told that's how you post things to Santa .
And with all his 'little helpers' you'd think he cud do summit lol

Sorry kid, this is open source... YOU are Santa!

(off to see if I've been so far good this year *laughs*)

It's a Friday and I know my brain is shutting down so forgive me if this question re-asks what is written above, but I am trying to create a common library that will be able to be used over lots of other components.

From what I read above, am I building a plugin that will mean that I can call it to install custom libraries to a given path, or am I installing a plugin, with a separate xml file that installsthe actual library??

So tired.......need sleep, shame its 9.55am 

Of course there are many ways to share common libraries.  I think we were discussing two ways.

1) Install the library with one of the extensions ( eg, with the component ) and then reference them in your other extensions.  I think a good place to put libraries would be J/administrator/components/com_whatever/library/ .  This is probably the classical way of sharing libs.

2) Create a system plugin that represents the libraries.  This would be a separate extension with it's own XML install file ( normal for plugins ).  The files would go in J/plugins/system/whatever/ .  I'm not sure how well this has been tested but seems like it would work.

Thought: This would be a system plugin, yeah?  It's horizontally extending the Framework Tier.

tcp

I was wondering about that as well, do plugins have to be of one of the predefined types, i.e. system, content blah blah etc etc

Or can we use a custom type such as library or component?

I prefer library, it's more semantically correct.

From my look at things, a plugin and a component are required. The plugin basically does the set-up for the component. I plan to put my plugin into /plugins/libraries/myplugin.php and the common code into /plugins/libraries/myplugin/*.php.

I think at some point in the future, a multi-step install is a good idea maybe we have something like



Or one could have the plugin install script invoke an installation for the component...

Maybe we should add an empty library folder to the plugins just for clarity and rename the system plugins to application plugins because that is technically what they are. Thoughts ?