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

[Michael Wechner]

Michael Wechner wrote:
> 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.

should be fixed now as well

svn ci -m "also check resource type name and namespace" 
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 46990.

Cheers

Michi
>
> 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
>>>
>>
>