[rules-dev] Stretching spreadsheets

[Michael Neale]

I think that goes back to an attempt to let people use different
words/languages without i18n - so probably a bad idea.

Unless people object, I propose getting rid of that behaviour and cleaning
it up to be keywords - AS LONG AS if they put in a non valid keyword, the
error shows a list of what *is* valid so they can then correct it.



On Mon, Nov 29, 2010 at 11:53 PM, Wolfgang Laun <wolfgang.laun at gmail.com>wrote:

> Hi Michael,
>
> I just discovered ActionType.addNewActionType, where the code tries to
> follow some
> (now) completely undocumented principle, where columns can be identified by
> single
> letters, the first one of the action type. This is in conflict with the
> documentation,
> where only full-fledged keywords are permitted.
>
> There are some undocumented keywords, e.g., DESCRIPTION. Using this results
> in a duration attribute (which is deprecated anyway). This can be fixed,
> but then
> the description is entered "as is"; it should have a leading '#'.
>
> Clear out all undocumented things? Or fix them properly and document them?
>
> What is it to be?
> -W
>
>
>
> On 28 November 2010 23:33, Michael Neale <michael.neale at gmail.com> wrote:
>
>> nice work..
>> yes "syntax cushioning" is the best term I have heard for this.
>>
>> I am sure your enhancements would be welcome.
>>
>> On Mon, Nov 29, 2010 at 5:14 AM, Wolfgang Laun <wolfgang.laun at gmail.com>wrote:
>>
>>> I have, at long last, overcome my disinclination against spreadsheets and
>>> played around a bit.
>>>
>>> As one of the incentives (perhaps the main one) for this kind of rule
>>> authoring appears to be a "syntax" cushioning by spreadsheet entries, I feel
>>> that additional simplifications might be appreciated. Therefore, I have
>>> modified some classes in  org.drools.decisiontable.parser, to achieve the
>>> following, in the area of RuleSet entries:
>>>
>>>    - All entries are now repeatable, either by adding more cells to the
>>>    right of "import" than just one (with a comma-separated list) or by writing
>>>    more that one "Import" row.
>>>    - Same for "Variables", "Functions" and "Queries".
>>>    - All tags ("Import",...) are case insensitive and immune against
>>>    leading and trailing spaces.
>>>    - Some user errors don't cause NPE; they throw an exception with an
>>>    explanatory message
>>>
>>> Opinions, please, and should I just release this, or would someone care
>>> to have a look and test it?
>>>  -W
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>
>>
>> --
>> Michael D Neale
>> home: www.michaelneale.net
>> blog: michaelneale.blogspot.com
>>
>> _______________________________________________
>> 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
>
>


-- 
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101130/f3908820/attachment.html