I think I will make DSL an "asset" - but there will by default be only one (like Highlander - "there can be only one") - that will be the one used unless there are multiple in which case you would have to specify which one to use.
<br><br>Model I will do the same.<br><br>The NEXT question is: One model (versioned) or multiple files? I spose multiple files are also doable as well.... <br><br><div><span class="gmail_quote">On 2/2/07, <b class="gmail_sendername">
Edson Tirelli</b> <<a href="mailto:tirelli@post.com">tirelli@post.com</a>> 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> Answering Michael, I agree with Felipe on Q2, but on Q1, I would<br>like to note that I think it would be good to allow for more than one<br>DSL in the future. This way, we would be able to create DSLs associated<br>
with "partitions" of the business model, and for each ruleset, we would<br>use the DSLs associated with each partition we are using. Ok, the<br>explanation is messy, so let me tell about an eventual use case:<br>
<br> In a telecom market, we possibly would have a Customer Business<br>Model (with customer related info), a Telecom Service Business Model<br>(with service related info, like calls, service plans, etc) and a<br>Finance Business Model (with billing related info, like charges,
<br>discounts, etc). So, a Billing system would use the Telecom Service<br>Business Model and Finance Business Model, while a Customer Self-Service<br>System might use the Telecom Service and Customer Business Model, while
<br>the CRM would use all of them.<br> As the DSL usually translate to Patterns and Constraints of the<br>mapped business model, and actions related to that, it would be good<br>from a reuse perspective to allow the use of multiple DSLs in each context.
<br> So, IMO, we should be prepared to support multiple DSL's for a<br>single rulebase/drl soon. If that mean the DSL must be assets instead of<br>attribute, I would go for it.<br><br> Just my 0.02.<br><br> []s
<br> Edson<br><br><br><br>Felipe Piccolini wrote:<br><br>> Hi Michael,<br>><br>> Iv been following your work in the brms/repository very closely<br>> because Im working in something very similar by<br>> my self for a project using JBossRules, and as I cant wait much longer
<br>> I decided to use your work as a base to<br>> put something on production until you guys do the "real-cool" thing.<br>><br>> About your questions, IMHO,<br>> -Q1: I think dsl should be an attribute (as far as I know, you can put
<br>> only 1 dsl expander on drl files) and<br>> there should be only one reference to expand the rule sentences, if<br>> you have multiple dsl, then have mutiple drl (packages).<br>> -Q2: I think object models (or business models to use as facts for
<br>> your rules) should be assets, so u can organize your model/classes<br>> not thinking in drools or any other framework, so you can extend your<br>> model or rules with just a pointer as a dependency, just as you
<br>> can put or remove jars from your classpath.<br>><br>> One thing I wanted to tell you for some time about drools-brms is<br>> that for some reason I dont know, the gwt ui looks awfull on mac (OS X),<br>> I made it works changing some things on the .launcher and .shell
<br>> files, but its looks like no modal window has a background, or complete<br>> messed up.. can you check it out? or help me to guiding me what to<br>> check to see it right? Thanks.<br>><br>><br>> On 01-02-2007, at 3:23, Michael Neale wrote:
<br>><br>>> BUT this also applies to the file structure for "packages" in a file<br>>> system/IDE (forget monolothic DRL for a moment - but instead imagine<br>>> a folder which is a rule package containing lots of rules).
<br>>><br>>> (in no particular order);<br>>><br>>> Q1: Should DSL "language configurations" be stored as an "asset"<br>>> inside a package (ie a file, perhaps multiple ones of them?) - or are
<br>>> they an attribute of a package?<br>>> Q2: The object model: should this be stored as an attribute of a<br>>> package - or just another asset of which there can be muliple ones<br>>> uploaded (as a jar, for instance).
<br>>> This is needed for validation/tooling. Obviously in the IDE the<br>>> classes will be on the classpath, but in the repo they have to be<br>>> stored somewhere.<br>>><br>>> Note versioning works well in all scenarios (subtle differences
<br>>> between a package attribute and asset for versioning, but ignore them<br>>> for now).<br>>><br>>> I have opinions, but wanted some discussion (attachment screenshot<br>>> shows the package managment screen).
<br>>> <Screenshot-JBoss Business Rules Management System .png><br>>> _______________________________________________<br>>> rules-dev mailing list<br>>> <a href="mailto:rules-dev@lists.jboss.org">
rules-dev@lists.jboss.org</a> <mailto:<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>><br>><br>><br>> *Felipe Piccolini M.*<br>> <a href="mailto:felipe.piccolini@bluesoft.cl">felipe.piccolini@bluesoft.cl</a> <mailto:<a href="mailto:felipe.piccolini@bluesoft.cl">felipe.piccolini@bluesoft.cl
</a>><br>><br>><br>><br>><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>><br>><br><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>