[Yanel-dev] resource-creator and creation of resource-configuration

[Michael Wechner]

simon wrote:
> Michael Wechner schrieb:
>> simon wrote:
>>> hi all
>>>
>>> i'm developing a svg resource-type. have a look at 
>>> http://trac.yanel-contribution.3k3.org/wiki/svg
>>> the resource configuration is done with configurable views within a 
>>> custom-config (like the BasicXMLResource).
>>
>> very cool :-)
> BTW i also integrated svg-edit which is a cool browser based svg 
> editor: http://trac.yanel-contribution.3k3.org/wiki/svg-edit
> soon i will have a online demo page.
>>
>> I would like to add a third-party resource type page to the yanel 
>> website where we can link such resource types as yours.
>>
>> Makes sense?
> would be nice.
>>> i implemented CreatableV2 to allow creation of an svg via 
>>> resource-creator. but the resource-creator is not able to create 
>>> custom-config. i think this is ok for now. but what i would like is 
>>> to disable creation of resource configuration at all.
>>> e.g if CreatableV2.createRTIProperties(Request) returns null no 
>>> resource-configuration is created. this would be useful for resource 
>>> which are configured via rc-map.
>>
>> very much aggreed and I have the same itch ;-)
>>
>> The question is where would you expect this to be configured? Or just 
>> as you suggest above if null is returned?
> the problem is null  is check and  just adds a RC without any 
> properties. i think is not really proper to change the null behavior.
>>>
>>> an other solution would be to delegate the creation of the 
>>> resource-configuration to the resource. e.g. within CreatableV2 
>>> introduce a methode createRC(HttpServletRequest request).
>>
>> that would probably be the most elegant. I think the CreatableV2 is 
>> not released yet
> after thinking some more time i really would prefer a methode 
> createRC(HttpServletRequest request).

On second thought I do not think the resource itself should be 
responsible for creating the resource config node, but
rather the realm or the resource creator (adapter). Even the resource 
config data/content probably shouldn't be created by
the resource type itself, because this can be dependent on the realm or 
the resource creator.

Well, I have implemented a resource config map check:

svn ci -m "check resource config map first" 
src/contributions/resources/resource-creator/src/java/org/wyona/yanel/impl/resources/rescreator/ResourceCreatorResource.java 

Sending        
src/contributions/resources/resource-creator/src/java/org/wyona/yanel/impl/resources/rescreator/ResourceCreatorResource.java
Transmitting file data .
Committed revision 46988.

and now the resource config node should not be created anymore if it 
already matches within the map.

I have tested it with the from scratch realm and it seems to work fine, 
but strictly speaking this is not backwards compatible
and actually this check should be configurable and off by default in 
order to be really backwards compatible.

Also at the moment only the matching is checked, but not really if the 
resource types are equal and hence one cannot make
exceptions to the rule/pattern, whereas I will try to fix this shortly.

Please give it a try and let me know if this works for you.

Btw, I have also added a TODO re custom config, but this is actually a 
separate task to enhance.

Thanks

Michi


>>
>> http://www.yanel.org/javadoc/org/wyona/yanel/core/api/attributes/CreatableV2.html 
>>
>>
>> but on the other hand it exists for quite some time now without any 
>> changes and hence I am afraid
>> that people consider it realeased ...
> i'm afraid as well. i would suggest to release CreatableV2 now as it 
> is. and introduce a new Creatable with the new method. unfortunately 
> there is already this CreatableV3. i guess it's not possible to 
> introduce a CreatableV2.1 right?
>
> wouldn't it make sense to release the interfaces early and often?
>
> cheers
> simon
>
>>
>> Also we have the still experimental CreatableV3 within the 
>> contributions folder ....
>>
>> Well, we need to discuss this and make some decisions ;-)
>>
>> Thanks
>>
>> Michi
>>>
>>> WDOT?
>>>
>>> cheers
>>> simon
>>
>