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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" 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 -~----------~----~----~----~------~----~------~--~---
