[rules-dev] Resource getName getDescription

[Esteban Aliverti]

Ok, I will move these attributes to drools-core (InternalResource). Later,
we can think about move them to drools-api.
Geoffrey, I like your idea, but I think that is not the "drools way" :).
What Mark wants is to always add new stuff in core and later, when it is
stable enough, publish it through drool-api. I agree with this, but when the
improvements are only useful for api users (name and description are not
used in drools-core in any way) I find this a little bit cumbersome. The
feature is never going to be used if it is no exposed. Users must always
cast Resource to InternalResource if they want to use this (And I see a lot
of these casts even inside drools-core).
But, as a general solution, I'm not against the implementation of new
features in core first and the exposure on api later.

Best Regards,

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Esteban Aliverti
- Developer @ http://www.plugtree.com
- Blog @ http://ilesteban.wordpress.com


On Mon, Sep 12, 2011 at 9:04 AM, Geoffrey De Smet
<ge0ffrey.spam at gmail.com>wrote:

> **
> 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
> - Blog @ http://ilesteban.wordpress.com
>
>
> On Mon, Sep 12, 2011 at 6:25 AM, Mark Proctor <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
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110912/4abc9d25/attachment.html