Edson, doesn&#39;t have to be line based, thats just the way it worked now cause it made it easier to expand.<br><br>It *will* need to work with the IDE of course - which at the moment is kind of mixed up with the regular DRL editor&nbsp; (so it gets content suggestions from the DSL if it is using one). Kris wants to seperate out the DSL aware editor from the vanilla DRL one (so its less of a mess) as well - so keep that in mind.
<br><br>Some other requirements:<br><br>* Errors when expanding should be accumulated in an error list, like the normal parser<br>* Should be able to allow/disallow &quot;in line DRL&quot; expressions (ie you may want to stop people from doing something that is regular DRL, and restrict it to DSL sentences only
<br>* Error messages should be &quot;friendlier&quot; - as in &quot;The sentence [....] is not understood. Perhaps you mean&#39;t [... nearest match from the DSL expressions ...]&quot; - if possible (would be nice !)<br>* DSL should work on whole drl files (as now) but *also* files which are just one rule (in which case the package context comes from outside the file, including the DSL etc). It may be desirable in this case to skip the &quot;end&quot; as it is not needed (and looks out of place in a natural type scenario - also the &quot;rule XYZ&quot; could be optional if the API tells the expander the rule name, which may be the file name etc). 
<br><br>Does all that make sense?<br><br>Michael.<br><br><div><span class="gmail_quote">On 2/5/07, <b class="gmail_sendername">Edson Tirelli</b> &lt;<a href="mailto:tirelli@post.com">tirelli@post.com</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>&nbsp;&nbsp;&nbsp;&nbsp; All,<br><br>&nbsp;&nbsp;&nbsp;&nbsp; I will reintegrate/implement DSL support in drools-compiler, as we
<br>discussed before, as a pre-processor. I have some questions I would like<br>to have your opinion about:<br><br>Q1: Is there any reason for the DSL parser to be line based?<br><br>Q2: I will make keywords configurable, so you can say &quot;regra&quot; for
<br>instance (in portuguese) instead of &quot;rule&quot;, ok?<br><br>Q3: Peter: I&#39;m thinking in copy/port the DSL tree that you created into<br>drools-compiler... I think we can leverage it to help create a better<br>
parser for the DSL, ok?<br><br>Q4: do we need everything to be expandable in the DSL? or should we<br>simply passthrough anything that is not expandable directly as a chunk<br>to the DRL? Example:<br><br>DSL:<br>=====<br>
...<br>regra ABC<br>se<br>&nbsp;&nbsp; ...<br>entao<br>&nbsp;&nbsp; System.out.println( &quot;BLABLA&quot; );<br>fim<br>...<br>====<br><br>&nbsp;&nbsp;&nbsp;&nbsp;Ok, I know that no business user will ever write<br>System.out.println(), but it is just just an example. And the keywords
<br>are in portuguese for you guys to understand it better... ;)<br><br>&nbsp;&nbsp; Thanks for the feeback.<br><br>&nbsp;&nbsp; []s<br>&nbsp;&nbsp; Edson<br><br>--<br> Edson Tirelli<br> Software Engineer - JBoss Rules Core Developer<br> Office: +55 11 3124-6000
<br> Mobile: +55 11 9218-4151<br> JBoss, a division of Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a><br><br><br>_______________________________________________<br>rules-dev mailing list<br><a href="mailto:rules-dev@lists.jboss.org">
rules-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br></blockquote></div><br>