Plugin class names

[Elin Waring]

I was working on an application with a plugin with the new mvc and it made me wonder  if to be consistent with what we are doing elsewhere it makes sense to begin those class names with Plugin rather than Plg as we have been doing. 

Also, what's the intention with the authentication methods that are in JApplication? Is each application going to be responsible for those or will some version be eventually reincorporated in the application package? 

Elin

[Andrew Eddie]

It's an interesting question because the way the CMS acknowledges
plugins, and how a new application might handle could be worlds apart.
Whatever the case, the names can be anything but I'd advise they
follow the auto-loader.

For example, a web service app might do this:

/code
../plugin
…./authentication
….../google.php

The class name would be JPluginAuthenticationGoogle (extends ?
implements ?), or if you are using an application namespace maybe
MozartPluginAuthenticationGoogle.

There probably needs to be a new interface for these but I'm thinking
I'd go with something like interface JTrigger (and a "trigger"
package) rather than trying to mess with JPlugin (JPlugin could then
implement JTrigger).

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

[Elin Waring]

Oh that is a good point. I had been thinking just to have a Plugin namespace but you're right about them potentially being quite different from application to application.  I was thinking the plugin folder would be more likely in  a top level folder of an application rather  than inside the code folder,  but I definitely see where you are going and it makes sense to do that.  

Elin

[Rouven Weßling]

If we wanna use the autoloader for plug-ins - which is a nice idea - the plg prefix isn't the problem. We can just register that as a prefix for the correct folder with JLoader. The problem is that we have to repeat the last part, i.e. for plgSearchContacts contacts will have to be duplicated because the plugin is in plugins/search/contacts/contacts.php. I guess we'll end up rolling a custom autoloader for it unless we wanna go back to the folder layout of 1.5. (IMO not a good idea)

Rouven

[Elin Waring]

I think the current layout structure or something is quite useful and somewhat similar to the practices encouraged elsewhere, though looking at some files the last few days it seems like both the older and newer structures are supported in the platform. So I think it would be good to decide and maybe deprecate support for one or the other structure.

Elin

[Sam Moffatt]

Responses inline.

On Thu, May 3, 2012 at 10:46 AM, Elin Waring <elin....@gmail.com> wrote:
>
> I think the current layout structure or something is quite useful and
> somewhat similar to the practices encouraged elsewhere, though looking at
> some files the last few days it seems like both the older and newer
> structures are supported in the platform. So I think it would be good to
> decide and maybe deprecate support for one or the other structure.

This was intentional to aide in place migration for 1.6 when it was
introduced. As we didn't do in place migration it's kind of a moot
point now and could probably remove that backwards compatibility
functionality.

> On Thursday, May 3, 2012 12:56:35 PM UTC-4, Rouven Weßling wrote:
>>
>> If we wanna use the autoloader for plug-ins - which is a nice idea - the
>> plg prefix isn't the problem. We can just register that as a prefix for the
>> correct folder with JLoader. The problem is that we have to repeat the last
>> part, i.e. for plgSearchContacts contacts will have to be duplicated because
>> the plugin is in plugins/search/contacts/contacts.php. I guess we'll end up
>> rolling a custom autoloader for it unless we wanna go back to the folder
>> layout of 1.5. (IMO not a good idea)

One way would be to do it per plugin type and register a prefix like
'plgSystem' which should work without modification. Would require
iterating over the top level but would work properly. This could
probably be handled in the importPlugin utility function.
Fundamentally we really don't save all that much since we know what
files we want to load from the database and need to instantiate the
classes inside to work out what they offer to call. It's a lot of work
to avoid loading a file immediately anyway.

Cheers,

Sam Moffatt
http://pasamio.id.au

[Rouven Weßling]

On 08.05.2012, at 08:28, Sam Moffatt wrote:

> On Thu, May 3, 2012 at 10:46 AM, Elin Waring <elin....@gmail.com> wrote:
>>
>> I think the current layout structure or something is quite useful and
>> somewhat similar to the practices encouraged elsewhere, though looking at
>> some files the last few days it seems like both the older and newer
>> structures are supported in the platform. So I think it would be good to
>> decide and maybe deprecate support for one or the other structure.
>
> This was intentional to aide in place migration for 1.6 when it was
> introduced. As we didn't do in place migration it's kind of a moot
> point now and could probably remove that backwards compatibility
> functionality.

The pull request to pull out the legacy support was just accepted.

> One way would be to do it per plugin type and register a prefix like
> 'plgSystem' which should work without modification. Would require
> iterating over the top level but would work properly. This could
> probably be handled in the importPlugin utility function.
> Fundamentally we really don't save all that much since we know what
> files we want to load from the database and need to instantiate the
> classes inside to work out what they offer to call. It's a lot of work
> to avoid loading a file immediately anyway.

I've written a custom autoloader to do it a few days ago: https://github.com/realityking/joomla-cms/commit/aee883855211a0fdab2d3ef8a77688e36fb30fa1

However I have to agree with you - it's not that useful. There are certainly more interesting things to tackle for autoloading in the CMS.

Rouven