Let's say we were to create a new folder called applications/*/
plugins, put stuff in there and modify web2py to handle the code in
there in some special way. That the current mechanism in admin for
packing, unpacking, deleting would still work. It is because plugins
in a subfolder are simply more specialized plugins than the ones I am
defining. Let me play with with words:
- What I call plugins should instead be called
random_applications_subsets
- What you call plugins are special types of
random_applications_subset that are somewhat isolated.
What you call plugins does not exist yet. It needs to be created. I am
taking a top-down approach instead of bottom-up approach because I am
afraid of building something that turn out to be too restrictive. When
we have in trunk is a convention. We can decide tomorrow not to follow
it any more and remove the page in admin and no application would
break. This is the beginning of a story that is yet to be written.
Before we write it we need to learn what others have done (Drupal for
example).
I do not want to create a single plugin system (I do not believe in a
one size fits all solution here) but I want to give people like you
the ability to create their own plugin system. Some plugins may be
specialized for a particular web2py CMS or other type of specialized
type of app.
Now I am going to redefine:
plugin_0 := random_application_subset
plugin_2 := what Mr Freeze calls a plugin
plugin_3 := what Alvaro calls a plugin
plugin_N := what Yarko calls a plugin
where _i indicates a higher level of abstraction/encapsulation of
functionality.
plugin_0 is simple. It is done. It is just a
random_application_subset. The thing being plugged (plug) is a bunch
of files. The thing it plugs into (socket) is an existing application,
and it may very well break if socket and plug are not compatible.
plugin_{i>0} are more complex because we need to define more clearly
types of plugs and sockets. I am thinking about functions that need to
dynamically create tables, insert records, change layout, add cron
jobs, add internationalization strings, generate js, pieces of the app
that need to communicate client-server, server-server, client-client
(same client or different client).
I think this is going to take time. Drupal provides a limited but
successful approach that can help kick off a more concrete discussion.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
