[JBoss JIRA] Created: (JBRULES-2245) Guided Editor in BRMS always shows DSL sentences completely separated from fact patterns - but original input order is required in certain situations.
by Gunnar von der Beck (JIRA)
Guided Editor in BRMS always shows DSL sentences completely separated from fact patterns - but original input order is required in certain situations.
------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-2245
URL: https://jira.jboss.org/jira/browse/JBRULES-2245
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-guvnor
Affects Versions: 5.0.1.FINAL
Reporter: Gunnar von der Beck
Assignee: Mark Proctor
Priority: Minor
When building custom DSL snippets for expressions like {{over window:time(...)}} or {{over window:length(...)}} i would like to give the user the option to mix these DSL snippets with facts by using the guided editor in the BRMS. Especially these DSL snippets must be placed directly after a fact pattern, e.g. {{Product( ... ) over window:time(30d)}}. Therefore they only make sense in a context behind a fact definition.
But the guided editor in Guvnor always places DSL sentences on the bottom of the left hand side - totally separated from the rest (not in the generated code, but in the GUI-View). So in more complex situations the user might loose the context of his DSL-like-input.
Anyway I think that the preferred way of presenting the users input would be to leave the original input order as is.
So here is my solution - a minor change in org.drools.guvnor.client.modeldriven.ui.RuleModeller. You might want to adopt it if you think this is a good idea.
{code:title=RuleModeller.java|borderStyle=solid}
package org.drools.guvnor.client.modeldriven.ui;
...
public class RuleModeller extends DirtyableComposite {
...
/**
* Builds all the condition widgets.
*/
private Widget renderLhs(final RuleModel model) {
DirtyableVerticalPane vert = new DirtyableVerticalPane();
IPattern lastPattern = null;
for ( int i = 0; i < model.lhs.length; i++ ) {
IPattern pattern = model.lhs[i];
// start new code
// insert spacer when switching from DSL sentence to other pattern
if (lastPattern != null &&
(lastPattern instanceof DSLSentence)
&& (!(pattern instanceof DSLSentence))) {
vert.add( spacerWidget() );
}
lastPattern = pattern;
// end new code
Widget w = null;
if (pattern instanceof FactPattern) {
w = new FactPatternWidget(this, pattern, completions, true) ;
vert.add( wrapLHSWidget( model,
i,
w ) );
vert.add( spacerWidget() );
} else if (pattern instanceof CompositeFactPattern) {
w = new CompositeFactPatternWidget(this, (CompositeFactPattern) pattern, completions) ;
vert.add( wrapLHSWidget( model, i, w ));
vert.add( spacerWidget() );
} else if (pattern instanceof DSLSentence) {
// start new code: do not ignore DSL sentences any more
w = new DSLSentenceWidget((DSLSentence) pattern,completions);
vert.add( wrapLHSWidget( model, i, w ) );
vert.setStyleName( "model-builderInner-Background" ); //NON-NLS
// end new code
} else if (pattern instanceof FreeFormLine){
final FreeFormLine ffl = (FreeFormLine) pattern;
final TextBox tb = new TextBox();
tb.setText(ffl.text);
tb.setTitle(constants.ThisIsADrlExpressionFreeForm());
tb.addChangeListener(new ChangeListener() {
public void onChange(Widget arg0) {
ffl.text = tb.getText();
}
});
vert.add(wrapLHSWidget(model, i, tb));
vert.add( spacerWidget() );
} else {
throw new RuntimeException("I don't know what type of pattern that is.");
}
// removed the second extra loop for DSLSentence patterns: integrated above
}
return vert;
}
...
}
{code}
This would give the end user a lot more options building rules with the guided editor - especially when mixing prepared DSL sentences with Fact patterns.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month
[JBoss JIRA] Created: (JBRULES-2132) Patch: Docs: Expert: Rule Language chapter: DSL Section
by Prem Stephen (JIRA)
Patch: Docs: Expert: Rule Language chapter: DSL Section
-------------------------------------------------------
Key: JBRULES-2132
URL: https://jira.jboss.org/jira/browse/JBRULES-2132
Project: JBoss Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 5.0.1.FINAL
Reporter: Prem Stephen
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.0.1.FINAL
In the following DSL
[when]There is a Contact with=Contact()
[when]- age is greater than or equal to {age}=age > {age}
[when]- age is greater than {age}=age > {age}
[when]- age is less than or equal to {age}=age <= {age}
[when]- age is less than {age}=age < {age}
Now, if I had 10 attributes of type int, then currently from what I could read in my documentation I need to recreate these lines for each of these 10 attributes.
Hope about a DSL that is more granular, similar to the one below ( i am just putting this up )
[when][operator]is less than="<"
[when][operator]is less than or equal to ="<="
[when][operator]is greater than=">"
[when][operator]is greater than or equal to =">="
then, I should be able to state that since age is a int, it can use the above operators.
A country, being a String, should not be able to use these operators.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month
[JBoss JIRA] Created: (JBMICROCONT-130) Array part of the Javassist reflection implementation is broken
by Adrian Brock (JIRA)
Array part of the Javassist reflection implementation is broken
---------------------------------------------------------------
Key: JBMICROCONT-130
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-130
Project: JBoss MicroContainer
Issue Type: Task
Components: BeanInfo
Affects Versions: JBossMC_2_0_0 Beta
Reporter: Adrian Brock
Javassist is returning wrong values for interfaces of arrays and modifiers of array classes.
These errors have been suppressed in org.jboss.test.classinfo.test.JavassistArrayUnitTestCase
by subclassling the tests to do nothing:
protected void assertInterfaces(Class<?> clazz, ClassInfo classInfo) throws Throwable
{
// TODO this is broken for javassist
}
protected void assertModifiers(Class<?> clazz, ClassInfo classInfo) throws Throwable
{
// TODO this is broken for javassist
}
This needs fixing in javassist
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month
[JBoss JIRA] Created: (JBAS-4963) invocationHasReachedAServer calls within exception handling vary from UnifiedInvokerHAProxy to JRMPInvokerProxyHA
by Galder Zamarreno (JIRA)
invocationHasReachedAServer calls within exception handling vary from UnifiedInvokerHAProxy to JRMPInvokerProxyHA
-----------------------------------------------------------------------------------------------------------------
Key: JBAS-4963
URL: http://jira.jboss.com/jira/browse/JBAS-4963
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-4.2.2.GA, JBossAS-5.0.0.Beta3
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Exception handling is different between JRMPInvokerProxyHA and
UnifiedInvokerHAProxy when it comes to, at least, calls to invocationHasReachedAServer():
1.- JRMPInvokerProxyHA
Exception handling that does not lead to invocationHasReachedAServer() being called:
* java.net.ConnectException
* java.net.UnknownHostException
* java.rmi.ConnectException
* java.rmi.ConnectIOException
* java.rmi.NoSuchObjectException
* java.rmi.UnknownHostException
* GenericClusteringException.NO
Exception handling that leads to invocationHasReachedAServer() being called:
* GenericClusteringException.YES
* java.rmi.ServerException
* java.lang.Exception
2.- UnifiedInvokerHAProxy
Exception handling that does not lead to invocationHasReachedAServer() being called:
* org.jboss.remoting.CannotConnectException
* GenericClusteringException.NO
* java.rmi.RemoteException
* java.lang.Throwable
Exception handling that leads to invocationHasReachedAServer() being called:
* GenericClusteringException.YES
This JIRA tracks discussions to clarify the correctness of UnifiedInvokerHAProxy and any
potential coding required.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month