On Oct 21, 4:41 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com>
wrote:
> On Wed, Oct 21, 2009 at 4:32 PM, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > I want to add something to this. I envision many different types of
> > plugins and combinations thereof:
>
> > 1) some plugin may expose a controller action
>
> Do you mean a plugin may contain a controller?
yes
> > 2) some may expose more than one controller action
>
> A controller's interface may include controllers - what are the rules? Can
> it redirect to use an app view? Must it contain it's own matching views?
> How will this happen?
a plugin should use it's own views but can use the app layout
> > 3) some will act on axisting db
>
> How will a plugin that is used by more than one app know the db? How will
> it prevent its own tables from accidentally conflicting with an apps? What
> are the needed rules / constraints for this?
It would need to be configured or passed the address of the db by the
LOAD function (not recommended)
> > 4) some will have their own db
>
> How will a plugin's db be created? IN the case where manual creation is
> needed, how will plugin installation handle this? What is needed here?
plugin_[whatever].db=DAL('sqlite://myowndb') # configurable
> > 5) some will act on existing tables
>
> How will data integrity be assured for such plugins? (I can think of a
> malicious plugin doing nasty things, or a sloppy one doing even worse)?
It cannot be guaranteed. When you use a plugin (or any web2py app, or
any app for what matters) you run other people code. As far you know
they can do os.system('rm -r *'). No way of knowing. Python does not
provide a sandbox.
> > 6) some will define their own tables
>
> In what db? What are the rules? How does the app now? How will the app
> know wich tables belong to the plugin?
plugin tables must have names that start with plugin_[name]_ so that
app can get a list:
tables=[table for table in db.tables if re.compile
('plugin_whetever_').match(table)]
> > 7) some will keep those tables private
>
> Private from users? Private from app (how)?
from the app or use auth to regulate data access.
> > 8) some will expose those tables to the rest of the app
>
> > 9) some may just define a new helper or widget for forms
> > 10) some may just define a new layout
> > 11) some may just contain static files
> > 12) some my just contain python modules
> > 13) some may expose internal variables, for example to a CMS app
>
> > So for me a plugin is not always an isolated entity.
>
> I will not go on - this is an example, and I invite everyone from the
> community to consider the same sorts of questions, but "is not isolated"
> begs "is it modular?" and introduces all sorts of nasty potential problems
> due to coupling.
>
>
> This then begs the question - should it be a plugin? or a component (e.g.
> part of the app, and not pluggable, due to application coupling).
ok but please let's not argue about definitions about about features
and behavior.
- For me a "plugin" is a piece of an app that can be copied in another
app and will work.
- A "component" is a controller+view that can be embedded using
something like the {{+LOAD()}} helper.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
