cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Add form widgets
Date Wed, 21 Dec 2005 09:12:43 GMT
Ralph Goers wrote:
> Sylvain Wallez wrote:
>
>> Ralph Goers wrote:
>>
>>> I have been asked to look into how custom form widgets can be 
>>> added.  With the block structure in 2.2 this would imply that the 
>>> widgets would need to be added to our own block.  How can we 
>>> "append" to the widget definitions in cocoon-forms.xconf without 
>>> touching that file since it will be internal to the forms block?
>>
>> The structure of component management currently doesn't allow this, 
>> as the FormManager creates its own ServiceSelector, and therefore 
>> can't use the xconf includes. This is something that must be changed 
>> though.
>>
> Any ideas as to how?  This doesn't seem like it would apply to only 
> forms and that includes would really solve the problem.   Rather, it 
> would seem that a block should be able to "tell" the container to add 
> configuration data to some other block's configuration.

While adding the xconf include feature, I also heavily changed the way 
component selectors are managed (although this is totally transparent). 
The DefaultServiceSelector actually registers the component it manages 
in the CoreServiceManager, and does a lookup in that service manager 
when its select() method is called.

Simply put:
  selector.addComponent(hint, config)
      --> manager.addComponent(selectorRole + "/" + hint, config)

  selector.select(hint)
      --> return manager.lookup(selectorRole + "/" + hint)

The benefit of this approach is that a selector for a given role (e.g. 
datasources, source-factories) can be declared several times, as the 
selector basically delegates everything to the surrounding service 
manager, which manages all included files. The component space is 
effectively flattened.

As a side note, this also makes selector useseless, as you can directly 
call "manager.lookup(role + "/" + hint)".

This approach requires selectors to be direct children of the service 
manager in the container hierarchy. CForms currently defines additional 
levels: the DefaultFormManager creates a SimpleServiceSelector that 
holds all widget builders. This approach prevents flattening the 
component space in CForms, and therefore the use of includes to define 
additional custom widgets. Obviously we'll have to change this.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://bluxte.net                     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message