I can see where you are coming from - in this case the "plugin" is one step removed from the python/db driver, e.g. pyodbc, level. I think of sql.py as providing a level of abstraction and the plugins implementing it appropriately. As an aside, the db plugin interface of the demo should ideally be able to integrate the gql.py and memdb.py or any storage engine as just another type of db.
I think a similar approach could be applied to other areas, for example, views/templates and authorisation. With this type of "plugin" the key aspect is that the web2py core defines a set of hooks (or points where it will call out - or API?) that a compliant plugin must satisfy. For the demo I have made, each plugin is a single file but there is no reason why the same approach couldn't be applied to more complex plugins that resemble the "plugin app" you have referred to elsewhere where the plugin comprises a model, controllers, etc. Obviously, to cater for this latter case a different method of organising resources is needed but I think it still prefereable to have the "plugins" separate from the applications folder. I envisage there could be a lot of debate on that issue. Anyway, I look forward to your comments. On Jan 26, 9:46 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > Thank you Bill. I will take a look. > This is very interesting and probably we should have something like > this but to clarify, you use the term plugin in a very different > context than I do. > I may be wrong but what you call a plugin is what I would call a > driver. This may be the cause of our apparent different opinion on > some issues. > > Massimo > > On Jan 26, 2:53 pm, billf <billferr...@blueyonder.co.uk> wrote: > > > I have created a new branch on launchpad under ~billferrett/web2py/ > > plugins. The purpose is to demo an approach to using plugins to > > provide functionality to the web2py core. > > > I needed an example area to apply the idea to so I have taken sql.py > > and moved all the db-engine specific code (and some general SQL code) > > replacing it with calls to the selected plugin class. > > > The plugins are found in plugins/db. There is one "abstract" class > > that acts as a template for "db" plugins and contains common > > functions. There is one plugin file/class for each db-engine. > > > On startup, sql.py looks for plugins in the plugins/db folder, > > ignoring any containing IS_ABSTRACT=True and asking each plugin to > > check that required drivers are present. This information is > > formatted so that widget.start() displays it in place of the normal > > "Database drivers found". > > > When a SQLDB is created, the appropriate plugin is selected depending > > on the uri. This can be overridden if required. The modified sql.py > > then calls to the plugin to perform the necessary functions (get > > dialect values, connect, create table, insert, update, delete, etc). > > > I have moved as much of the actual SQL to the plugins as was > > practicable for the demo. All the plugin code is complete but only > > the basic functionality for sqlite and mysql has been tested (create > > table, insert, update, delete). > > > As I say, this is intended as a demo of an approach that I think could > > be useful. I hope that some of you will have the time to look at it > > and I look forward to your comments. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" 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 -~----------~----~----~----~------~----~------~--~---
