|
List Info
Thread: Working on some ideas for plugin integration
|
|
| Working on some ideas for plugin
integration |

|
2006-08-28 22:14:56 |
I'm just working on some ideas I have knocking around at
the moment on
a local install of mephisto for managing plugins. Basically,
what I'm
trying to put together is a simple Plugins section which
lists the
installed mephisto plugins, a little bit of metadata
(author/description, if available) and if a plugin has any
settings, a
"Settings" link. In some ways its similar to the
Wordpress plugin
screen but simpler: there is no activation/deactivation of
plugins, and
plugin settings are nothing more than a simple series of
key/value
pairs (with an optional description).
The basic model is:
MephistoPlugin
has many Plugin Settings
So far I've got the basic domain model for the above
written, plus a
plugin scanner.
The way I've implemented it so far, the scanner checks for
the word
"mephisto" in a "tags" key inside
the about.yml file. However, if its
possible to get Rails to look for plugins elsewhere, it
might be
cleaner to have a dedicated mephisto plugins directory which
it reads.
This saves people from having to create an about.yml file
and adding
the mephisto tag.
As to how a plugin gets its settings, well it simply creates
them
somewhere, probably in init.rb, so it might look something
like this:
# init.rb
MephistoPlugin.find_by_name('mephisto_comment_notification
').settings.create(:key
=> 'foo', :value => 'bar', :description =>
'blah blah blah')
This feature should be enough for the majority of plugins,
which will
need nothing more than a few settings at most.
More complicated plugins who wish to have their own
controllers or
views etc. can do so, but its left up to them on how they
implement
this - my extensible menus patch will make it easy for them
to add
links to their own functionality though.
A few issues I have in my mind about my own implementation
are:
* Making sure the plugin scanner (which should only need to
run once in
environment.rb) runs before plugins are initialized as
plugins need to
have records in the mephisto_plugins table before they can
create
settings in the init.rb file. Perhaps we can make it simpler
by having
plugins register themselves? (MephistoPlugin.create in
init.rb etc.).
Or perhaps this is something you'd want the core app to
retain control
over.
* It would be really cool to be able to do one-click install
of plugins
through the admin interface -the main issues with this are:
deciding
how to do this from an interface point of view - the
installation of
the plugin might need to be deferred to a background process
(backgroundrb?), but then again it might not. There would
need to be
some way of initialising the newly installed plugin to avoid
a server
restart.
What do you think of the general idea? My implementation
isn't
neccesarily the best way of doing it but I'll wrap up what
I've got so
far in the next day or two and submit a patch so you can
have a look.
No doubt you'll want to tweak things but personally I think
the general
idea of a Plugins tab for viewing installed plugins, editing
settings
and (possibly) installing plugins would be very useful. The
easier it
is for people to extend mephisto, the easier it is to
encourage people
to add features as plugins rather than pester the core to
implement
feature x or y. From a personal perspective, I'm really
loving mephisto
and would like to start writing plenty of plugins in the
future which
is why I've been working on this.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Mephisto Blog" group.
To post to this group, send email to MephistoBlog googlegroups.com
To unsubscribe from this group, send email to
MephistoBlog-unsubscribe googlegroups.com
For more options, visit this group at http://gr
oups.google.com/group/MephistoBlog
-~----------~----~----~----~------~----~------~--~---
|
|
| Working on some ideas for plugin
integration |

|
2006-08-29 00:01:45 |
Great stuff Luke, glad to hear your poking around in this
area. When
we start working on 0.8, your efforts will definitely help
out.
In terms of the UI for plugins. I want to make plugins
installable and
configurable from the admin, but haven't put much thought
into how I'm
going to do it yet. At the moment we have different types
of plugins
'Filters/Macros', 'Liquid', and plugins like your admin
tab thing, not
to mention future plugins for assets.
So we're faced with the problem that we have many different
types of
plugins and we need the best way to manage them in an
organized way in
both the UI and the dir tree. I'm not sure what Rick has
up his sleeve
for this, but I'm thinking that different types of plugins
live under
their own namespace:
plugins/
filters/
liquid/
assets/
etc/
I would ultimately love the ability to be able to install
plugins
without having to go to ftp/etc to import them. Textpattern
does
something like this in the fact that they use base64
encoding to
represent a plugin, I don't think this is the way to do it,
but it's an
example of an easy way to install plugins. I don't have
much
experience with Wordpress, so it might do it a bit
differently.
We want to make headway in this area, but we really want to
get our
theme system up to par first. I'm personally wish we was
done with the
theme system already because I'm really looking forward to
working on a
real plugin system.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Mephisto Blog" group.
To post to this group, send email to MephistoBlog googlegroups.com
To unsubscribe from this group, send email to
MephistoBlog-unsubscribe googlegroups.com
For more options, visit this group at http://gr
oups.google.com/group/MephistoBlog
-~----------~----~----~----~------~----~------~--~---
|
|
| Working on some ideas for plugin
integration |

|
2006-08-29 00:44:53 |
I believe vendor/plugins has support for nested plugins. So,
why not
have a dir structure like this?
vendor/plugins/mephisto/liquid
vendor/plugins/mephisto/admin
...
Are there going to be clearly defined plugin types though?
Or, is it
enough to just install them in vendor/plugins/mephisto/*?
Admin installable plugins would be cool. How safe would
that be though?
How about this:
mephisto_plugin :comment_akismet do |plugin|
plugin.summary = "Akismet Comment Spam
Protection"
plugin.version = "0.1a"
plugin.default_settings = {:blog_url => '...',
:api_key => '...'}
plugin.on_init do |config|
require 'akismet'
config.active_record.observers <<
:comment_akismet_observer
end
end
During rails init, something like
Mephisto::Plugins[:comment_akismet].run is called if the
plugin is
activated. When installed from the web, the same method is
called to
require the necessary files, set up the default settings,
and activate
the plugin.
Also, I'd rather use a serialized option hash for settings
to minimize
possible settings migrations between versions. This could
be
interesting enough to explore further. I'm just afraid of
making this
too complex though. Perhaps we create a few for 0.7/0.8 and
see how
the system works?
--
Rick Olson
http://weblog.techno-
weenie.net
http://mephistoblog.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Mephisto Blog" group.
To post to this group, send email to MephistoBlog googlegroups.com
To unsubscribe from this group, send email to
MephistoBlog-unsubscribe googlegroups.com
For more options, visit this group at http://gr
oups.google.com/group/MephistoBlog
-~----------~----~----~----~------~----~------~--~---
|
|
| Working on some ideas for plugin
integration |

|
2006-08-29 08:58:19 |
I'm just afraid of making this
> too complex though. Perhaps we create a few for
0.7/0.8 and see how
> the system works?
I agree; you don't want this to get too complicated. By the
same token,
I don't think you want to make too many assumptions for
plugin
developers otherwise it might be too restrictive.
Of the ideas above, I favour a simple folder structure, with
/vendor/plugins/mephisto if Rails supports this ok. I don't
think there
is any benefit in distinguishing between general plugins,
liquid
plugins etc.
I think using the database to store plugins is easier
overall, as long
as you keep the schema simple.
As nice as it would be to have hooks into different parts of
the app, I
believe that going in this direction is starting down the
road to being
too complex. Adding your own tabs gives you the ability to
link to your
own controllers/views so developers can put whatever they
need in their
own controllers and views.
I'm gonna look at setting up a local svk repository later
so I can
manage the code I'm writing for this better, and I'll post
up some code
later.
With regards to how secure is it to install plugins through
the admin
interface, is it really any less secure than somebody
finding your SSH
login details and logging in via a shell and installing
something?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Mephisto Blog" group.
To post to this group, send email to MephistoBlog googlegroups.com
To unsubscribe from this group, send email to
MephistoBlog-unsubscribe googlegroups.com
For more options, visit this group at http://gr
oups.google.com/group/MephistoBlog
-~----------~----~----~----~------~----~------~--~---
|
|
[1-4]
|
|