debian-sf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Debian-sf-devel] Plugins thingy, draft #2


From: Francisco Gimeno
Subject: Re: [Debian-sf-devel] Plugins thingy, draft #2
Date: Mon, 18 Nov 2002 13:27:28 +0100
User-agent: KMail/1.4.3

Hi!

This is my first post in the mailing-list. I'm KikoV and I'm trying to 
integrate the phpicalendar plugin into sourceforge.

About phpicalendar:
phpicalendar web: http://phpicalendar.sourceforge.net
phpicalendar demo: http://phpicalendar.sourceforge.net/phpicalendar-0.8/

I have nothing to do with phpicalendar :P. I just found it and liked it :]

> Hi some comments/ideas take the good throw the bad :)
and more!
>
> Roland Mas wrote:
> >  Hi again,
> >
> >Here's the state of the README.Plugins I've written so far.  Places
> >marked [TODO] are, well, places where it is known that further
> >thinking is needed.  Places where implementation is needed are also
> >marked.  I'll try to implement at least some of the less controversial
> >stuff this weekend, and post it for review before committing anything
> >to CVS.
> >
> >  Comments and thoughts and ideas for how to implement missing stuff
> >are welcome and looked for :-)
I'll try.

> >WHAT PLUGINS ARE, AND WHY THEY ARE USEFUL
> >-----------------------------------------
> >
> >  Plugins are extensions to the "core" of Sourceforge, providing extra
> >functionality without being tightly integrated within Sourceforge
> >proper.  They are useful because they allow for independent
> >development of third-party functionality, and they add flexibility to
> >Sourceforge as to what features are available on a particular
> >installation.
> >
> >  As an example, it's been suggested to integrate a shared calendar
> >application in Sourceforge.  It's a good idea and an interesting
> >feature, but not one that everybody wants.  Thus, including it in the
> >Sourceforge code would piss off someone.  Additionnally, there might
> >be several competing implementations for such a calnedar application.

s/calnedar/calendar                                                             
               

> >Choosing one among them would also piss off people.  So it is made

piss off? do you mean anoy?

> >possible to have a system so that different implementations can exist
> >and be installed separately.

> >HOW PLUGINS WORK
> >----------------
> >
.
.
.

> >- A plugin may create its own tables in the same database.  These
> >tables must be named plugin_foo_* if the plugin's string identifier is
> >"foo".  One suggested table is plugin_foo_meta_data, which should be
> >used to store the plugin meta-data, such as the installed version.
> >The plugin can then use some code like db-upgrade.pl if its database
> >schema changes over time.
> I would prefer that  there is only one table containing versionning
> information.
> The actual debian_meta_data  table is enough to store informations you
> plan for
> plugins table if you add desc field. Nevertheless I would add a version
> field to plugins table
> I'm not sure that id and name are both necessary, except if you want to
> allow to change plugin name.
I think that both fields are Ok...
when referring use the id, when using files and external datas uses the name.

> >[TODO: Standardise the command/script/something below]
It would be OK to prepare a mini-plugin-SDK. With some model-scripts  like the 
/etc/init.d/skeleton.
Scripts to create the databases, to register plugins and so...

> There are some case where it can be interesting to use standart table
> like for this case:
> -If you want to add different documentation field to Project it's better
> to use the documentation
> table.
I don't understand this...
Anyway, I think that every core-module like documentation and so, should have 
a mini-API to the external plugin. For example, addDocument ( ... ) in the 
document module.
> -If you want to add extra info to the user table like phone number,
> adress, can be interesting to
> do this some kind of construction made in survey.
Extra info could be in different tables by using ref keys. It's the elegant 
way, and using SQL is very easy get data.

> >- Functions in Group.class and User.class: the Group and User classes
> >now have a usesPlugin() method.  It takes a single parameter, the
> >"acmetimetracker" identifier for the module, and returns a boolean if
> >the particular user/group has turned on the use of that module.
>
> Maybe we could also adopt the overload facility used in theme to be able
> to overload some already existing functions.
> just for  memory
> There is a Layout.class table  that contains standart function for sf
> layout There are many Theme.class that can decide to reimplement or not
> done for this Layout function
Do you mean making a Plugin.class ?

> >- A plugin should not change the existing files, except insofar as it
> >adds links to its own web pages.  Of course, these additions will have
> >to be merged into the pages of the main package, but it should be just
> >a matter of inserting lines like
> >| if $this_group->usesPlugin("foo") {
> >|    echo [Link to /plugins/foo/index.php?parameters]
> >| }
good way.
> >in the existing pages.  Most plugins will probably only add these
> >links on the project summary page and/or on the user personal pages.
>
> If you add some graphic elements this can have some influence on the
> page layout
> For this one easy to do thing is to split the page in graphical subpart
> and to allow to
> change the layer, for example www/include/project_home.php should be
> splited in
> www/include/project_home.php.desc
> www/include/project_home.php.contacts
> www/include/project_home.php.frs
> www/include/project_home.php.jobs
> www/include/project_home.php.news
> www/include/project_home.php.pubarea
> www/include/project_home.php.stats
>
> www/include/project_home.php would make simple includes
Then, you could modify the aspect of SF. It's really good this idea. A good 
way to include the mini-API into this modules.

> >[TODO: Think about that, design, implement]
> >  Speaking of languages...  There should be some way to have
> >plugin-specific language files, so that the plugins can use the
> >standard methods used elsewhere in Sourceforge.  I haven't thought
> >about that very deeply yet, but I think it will evolve into a
> >recommendation that the "handles" in the language files are
> >plugin_foo_page / item (as compared to the current page / item model
> >used for "core" Sourceforge i18n strings).
>
> Just use the mecanism you used for langage_local is enough
I have to see the code to talk about this.
> >[TODO: Implement those scripts]
> >- A plugin should register itself into the database using the provided
> >sf-register-plugin script on its installation, and deregister itself
> >using sf-deregister-plugin on removal.
> >
> >HOW DO I MAKE A PLUGIN?
> >-----------------------
> >
> >[TODO: Actually implement it...]
> >  Your best bet would be to start with the sample "helloworld" plugin
> >and change parts of it.  It shows an example of everything you should
> >need to make your plugin: PHP pages, Perl CGI pages, configuration
> >files, bits of Apache configuration, cron jobs, etc.  If you need
> >something else, please ask, we'll discuss it, (hopefully) reach an
> >agreement on how to Do It Right, and implement a sample in
> >helloworld.
Well... I have to do the phpicalendar integration... When developing I'll have 
doubts... We can fix the TODO lists then. I'll send my comments, doubts, and 
the way I would make it to the mailing list.

greetings.
-- 
Francisco Gimeno Domenech
Telvent-Interactiva





reply via email to

[Prev in Thread] Current Thread [Next in Thread]