looking at html.py I see that the FORM class does keep a list of all its child instances in self.components. So that is not a concern.
On May 5, 3:18 am, dlypka <dly...@gmail.com> wrote: > 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 -- 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 -~----------~----~----~----~------~----~------~--~---
