I think the web2py component should have the concept of an Interface as in COM, Java and C#. So I propose that the component would have some classes whose names begin with interface_ (or whatever naming convention is web2py-acceptable) and these classes would represent the exposed interfaces. Unlike Java interfaces, these web2py interfaces would contain implementation code to avoid wasteful source file proliferation which true interface classes (signature only classes without implementation bodies) would cause. It is just the existence of classes whose names begin with interface_ which is important - there is no need to make them codeless. It would be an adopted web2py component convention that if a component class implements a method which is a member of an established web2py component interface, then it must implement ALL of the methods of that interface.
So a web2py component client can use whatever reflection technique python has to browse all the interfaces which a component exposes. Or we could enforce a rule that every web2py component must support a standard interface which enumerates all the interfaces. In a forms component for example, it is important for the form class to support an Enumerator Interface which allows walking the list of child controls within the form. I suspect right now some of the existing forms classes such as crud probably do not hold onto the collection of INPUT objects. It probably just does constructor calls without saving the child object refs on any kind of list. So I suggest the web2py components follow a guideline to maintain lists of their child objects and to provide Enumeration interfaces over them. --- End of web2py Component Interface Guidelines --- On May 4, 5:37 am, dlypka <dly...@gmail.com> wrote: > OK, to help kick off the metadata here are some definitions: > > A "Control" (aka Server-side Control) is a class whose constructor > emits markup. > > This behavior allows the control to be embedded within markup. > > A "Control" can be installed in a designer palette. > > Because it emits markup, it always renders a representation in design > mode. > > Controls do not have metadata. > > All controls should support events and Observer Pattern > > The classes in gluon/html.py are the base controls for web2py. > The classes in gluon/sqlhtml.py are example of "user controls" which > are preconfigured controls. > Another name for a user control is "widget". > > A "Component" is a class which has support to join a Component > Repository. > > The meta data for a component includes the following attributes: > A bitmap for representation in a designer palette > Version information > Desciption > Trust Metadata (such as a digital signature) > Path to the Code > Hints for representation in the designer > > I suppose a Component would support several design patterns: > Observer Pattern > Iterator Pattern > Decorator Pattern > Factory Pattern > Composite Pattern > Template Method Pattern > > A Component should support some standard states > such as active, inactive. > > -- End of Metadata Kick Off -- > > On May 3, 5:46 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > > The format is the last thing we should worry about it. The real issues > > are how to we categorize plugins? What should the metadata contain? > > what should be standard hooks? which contraints should be require for > > the plugin to be portable? > > > On May 3, 3:16 pm, dlypka <dly...@gmail.com> wrote: > > > > For the metadata, it sounds like a need for something similar to good > > > old 'typelibs' a la Microsoft COM. > > > I suppose it would be represented in XML rather than binary as > > > typelibs were binary. > > > Or maybe in some portable python byte code? > > > > On May 3, 10:55 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > > This is a recurrent theme on this list and one I care the most. It is > > > > also a complicated issue because different people define plugins in > > > > different ways and because it is a matter of writing specs more than a > > > > technical issues. Anyway... > > > > > In web2py we do not have the concept of projects. We have the site > > > > (one web2py folder) and multiple applications for a site. An > > > > application can be a plug-in in the sense described in > > > > > http://www.web2py.com/examples/static/plugin_t2.pdf > > > > > I think we should also plug-ins in the sense of "things" that plug > > > > into an application. While an application is a zipped file that unzips > > > > under a new application folder, a plugin would be a zipped file that > > > > unzips ONLY under an existing application folder IF it does not > > > > override any existing file UNLESS the existing files constitute a > > > > previous version of the same plug-in. A plug-in could contain > > > > > modules/plugin_xxx/* > > > > models/plugin_xxx.py > > > > controllers/plugin_xxx.py > > > > views/plugin_xxx/*.html > > > > static/plugin_xxx/* > > > > > and it would also contain a metadata file of some kind > > > > > plugins/plugin_xxx.meta? > > > > > We can imaging more sophisticated admin, layout.html, etc. that know > > > > how to interpret the metadata file. > > > > > We need to come out with specs for writing these metadata files. What > > > > should be in there? > > > > Once this is solved everything else can be coded in one day. > > > > > Massimo > > > > > On May 3, 6:47 am, Kless <jonas....@googlemail.com> wrote: > > > > > > Is there any plugin system for reuse/share applications in another > > > > > projects?- Hide quoted text - > > > > > - Show quoted text -- Hide quoted text - > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
