Re: [rules-dev] Resource getName getDescription
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(a)codehaus.org
> <mailto:mproctor@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
Attachments:
- attachment.html (text/html — 7.9 KB)