In looking at the plugins that have been released, or proposed, some sort of "developers guideline" on how to hook into the various tables, features and such seems in order.

Pretty much adding fields to the link record has become standard.

Adding information to the category and users tables is less standard, and more prone to problems. The users table especially, if more programs are going to access the data.

Gossamer Community may change the way this all happens, so maybe this should wait for Alex to comment on what information is going to be shared among the programs, and how, before going too deep into this.

What was occurring to me today, was adding fields to the user record is a problem. Using an intermediary table that was keyed to the Username, and linked to the custom table for the plug in started to make sense.

But, I guess the way Gossamer Community will handle user/logon data will influence this process.

Either way, some sort of developer guide needs to be developed, and now is as good a time as any :)

Part of the developer guide would be to develop standard interfaces for setting up plugins, calling features, and hooking into links. What was "accepted" behavior and what was unacceptable.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Is there a guide on how to make a plugin?

I have been searching the forum and I'm still searching curently.

If there is any ifo. out there please let me know.

Good idea.

Perhaps column naming standards etc. I use a prefix if I am adding columns to an existing links table like EM_User for example, so as not to clash with other plug-ins.

I think you are right, and we will have to wait to see what impact Community has on things also.



CODE07: I learnt how to write a plug-in just by reading the docs section on plug-ins, and even more so by getting pointers from the existing plug-in developers on this forum. Maybe pick something you want to do, and dive straight into it! I did this with directory depth (my first plug-in), and even though I would say most of it was written in parts by others, I put it together myself, and this taught me the basics of writting plugins.


http://www.iuni.com/...tware/web/index.html
Links Plugins

Also, template naming standards. This is important I beleive, so as not to accidently install and overwrite a users, or other plug-in writters templates.

I have started my own naming convention similar to that of the column naming above.

Remote Counter Prefix: RC
Editor Monitor Prefix : EM
Tool Box Prefix: TB
Directory Depth: DD

and so on.

So all templates are name with the prefix and undscore before the name, for example:

RC_About.html

is a template from the Remote Counter plugin.


http://www.iuni.com/...tware/web/index.html
Links Plugins

Hi Ian,

I had an idea as per keeping the plugin names different or the same (whichever is needed).

Why doesn't GT keep a database of them that is searchable? SO when you want to name a template pahe you would just look it up in the GT DB.

And as per common terms, these can also be set up within the GT DB. As a seperate section of the DB.

It seems that a searchable DB would be better than posting here or placing them in a single excel file, etc...

Just a thought!

Nice idea Brian!


http://www.iuni.com/...tware/web/index.html
Links Plugins