There's a naming conflict between <property> (i.e., a string/value pair that stores meta information) and JavaBeans properties (i.e., <set-property> and <configure>).
It would be kind of nice if an extension could know of its meta-properties (i.e., <property> tags). It will know its own internal configuration. All the <property> stuff is being (re-)targetted as for use by visual editors and RAD tools, to support round- trip engineering. For instance, a visual tool that is showing some kind of chart view of the specification may store location, size and color information as one or more properties. A RAD tool may use properties to identify why it created certain specification elements so that it can then update them when other parts of the overall model change. For instance, a RAD tool that generates a CRUD application may need to read and update a Tapestry application when a new column is added to some table. You are right, most of the elementsthat can contain <property> have access to their own specification, so that they can access the <property> tags. To do this for extensions, I would have to require that the extension implements an interface with a method setSpecification(ExtensionSpecification), or somesuch. -- [EMAIL PROTECTED] http://tapestry.sf.net > Working on support for extensions and I'm trying to understand how they are > handled. > > Extension specs have properties and configurations. But the extension object > is initialized with its configrations after its instantiated. They never see > the properties. > > Why have the properties? > > > Geoffrey Longman > Intelligent Works Inc. > > > ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
