Every time we discuss this we spend time on semantic issues and I
would rather not enter into this discussion.
What I want:
1) ability to built applications in a more modular fashion ({{=LOAD
()}} provides that)
2) ability to take a piece of an app out and reuse in another app (the
"plugin_" prefix and some conventions could allow this)
3) the ability for some special types of app (CMS) to auto-discover
certain special types of plugins (like in Drupal) and change
accordingly (we do not have this yet because I am not sure what the
requirements are).
The purpose of a plugin, as I intend it, is not to replace the concept
of python modules (i.e. pieces of codes that you import once and are
available everywhere), it is not to create a new new complex system of
dependencies between web2py objects (which would be nightmare), and it
is not to create a new mechanism for installing/uninstalling
applications (or pieces of an application). This means an app can
depend on a plugin but plugins should not depend on each other, a
plugin can be designed for a specific class of apps.
My goal is always to simplify the "web2py experience" not make it more
complex.
Massimo
On Oct 21, 1:18 pm, Yarko Tymciurak <[email protected]>
wrote:
> On Wed, Oct 21, 2009 at 1:14 PM, Alex Fanjul <[email protected]> wrote:
> > I think that the best cms "framework" for take a sight in it is Drupal
> > and his great plugin system...
> > It has core plugins and optional (downloadable plugins). Firefox is not
> > comparable because all of them are "optional" type,
>
> I respectfully state that this is the difference between a component (not
> optional, part of a build) and a "plugin" (plug in ==> insert or remove).
>
> > you can not choose if you want to use gecko engine (for example)
> > It would be great to have a "web2py-centraplugin.com" to download or find
> > all of them...
>
> > alex f
>
> > El 21/10/2009 20:03, Yarko Tymciurak escribió:
>
> > On Wed, Oct 21, 2009 at 11:41 AM, mdipierro <[email protected]>wrote:
>
> >> This is up to the developer. You can choose to store all plugins in
> >> one app and have other apps call them
>
> > *sigh*
>
> >> {{=LOAD(...,application='otherapp')}}
>
> >> The fact is that if you distribute or compile an app, all plugins
> >> should stay with it.
>
> > "should"? Several cases in point:
>
> > - shared libraries are not distributed (and consider the reasons that
> > exists over static linking)
> > - Firefox is NOT distributed with all plugins - the end user adds those he
> > wants to use (think of the reasons);
> > - a "survey" plugin.... how will it be added by the person who downloads a
> > (for example) wiki app?
>
> > The entire concept of "plugin" and it's purposes, and motivation needs to
> > be explicit.
>
> > I am concerned we do not be holding a mouse and calling it a tiger...
>
> >> Moreover it should be possible for two apps to
> >> use two different version of the same plugins since we cannot
> >> guanartee creators of plugins will not break backward compatibility
> >> and we cannot guarantee the non-existance of plugins with the same
> >> name. They belong to the app but you can share them.
>
> >> Massimo
>
> >> On Oct 21, 11:25 am, Yarko Tymciurak <[email protected]>
> >> wrote:
> >> > On Wed, Oct 21, 2009 at 11:16 AM, mr.freeze <[email protected]>
> >> wrote:
>
> >> > > I like how the plugin system is shaping up but have one question about
> >> > > the folder structure. It seems more manageable to structure it like
> >> > > this:
>
> >> > > applications
> >> > > -- my app
> >> > > ---- models
> >> > > ---- views
> >> > > ---- controllers
> >> > > ---- plugins
> >> > > ------ myplugin
> >> > > -------- models
> >> > > -------- views
> >> > > -------- controllers
>
> >> > > This way a plugin would basically be a sub-app, making it easier to
> >> > > install/uninstall/upgrade and could also have multiple models/views/
> >> > > controllers. I remember some discussion about it but can't remember
> >> > > what the reasons against it were.
>
> >> > <sarcasm flag UP>
> >> > ...yes, with the added benefit that you get to make copies and copies of
> >> > plugins into every applications that needs it, woohooo!...
> >> > </sarcasm>
>
> >> > Seriously, folks - think about plugins in other systems.
> >> > Plugins need to be that - logically, I expect them to be per web2py
> >> > installation (not as a component within an application);
> >> > Logically, I also _might_ like to see them versionsed, so that pluginA
> >> has a
> >> > DEFAULT version which links to a specific version (without talking about
> >> the
> >> > mechanism for that "linking").
>
> >> > > On Oct 21, 10:18 am, mdipierro <[email protected]> wrote:
> >> > > > The new web2py in trunk (1.68.2) also contains an improved
> >> > > > experimental solution for plugins.
> >> > > > Here is a new video about it
>
> >> > > >http://www.vimeo.com/7182692
>
> >> > > > It includes suggestions from various people but I am sure it still
> >> > > > needs a lot of work. Anyway, give it a try and let us know what else
> >> > > > would you expect from a plugin system.
>
> >> > > > The interface for uploading/downloading plugins is missing, among
> >> > > > other things.
>
> >> > > > Massimo
>
> > --
> > Alejandro Fanjul Fdez.
> > [email protected]
> >www.mhproject.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
