Tips to write plugins - Revision history

E.jennings@bath.ac.uk at 12:35, 30 June 2017

2017-06-30T12:35:27Z

@@ Line 30: / Line 30: @@
   my $eprint = EPrint::DataObj::EPrint->new($session, 23); #get eprint 23
   print $eprint->mysubroutine(); #prints “foo”
 * Rule 7: learn about cfg/cfg.d/plugins.pl. This file lets you disable plugins you dont want to use or map you modified plugins over other plugins. For example use MyReview.pm everywhere you would usually use Review.pm – very powerful. It also lets you define where plugins apear around about the place.

Libjlrs@leeds.ac.uk: added link to new instructrions page

2010-10-18T10:49:25Z

added link to new instructrions page

← Older revision		Revision as of 10:49, 18 October 2010
Line 10:		Line 10:
	* Rule 3: Everything in the Plugin/ directory which you do should be kept in the appropiate place in archives/YOUR_REPOSITORY/cfg/plugins/EPrints/Plugin etc. This is a really good way to keep track of what you’ve actually done.		* Rule 3: Everything in the Plugin/ directory which you do should be kept in the appropiate place in archives/YOUR_REPOSITORY/cfg/plugins/EPrints/Plugin etc. This is a really good way to keep track of what you’ve actually done.

	* Rule 4: Everything you do should be a plugin. EPrints has plugins for almost everything which means you should be able to do almost all funtionality in plugins.		* Rule 4: Everything you do should be a plugin. EPrints has plugins for almost everything which means you should be able to do almost all funtionality in plugins. See [[Instructions for local plugins]]

	* Rule 5: For everything you want to do which ~~doesnt~~ seem to be a plugin think really hard. Are you SURE it’s not a plugin? Really SURE? Are you SURE you need this functionality? Really SURE?		* Rule 5: For everything you want to do which doesn't seem to be a plugin think really hard. Are you SURE it’s not a plugin? Really SURE? Are you SURE you need this functionality? Really SURE?

	* Rule 6: If you have followed rule 5 and you are still really sure then kludge a plugin, a kuldgin as I like to call them, using namespace over writing. This is feature/artifact of perl, from one package you can write in another package. Add methods to the DataObj::EPrint good example of where you might want to do this. To do it :		* Rule 6: If you have followed rule 5 and you are still really sure then kludge a plugin, a kuldgin as I like to call them, using namespace over writing. This is feature/artifact of perl, from one package you can write in another package. Add methods to the DataObj::EPrint good example of where you might want to do this. To do it :

Pm705 at 15:36, 10 February 2010

2010-02-10T15:36:25Z

← Older revision		Revision as of 15:36, 10 February 2010
Line 1:		Line 1:
			[[Category:Plugins]]
	I've written a lot of plugins for EPrints 3+ now and so i think its time to share the knowledge. If you care you can read about the mess I got into in the early days [http://blogs.ecs.soton.ac.uk/oneshare/2009/09/25/taking-stock-and-mopping-up-the-mess-i-made-of-eprints/ here].		I've written a lot of plugins for EPrints 3+ now and so i think its time to share the knowledge. If you care you can read about the mess I got into in the early days [http://blogs.ecs.soton.ac.uk/oneshare/2009/09/25/taking-stock-and-mopping-up-the-mess-i-made-of-eprints/ here].

Pm705: moved How to write plugins to Tips to write plugins

2010-02-10T15:29:20Z

moved How to write plugins to Tips to write plugins

← Older revision	Revision as of 15:29, 10 February 2010
(No difference)

Pm705 at 15:23, 10 February 2010

2010-02-10T15:23:23Z

Pm705 at 15:22, 10 February 2010

2010-02-10T15:22:01Z

← Older revision		Revision as of 15:22, 10 February 2010
Line 3:		Line 3:
	So without further ado let me give you the top 10 ways to avoid making a hash of your EPrints install when doing a large customization:		So without further ado let me give you the top 10 ways to avoid making a hash of your EPrints install when doing a large customization:

	# NEVER edit Session.pm if there is one file that you will absolutely not recover from it’s this. also there is an easy way to avoid editing it see rule 6.		* Rule 1: NEVER edit Session.pm if there is one file that you will absolutely not recover from it’s this. also there is an easy way to avoid editing it see rule 6.
	# Don’t edit anything in perl_lib/EPrints. Make copies with a new name and new package. That way these files wont be over written when you upgrade.		* Rule 2: Don’t edit anything in perl_lib/EPrints. Make copies with a new name and new package. That way these files wont be over written when you upgrade.
	# Everything in the Plugin/ directory which you do should be kept in the appropiate place in archives/YOUR_REPOSITORY/cfg/plugins/EPrints/Plugin etc. This is a really good way to keep track of what you’ve actually done.		* Rule 3: Everything in the Plugin/ directory which you do should be kept in the appropiate place in archives/YOUR_REPOSITORY/cfg/plugins/EPrints/Plugin etc. This is a really good way to keep track of what you’ve actually done.
	# Everything you do should be a plugin. EPrints has plugins for almost everything which means you should be able to do almost all funtionality in plugins.		* Rule 4: Everything you do should be a plugin. EPrints has plugins for almost everything which means you should be able to do almost all funtionality in plugins.
	# For everything you want to do which doesnt seem to be a plugin think really hard. Are you SURE it’s not a plugin? Really SURE? Are you SURE you need this functionality? Really SURE?		* Rule 4: For everything you want to do which doesnt seem to be a plugin think really hard. Are you SURE it’s not a plugin? Really SURE? Are you SURE you need this functionality? Really SURE?
	# If you have followed rule 5 and you are still really sure then kludge a plugin, a kuldgin as I like to call them, using namespace over writing. This is feature/artifact of perl, from one package you can write in another package. Add methods to the DataObj::EPrint good example of where you might want to do this. To do it :		* Rule 5: If you have followed rule 5 and you are still really sure then kludge a plugin, a kuldgin as I like to call them, using namespace over writing. This is feature/artifact of perl, from one package you can write in another package. Add methods to the DataObj::EPrint good example of where you might want to do this. To do it :

	make a Plugin (yes a plugin) in your local cfg (see rule 3). start the plugin file in the normal way:		make a Plugin (yes a plugin) in your local cfg (see rule 3). start the plugin file in the normal way:

Pm705 at 15:20, 10 February 2010

2010-02-10T15:20:45Z

← Older revision		Revision as of 15:20, 10 February 2010
Line 16:		Line 16:
	#now for the clever bit		#now for the clever bit
	package EPrints::DataObj::EPrint;		package EPrints::DataObj::EPrint;
	sub mysubroutine{		sub mysubroutine{
	return(”foo”);		return(”foo”);
	}		}

Pm705 at 15:20, 10 February 2010

2010-02-10T15:20:20Z

← Older revision		Revision as of 15:20, 10 February 2010
Line 16:		Line 16:
	#now for the clever bit		#now for the clever bit
	package EPrints::DataObj::EPrint;		package EPrints::DataObj::EPrint;
	sub mysubroutine{		sub mysubroutine{
	return(”foo”);		return(”foo”);
	}		}

Pm705 at 15:19, 10 February 2010

2010-02-10T15:19:31Z

Pm705 at 15:18, 10 February 2010

2010-02-10T15:18:47Z

← Older revision		Revision as of 15:23, 10 February 2010
Line 4:		Line 4:

	* Rule 1: NEVER edit Session.pm if there is one file that you will absolutely not recover from it’s this. also there is an easy way to avoid editing it see rule 6.		* Rule 1: NEVER edit Session.pm if there is one file that you will absolutely not recover from it’s this. also there is an easy way to avoid editing it see rule 6.

	* Rule 2: Don’t edit anything in perl_lib/EPrints. Make copies with a new name and new package. That way these files wont be over written when you upgrade.		* Rule 2: Don’t edit anything in perl_lib/EPrints. Make copies with a new name and new package. That way these files wont be over written when you upgrade.

	* Rule 3: Everything in the Plugin/ directory which you do should be kept in the appropiate place in archives/YOUR_REPOSITORY/cfg/plugins/EPrints/Plugin etc. This is a really good way to keep track of what you’ve actually done.		* Rule 3: Everything in the Plugin/ directory which you do should be kept in the appropiate place in archives/YOUR_REPOSITORY/cfg/plugins/EPrints/Plugin etc. This is a really good way to keep track of what you’ve actually done.

	* Rule 4: Everything you do should be a plugin. EPrints has plugins for almost everything which means you should be able to do almost all funtionality in plugins.		* Rule 4: Everything you do should be a plugin. EPrints has plugins for almost everything which means you should be able to do almost all funtionality in plugins.
	* Rule 4: For everything you want to do which doesnt seem to be a plugin think really hard. Are you SURE it’s not a plugin? Really SURE? Are you SURE you need this functionality? Really SURE?
	* Rule 5: If you have followed rule 5 and you are still really sure then kludge a plugin, a kuldgin as I like to call them, using namespace over writing. This is feature/artifact of perl, from one package you can write in another package. Add methods to the DataObj::EPrint good example of where you might want to do this. To do it :		* Rule 5: For everything you want to do which doesnt seem to be a plugin think really hard. Are you SURE it’s not a plugin? Really SURE? Are you SURE you need this functionality? Really SURE?

			* Rule 6: If you have followed rule 5 and you are still really sure then kludge a plugin, a kuldgin as I like to call them, using namespace over writing. This is feature/artifact of perl, from one package you can write in another package. Add methods to the DataObj::EPrint good example of where you might want to do this. To do it :

	make a Plugin (yes a plugin) in your local cfg (see rule 3). start the plugin file in the normal way:		make a Plugin (yes a plugin) in your local cfg (see rule 3). start the plugin file in the normal way:
Line 25:		Line 30:
	print $eprint->mysubroutine(); #prints “foo”		print $eprint->mysubroutine(); #prints “foo”

	Rule 7: learn about cfg/cfg.d/plugins.pl. This file lets you disable plugins you dont want to use or map you modified plugins over other plugins. For example use MyReview.pm everywhere you would usually use Review.pm – very powerful. It also lets you define where plugins apear around about the place.		* Rule 7: learn about cfg/cfg.d/plugins.pl. This file lets you disable plugins you dont want to use or map you modified plugins over other plugins. For example use MyReview.pm everywhere you would usually use Review.pm – very powerful. It also lets you define where plugins apear around about the place.

	Rule 8: for plugins which use a cgi script for whatever reason (usually ajax) make a directory in cgi which has the same name as the plugin for example cgi/myfirstplugin where all the cgi used by MyFirstPlugin.pm can be found. It makes it much easier to see what youve done and if you want to deploy the plugin somewhere else you grab the plugin file and the directory and you well on the way.		* Rule 8: for plugins which use a cgi script for whatever reason (usually ajax) make a directory in cgi which has the same name as the plugin for example cgi/myfirstplugin where all the cgi used by MyFirstPlugin.pm can be found. It makes it much easier to see what youve done and if you want to deploy the plugin somewhere else you grab the plugin file and the directory and you well on the way.

	Rule 9: Give each plugin its own phrase file. I got into a hidious mess where my zz_local.xml phrase file was about a 4000 lines long and it wasnt clear what phrases belonged to what plugin.		* Rule 9: Give each plugin its own phrase file. I got into a hidious mess where my zz_local.xml phrase file was about a 4000 lines long and it wasnt clear what phrases belonged to what plugin.

	Rule 10: If your plugin needs configuring put all the config options in a cfg/cfg.d/my_plugins_config_options.pl that way the user only has to go to one place edit the options and different repositories using the same plugin can have different options.		* Rule 10: If your plugin needs configuring put all the config options in a cfg/cfg.d/my_plugins_config_options.pl that way the user only has to go to one place edit the options and different repositories using the same plugin can have different options.

	In conclusion obey rules 1-10. If I’d known this stuff when I’d started we probably wouldnt have needed the first 6 months of the OneShare project.		In conclusion obey rules 1-10. If I’d known this stuff when I’d started we probably wouldnt have needed the first 6 months of the OneShare project.

← Older revision		Revision as of 15:19, 10 February 2010
Line 4:		Line 4:

	# NEVER edit Session.pm if there is one file that you will absolutely not recover from it’s this. also there is an easy way to avoid editing it see rule 6.		# NEVER edit Session.pm if there is one file that you will absolutely not recover from it’s this. also there is an easy way to avoid editing it see rule 6.

	# Don’t edit anything in perl_lib/EPrints. Make copies with a new name and new package. That way these files wont be over written when you upgrade.		# Don’t edit anything in perl_lib/EPrints. Make copies with a new name and new package. That way these files wont be over written when you upgrade.

	# Everything in the Plugin/ directory which you do should be kept in the appropiate place in archives/YOUR_REPOSITORY/cfg/plugins/EPrints/Plugin etc. This is a really good way to keep track of what you’ve actually done.		# Everything in the Plugin/ directory which you do should be kept in the appropiate place in archives/YOUR_REPOSITORY/cfg/plugins/EPrints/Plugin etc. This is a really good way to keep track of what you’ve actually done.

	# Everything you do should be a plugin. EPrints has plugins for almost everything which means you should be able to do almost all funtionality in plugins.		# Everything you do should be a plugin. EPrints has plugins for almost everything which means you should be able to do almost all funtionality in plugins.

	# For everything you want to do which doesnt seem to be a plugin think really hard. Are you SURE it’s not a plugin? Really SURE? Are you SURE you need this functionality? Really SURE?		# For everything you want to do which doesnt seem to be a plugin think really hard. Are you SURE it’s not a plugin? Really SURE? Are you SURE you need this functionality? Really SURE?

	# If you have followed rule 5 and you are still really sure then kludge a plugin, a kuldgin as I like to call them, using namespace over writing. This is feature/artifact of perl, from one package you can write in another package. Add methods to the DataObj::EPrint good example of where you might want to do this. To do it :		# If you have followed rule 5 and you are still really sure then kludge a plugin, a kuldgin as I like to call them, using namespace over writing. This is feature/artifact of perl, from one package you can write in another package. Add methods to the DataObj::EPrint good example of where you might want to do this. To do it :

	make a Plugin (yes a plugin) in your local cfg (see rule 3). start the plugin file in the normal way:		make a Plugin (yes a plugin) in your local cfg (see rule 3). start the plugin file in the normal way:

	package EPrints::Plugin::MyPlugin;		package EPrints::Plugin::MyPlugin;

	use strict;		use strict;

	our @ISA = qw/ EPrints::Plugin /;		our @ISA = qw/ EPrints::Plugin /;

	#now for the clever bit		#now for the clever bit

	package EPrints::DataObj::EPrint;		package EPrints::DataObj::EPrint;

	sub mysubroutine{		sub mysubroutine{

	return(”foo”);		return(”foo”);

	}		}

Line 36:		Line 23:

	my $eprint = EPrint::DataObj::EPrint->new($session, 23); #get eprint 23		my $eprint = EPrint::DataObj::EPrint->new($session, 23); #get eprint 23

	print $eprint->mysubroutine(); #prints “foo”		print $eprint->mysubroutine(); #prints “foo”

← Older revision		Revision as of 15:18, 10 February 2010
Line 3:		Line 3:
	So without further ado let me give you the top 10 ways to avoid making a hash of your EPrints install when doing a large customization:		So without further ado let me give you the top 10 ways to avoid making a hash of your EPrints install when doing a large customization:

	~~Rule 1:~~ NEVER edit Session.pm if there is one file that you will absolutely not recover from it’s this. also there is an easy way to avoid editing it see rule 6.		# NEVER edit Session.pm if there is one file that you will absolutely not recover from it’s this. also there is an easy way to avoid editing it see rule 6.

	~~Rule 2:~~ Don’t edit anything in perl_lib/EPrints. Make copies with a new name and new package. That way these files wont be over written when you upgrade.		# Don’t edit anything in perl_lib/EPrints. Make copies with a new name and new package. That way these files wont be over written when you upgrade.

	~~Rule 3:~~ Everything in the Plugin/ directory which you do should be kept in the appropiate place in archives/YOUR_REPOSITORY/cfg/plugins/EPrints/Plugin etc. This is a really good way to keep track of what you’ve actually done.		# Everything in the Plugin/ directory which you do should be kept in the appropiate place in archives/YOUR_REPOSITORY/cfg/plugins/EPrints/Plugin etc. This is a really good way to keep track of what you’ve actually done.

	~~Rule 4:~~ Everything you do should be a plugin. EPrints has plugins for almost everything which means you should be able to do almost all funtionality in plugins.		# Everything you do should be a plugin. EPrints has plugins for almost everything which means you should be able to do almost all funtionality in plugins.

	~~Rule 5:~~ For everything you want to do which doesnt seem to be a plugin think really hard. Are you SURE it’s not a plugin? Really SURE? Are you SURE you need this functionality? Really SURE?		# For everything you want to do which doesnt seem to be a plugin think really hard. Are you SURE it’s not a plugin? Really SURE? Are you SURE you need this functionality? Really SURE?

	~~Rule 6:~~ If you have followed rule 5 and you are still really sure then kludge a plugin, a kuldgin as I like to call them, using namespace over writing. This is feature/artifact of perl, from one package you can write in another package. Add methods to the DataObj::EPrint good example of where you might want to do this. To do it :		# If you have followed rule 5 and you are still really sure then kludge a plugin, a kuldgin as I like to call them, using namespace over writing. This is feature/artifact of perl, from one package you can write in another package. Add methods to the DataObj::EPrint good example of where you might want to do this. To do it :

	make a Plugin (yes a plugin) in your local cfg (see rule 3). start the plugin file in the normal way:		make a Plugin (yes a plugin) in your local cfg (see rule 3). start the plugin file in the normal way:

	package EPrints::Plugin::MyPlugin;		package EPrints::Plugin::MyPlugin;

	use strict;		use strict;

	our @ISA = qw/ EPrints::Plugin /;		our @ISA = qw/ EPrints::Plugin /;

	#now for the clever bit		#now for the clever bit

	package EPrints::DataObj::EPrint;		package EPrints::DataObj::EPrint;

	sub mysubroutine{		sub mysubroutine{

	return(”foo”);		return(”foo”);

	}		}

	That has added mysubroutine to DataObj::EPrint so you can now		That has added mysubroutine to DataObj::EPrint so you can now

	my $eprint = EPrint::DataObj::EPrint->new($session, 23); #get eprint 23		my $eprint = EPrint::DataObj::EPrint->new($session, 23); #get eprint 23

	print $eprint->mysubroutine(); #prints “foo”		print $eprint->mysubroutine(); #prints “foo”

	Rule 7: learn about cfg/cfg.d/plugins.pl. This file lets you disable plugins you dont want to use or map you modified plugins over other plugins. For example use MyReview.pm everywhere you would usually use Review.pm – very powerful. It also lets you define where plugins apear around about the place.		Rule 7: learn about cfg/cfg.d/plugins.pl. This file lets you disable plugins you dont want to use or map you modified plugins over other plugins. For example use MyReview.pm everywhere you would usually use Review.pm – very powerful. It also lets you define where plugins apear around about the place.