[
http://jira.jboss.com/jira/browse/JBRULES-807?page=comments#action_12360303 ]
Edson Tirelli commented on JBRULES-807:
---------------------------------------
This one is though, but I agree it needs 'fixing' so I could use some advice.
Problem is that the DSL pre-processor as it is today is really a "macro
pre-processor". Almost like C/C++ macros where you can really transform the original
DRL into a completelly different one when running the expander. One simple example is
allowing not only the keywords substitution, but also to change the complete structure of
a rule file. Like doing in portuguese somethine like:
regra "rule name"
faça
// RHS
quando
// LHS
i.e., reversing the order of RHS/LHS (as woolfel asked for better backward chaining
'feeling') or ommiting keywords (like the "end" keyword that is not
present in the above rule and is automatically appended by the DSL pre-processor.
Also, the current DSL pre-processor is capable of making the DRL file cleaner by allowing
for "hiding" ugly stuff. Example: one can define functions in the mapping file
now and only add a single "use" clause in the DRL file:
DSL mapping (in XML format for instance):
-----------
<mapping>
<section> keyword</section>
<key>Add finance functions</key>
<value>
function finance1(...) {
...
}
function finance2(...) {
...
}
...
</value>
</mapping>
-----------
So the DRL file would contain a single line, responsible for adding all the
"clutter" stuff:
----------
Add finance functions
---------
Not sure if it is really a good idea, but works. :)
Anyway, all this flexibility in the core pre-processor engine has the price of complexity.
The way it is now, it is really difficult to map error messages to offsets in the original
DRL (even worst to use lines instead of offsets). Although, I understand that this is a
needed feature.
What I thought about is to use a datastructure to do the mapping by offset, so each
manipulation that is done in the source file is reflected in the data-structure. But this
is not easy and I'm still not sure it is feasible, since the core engine supports
multi-phase expansion, where a chunk can be expanded to another chunk that is recursivelly
expanded. This is good for building DSL hirarchies where a DSL is defined using sentences
defined by another DSL.
Anyway, another approach is to limit the flexibility, i.e., for instance, disallow
structural changes. Example, instead of allowing full template rewriting, we could only
allow simple keyword translations. This way, we can use the keywords as reference points
in the original DRL for error reporting. So, if "rule" is translated to
"regra", but we garantee it is present in the original DRL (no structural
changes), we calculate offsets using it as a reference point. The question is: is the loss
of flexibility worth in this case?
Any other ideas you guys have? questions?
DefaultExpander not recording line numbers of errors correctly
--------------------------------------------------------------
Key: JBRULES-807
URL:
http://jira.jboss.com/jira/browse/JBRULES-807
Project: JBoss Rules
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-brms
Reporter: Michael Neale
Assigned To: Edson Tirelli
In DefaultExpanderTest, I have added a method:
FIXME_testLineNumberError()
this shows how it should work. The problem is that the line number calculated and
reported is relative to the LHS block (in this case) whereas it have to be relative to the
whole "file".
--
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