summaryrefslogtreecommitdiff
path: root/doc/Howto_Write_Plugins
blob: 6f58de5a573ee751bf4c8ed080a6b19b989c20cd (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
HowTo Write A Plugin For Portato
=================================

(NOTE: The XML schema is likely to change in the future.)

Writing a plugin is (quite) simple. You have to provide a XML file which tells portato how to communicate with the plugin and in most cases a Python module doing the actual work. This howto is not going to cover the writing of the plugin, but only the XML.

General
-------

So - how is a plugin is working in general? Portato defines a set of hooks (see the Hooks file for a complete list) to which your plugin can connect. For each hook you have three choices: To connect before, after or instead of the function being hooked. (Of course you can connect several times to one hook ...) The latter one should be used only if you really know what you are doing as it is likely that Portato won't work any longer after this. Also have in mind, that only one plugin can override. Thus: if several plugins want to override one hook, a randomly chosen one will get the allowance.

For each of the "before" and "after" mode a queue exists, holding the plugins to execute. A plugin is allowed to state another plugin which should be executed after (in "before" mode) or before (in "after" mode) your plugin. The star * exists to note that this should be applied to ALL other plugins. (And "-*" does exactly the opposite.) Portato TRIES to satisfy your request...

When you now have chosen the connect(s) to chose you write an appropriate function (or better: a Python callable) which will be given in the XML-definition to be called by Portato with the hook's arguments. (Hint: All arguments will be passed as keyword parameters. So you can easily pick the ones you need and add a "**kwargs" argument, which will take the rest. As a nice side effect you do not have to reflect any API changes which will come with additional parameters :)).

Finally: Add an import tag stating the module to import to execute the function(s) given - and you are done. 

If you are finished with your plugin, you can check if it complies with the XML Schema by doing: "portato -x $PLUGIN_FILE".

Sample XML
----------

<?xml version="1.0" encoding="UTF-8" ?>
<plugin xmlns="http://portato.sourceforge.net/plugin" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://portato.sourceforge.net/plugin http://portato.sourceforge.net/plugin.xsd">
    <author>Joe Smith</author>
    <name>Some small sample plugin</name>

    <import>plugins.sample.small</import>

    <hooks>
		<hook type = "a_hook" call = "the_calling_function">
        	<connect type="after" />
		</hook
    </hooks>

	<options>
		<option>disabled</option>
	</options
</plugin>

Notes:

- If you want to specify a dependency plugin the connect tag has to be like: <connect type = "after"> The other plugin we depend on </connect>.
- The "connect"-tag can be omitted. It then defaults to "<connect type='before' />".
- It is possible of course to have more than one "hook" tag.
- The options tag is optional. For a complete list of options, see below.

Additional Tags
---------------

Menu: 
		It is possible, that your plugin gets an entry in the "Plugin"-menu. Therefore you have to provide a "menu" tag and one or more "item" tags:
		
		<menu>
			<item call = "the_calling_menu_function">
				A small _Plugin
			</item>
		</menu>

		Note, that the underscore in front of a character will make it be underlined in the menu and thus accessible by a shortcut.

Options
--------

disabled:
		Disable the plugin by default, i.e. the user has to enable it, if he wants to use it.
='/others/cgit.git/commit/cgit.h?h=v0.4&id=fbaf1171b4e343929dd43ecac7cd9d1c692b84ec&follow=1'>Don't truncate valid cachefilesLars Hjemli3-4/+16 An embarrassing thinko in cgit_check_cache() would truncate valid cachefiles in the following situation: 1) process A notices a missing/expired cachefile 2) process B gets scheduled, locks, fills and unlocks the cachefile 3) process A gets scheduled, locks the cachefile, notices that the cachefile now exist/is not expired anymore, and continues to overwrite it with an empty lockfile. Thanks to Linus for noticing (again). Signed-off-by: Lars Hjemli <hjemli@gmail.com> 2006-12-11Move global variables + callback functions into shared.cLars Hjemli4-82/+86 Signed-off-by: Lars Hjemli <hjemli@gmail.com> 2006-12-11Move functions for generic object output into ui-view.cLars Hjemli4-34/+43 Signed-off-by: Lars Hjemli <hjemli@gmail.com> 2006-12-11Move log-functions into ui-log.cLars Hjemli5-111/+121 Signed-off-by: Lars Hjemli <hjemli@gmail.com> 2006-12-11Move repo summary functions into ui-summary.cLars Hjemli4-47/+59 Signed-off-by: Lars Hjemli <hjemli@gmail.com> 2006-12-11Move functions for repolist output into ui-repolist.cLars Hjemli5-70/+90 Signed-off-by: Lars Hjemli <hjemli@gmail.com> 2006-12-11Move common output-functions into ui-shared.cLars Hjemli4-82/+99 While at it, replace the cgit_[lib_]error constants with a proper function Signed-off-by: Lars Hjemli <hjemli@gmail.com> 2006-12-11Rename config.c to parsing.c + move cgit_parse_query from cgit.c to parsing.cLars Hjemli4-28/+29 Signed-off-by: Lars Hjemli <hjemli@gmail.com> 2006-12-11Avoid infinite loops in caching layerLars Hjemli3-14/+31 Add a global variable, cgit_max_lock_attemps, to avoid the possibility of infinite loops when failing to acquire a lockfile. This could happen on broken setups or under crazy server load. Incidentally, this also fixes a lurking bug in cache_lock() where an uninitialized returnvalue was used. Signed-off-by: Lars Hjemli <hjemli@gmail.com> 2006-12-11Let 'make install' clear all cachefilesLars Hjemli1-0/+2 Signed-off-by: Lars Hjemli <hjemli@gmail.com> 2006-12-11Fix cache algorithm loopholeLars Hjemli3-11/+16 This closes the door for unneccessary calls to cgit_fill_cache(). Noticed by Linus. Signed-off-by: Lars Hjemli <hjemli@gmail.com> 2006-12-10Add version identifier in generated filesLars Hjemli2-9/+14 Signed-off-by: Lars Hjemli <hjemli@gmail.com> 2006-12-10Add license file and copyright noticesLars Hjemli5-0/+372 Signed-off-by: Lars Hjemli <hjemli@gmail.com> 2006-12-10Add caching infrastructureLars Hjemli9-28/+353 This enables internal caching of page output. Page requests are split into four groups: 1) repo listing (front page) 2) repo summary 3) repo pages w/symbolic references in query string 4) repo pages w/constant sha1's in query string Each group has a TTL specified in minutes. When a page is requested, a cached filename is stat(2)'ed and st_mtime is compared to time(2). If TTL has expired (or the file didn't exist), the cached file is regenerated. When generating a cached file, locking is used to avoid parallell processing of the request. If multiple processes tries to aquire the same lock, the ones who fail to get the lock serves the (expired) cached file. If the cached file don't exist, the process instead calls sched_yield(2) before restarting the request processing. Signed-off-by: Lars Hjemli <hjemli@gmail.com>