[rules-dev] Resource getName getDescription

[Geoffrey De Smet]

We could use Abstract* class trick (the Collections api does it and I 
use it a lot in Planner):

drools-api has:
   interface Resource
   abstract class AbstractResource implement Resource
And the javadoc on interface Resource clearly states that they should 
extend AbstractResource when implementing a custom Resource. Same for 
the reference manual.
(Similar to interface List and class AbstractList)

Then if any new method is added, the AbstractResource implementation 
should try to provide a reasonable default that works (but is possibly 
not as efficient as a specific implementation).
As a result, any custom Resource that extend AbstractResource needed be 
changed immediately (but might want to in time to implement a more 
efficient implementation).

And, more importantly, we don't break binary backwards compatibility on 
*api (unless they implemented Resource directly)
so less chance of "impossible to fix" if you have a project with a 
dependency A and B
where A and B themselves depend on different drools versions,
as you can just use the "highest version" between those 2 dependencies.

Op 12-09-11 07:51, Mark Proctor schreef:
> On 12/09/2011 06:36, Esteban Aliverti wrote:
>> Ok, I thought #droolsdev was ok too. Sorry about that.
>> The idea to have a 'name' and a 'description' attribute in <Resource> 
>> elements inside a change-set is to tag them or to add them some 
>> human-friendly information so you can refer to it not using the URL 
>> or the name of the asset (could be duplicated in different packages), 
>> but with a name and a description.
>> These changes are 100% end-users oriented, that is why I put those 
>> attributes in API. End users applications (like Guvnor) could take 
>> advantages on these new attributes.
> You can add them to the xml, and have that set them on the 
> InternalResource. We can migrate to public apis over time, I just want 
> people to take a much more conservative outlook on -api changes.
>
> Mark
>>
>> So, a change-set now could look like this (the new attributes are not 
>> mandatory):
>>
>> <change-set>
>> <add>
>> <resource *name="Loan Rules" description="Rules about loans"* 
>> type="DRL" source="http://someHost:1234/someDRLResource.drl"/>
>> <resource *name="Risk Rules" description="Rules about Risk 
>> evaluation"* type="DRL" 
>> source="http://someHost:1234/someOtherDRLResource.drl"/>
>> </add>
>> </change-set>
>>
>> These attributes can also be used in Spring's configuration:
>>
>> <drools:kbase id="kbase1" node="node1">
>> <drools:resources>
>> <resource *name="Loan Rules" description="Rules about loans"* 
>> type="DRL" source="http://someHost:1234/someDRLResource.drl"/>
>> <resource *name="Risk Rules" description="Rules about Risk 
>> evaluation"* type="DRL" 
>> source="http://someHost:1234/someOtherDRLResource.drl"/>
>> </drools:resources>
>> </drools:kbase>
>>
>> WDYT?
>>
>> Best Regards,
>>
>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>>
>> Esteban Aliverti
>> - Developer @ http://www.plugtree.com <http://www.plugtree.com>
>> - Blog @ http://ilesteban.wordpress.com
>>
>>
>> On Mon, Sep 12, 2011 at 6:25 AM, Mark Proctor <mproctor at codehaus.org 
>> <mailto:mproctor at codehaus.org>> wrote:
>>
>>     Shoudn't name and description be on InternalResource, not on
>>     Resource?
>>
>>     I think it's time to put a restriction on changes to "-api". Feel
>>     free
>>     to change core/compiler etc, but if you want to change -api we'll
>>     need
>>     to propose it here.
>>
>>     Mark
>>
>>     _______________________________________________
>>     rules-dev mailing list
>>     rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

-- 
With kind regards,
Geoffrey De Smet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110912/39e203fd/attachment-0001.html