[JBoss JIRA] (DROOLS-5062) [DMN Designer] Automatically correct node prefix/trailing space on import
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5062?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5062:
-----------------------------------
Summary: [DMN Designer] Automatically correct node prefix/trailing space on import (was: [DMN Designer] Editor allows node with prefix/trailing space)
> [DMN Designer] Automatically correct node prefix/trailing space on import
> -------------------------------------------------------------------------
>
> Key: DROOLS-5062
> URL: https://issues.redhat.com/browse/DROOLS-5062
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
>
> I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
> But, imho, an UX point is not being considered, where is necessary instead.
> By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
> The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
> Further, I consider is just the Analyst which slipped a space.
> In my perspective, the editor should just strip away the prefix/trailing space:
> * while Importing a DMN model from file Upload
> * while editing a DRGElement and hitting OK to save its name
> For your consideration, thanks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5060) [DMN Designer] Editor allows node with prefix/trailing space
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5060?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5060:
-----------------------------------
Description:
I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
But, imho, an UX point is not being considered, where is necessary instead.
By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
Further, I consider is just the Analyst which slipped a space.
In my perspective, the editor should just strip away the prefix/trailing space:
* -While Importing a DMN model from file Upload- (See [DROOLS-5062|https://issues.redhat.com/browse/DROOLS-5062])
* While editing a DRGElement and hitting OK to save its name
For your consideration, thanks.
was:
I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
But, imho, an UX point is not being considered, where is necessary instead.
By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
Further, I consider is just the Analyst which slipped a space.
In my perspective, the editor should just strip away the prefix/trailing space:
*- While Importing a DMN model from file Upload- (See [DROOLS-5062|https://issues.redhat.com/browse/DROOLS-5062)
* While editing a DRGElement and hitting OK to save its name
For your consideration, thanks.
> [DMN Designer] Editor allows node with prefix/trailing space
> ------------------------------------------------------------
>
> Key: DROOLS-5060
> URL: https://issues.redhat.com/browse/DROOLS-5060
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
> But, imho, an UX point is not being considered, where is necessary instead.
> By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
> The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
> Further, I consider is just the Analyst which slipped a space.
> In my perspective, the editor should just strip away the prefix/trailing space:
> * -While Importing a DMN model from file Upload- (See [DROOLS-5062|https://issues.redhat.com/browse/DROOLS-5062])
> * While editing a DRGElement and hitting OK to save its name
> For your consideration, thanks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5060) [DMN Designer] Editor allows node with prefix/trailing space
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5060?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5060:
-----------------------------------
Tester: Jozef Marko
Description:
I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
But, imho, an UX point is not being considered, where is necessary instead.
By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
Further, I consider is just the Analyst which slipped a space.
In my perspective, the editor should just strip away the prefix/trailing space:
*- While Importing a DMN model from file Upload- (See [DROOLS-5062|https://issues.redhat.com/browse/DROOLS-5062)
* While editing a DRGElement and hitting OK to save its name
For your consideration, thanks.
was:
I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
But, imho, an UX point is not being considered, where is necessary instead.
By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
Further, I consider is just the Analyst which slipped a space.
In my perspective, the editor should just strip away the prefix/trailing space:
* while Importing a DMN model from file Upload
* while editing a DRGElement and hitting OK to save its name
For your consideration, thanks.
Labels: drools-tools (was: )
> [DMN Designer] Editor allows node with prefix/trailing space
> ------------------------------------------------------------
>
> Key: DROOLS-5060
> URL: https://issues.redhat.com/browse/DROOLS-5060
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
> But, imho, an UX point is not being considered, where is necessary instead.
> By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
> The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
> Further, I consider is just the Analyst which slipped a space.
> In my perspective, the editor should just strip away the prefix/trailing space:
> *- While Importing a DMN model from file Upload- (See [DROOLS-5062|https://issues.redhat.com/browse/DROOLS-5062)
> * While editing a DRGElement and hitting OK to save its name
> For your consideration, thanks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5062) [DMN Designer] Editor allows node with prefix/trailing space
by Michael Anstis (Jira)
Michael Anstis created DROOLS-5062:
--------------------------------------
Summary: [DMN Designer] Editor allows node with prefix/trailing space
Key: DROOLS-5062
URL: https://issues.redhat.com/browse/DROOLS-5062
Project: Drools
Issue Type: Bug
Components: DMN Editor
Reporter: Matteo Mortari
Assignee: Michael Anstis
I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
But, imho, an UX point is not being considered, where is necessary instead.
By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
Further, I consider is just the Analyst which slipped a space.
In my perspective, the editor should just strip away the prefix/trailing space:
* while Importing a DMN model from file Upload
* while editing a DRGElement and hitting OK to save its name
For your consideration, thanks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5060) [DMN Designer] Editor allows node with prefix/trailing space
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5060?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-5060:
----------------------------------------
no veto against having 2 separate jiras, as long as both UX of naming a node and importing a DMN model with that "defect" will be handled. Thanks1
> [DMN Designer] Editor allows node with prefix/trailing space
> ------------------------------------------------------------
>
> Key: DROOLS-5060
> URL: https://issues.redhat.com/browse/DROOLS-5060
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
>
> I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
> But, imho, an UX point is not being considered, where is necessary instead.
> By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
> The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
> Further, I consider is just the Analyst which slipped a space.
> In my perspective, the editor should just strip away the prefix/trailing space:
> * while Importing a DMN model from file Upload
> * while editing a DRGElement and hitting OK to save its name
> For your consideration, thanks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5060) [DMN Designer] Editor allows node with prefix/trailing space
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5060?page=com.atlassian.jira.plug... ]
Michael Anstis commented on DROOLS-5060:
----------------------------------------
Hi [~tari_manga] I'd like to limit this JIRA to correcting the leading/trailing white-space at the point of entry.
I'd like to move the other request ("While Importing a DMN model from file Upload") to a new JIRA for the following reason:
- It is an automated correction/cleanse
- We already have one automated correction (when layout information is missing or insufficient)
- We may, in the future, want to support other automated corrections
- I'd therefore like to consolidate the approach to _how_ automated corrections are detected, ran and reported to the User. My initial opinion is that when opening (or importing or some other trigger to be determined) a DMN file we collect (probably via CDI discovery) all implementations of "Automated Fixers" (one of which if layout another is trim leading/trailing space etc). We then show the list of possible fixes to the User, they can select whatever they like and then we run them and save the file. Anyway, IMO, it's out of scope of this JIRA as it'd need some UX involvement.
WDYT?
> [DMN Designer] Editor allows node with prefix/trailing space
> ------------------------------------------------------------
>
> Key: DROOLS-5060
> URL: https://issues.redhat.com/browse/DROOLS-5060
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
>
> I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
> But, imho, an UX point is not being considered, where is necessary instead.
> By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
> The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
> Further, I consider is just the Analyst which slipped a space.
> In my perspective, the editor should just strip away the prefix/trailing space:
> * while Importing a DMN model from file Upload
> * while editing a DRGElement and hitting OK to save its name
> For your consideration, thanks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5061) DMN codegen DMNContext and DMNResult
by Matteo Mortari (Jira)
Matteo Mortari created DROOLS-5061:
--------------------------------------
Summary: DMN codegen DMNContext and DMNResult
Key: DROOLS-5061
URL: https://issues.redhat.com/browse/DROOLS-5061
Project: Drools
Issue Type: Epic
Components: dmn engine
Reporter: Matteo Mortari
Assignee: Luca Molteni
A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
Surface and interface common to:
* BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
* Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
* DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4172) Add support for TLS 1.3
by Harish Murali (Jira)
[ https://issues.redhat.com/browse/WFCORE-4172?page=com.atlassian.jira.plug... ]
Harish Murali commented on WFCORE-4172:
---------------------------------------
Thanks [~fjuma]. Any idea about the expected release dates for wildfly 19 . I see the beta is available, but I would like to know the final release date. Please let me know the right forum, in case if this is not the place to discuss this.
> Add support for TLS 1.3
> -----------------------
>
> Key: WFCORE-4172
> URL: https://issues.redhat.com/browse/WFCORE-4172
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Major
> Labels: affects-model, eap-7.2.0-deferred
> Fix For: 11.0.0.Beta6
>
>
> It presently appears as though TLS 1.3 support could be available from Java 11.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months