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.l...@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.ne...@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.l...@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@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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
