[rules-dev] Resource getName getDescription

[Esteban Aliverti]

Done:
https://github.com/droolsjbpm/droolsjbpm-knowledge/pull/14
https://github.com/droolsjbpm/drools/pull/61
https://github.com/droolsjbpm/droolsjbpm-integration/pull/7

Best Regards,

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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


On Mon, Sep 12, 2011 at 10:32 AM, Mark Proctor <mproctor at codehaus.org>wrote:

>  On 12/09/2011 09:18, Esteban Aliverti wrote:
>
> 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.
>
> At some point geoffrey is going to add a -internal-apior something like
> like. The idea is to use this as a staging ground to allow end user apis to
> mature to stability.
>
> At the moment the whole stuff around changesets, resources etc is still
> very immature and i'm not sure we have the entire design right. If you
> notice in the changeset javadocs I tell people to only use the xml change
> notation and not the api at this stage. I want to see us mature this futher
> before we start locking apis in granite. We still have a lot work to do on
> deployment, especially on changesets.
>
> For your current use case the user should never be accessing the resulting
> Resource instances anyway, it's applied via the xml. If there is a problem
> that information becomes part of an informational error log. They aren't
> going to inspect resulting resource instances.
>
> Mark
>
>
>  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
>>
>>
>
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110912/86f62274/attachment-0001.html