[ http://jira.jboss.com/jira/browse/JBRULES-647?page=comments#action_12354928 ] Michael Neale commented on JBRULES-647: --------------------------------------- The RuleModel class, in jbrms: org.drools.brms.client.modeldriven.brxml.RuleModel Needs to either: a) Render to DRL or b) Map to Descrs (bypassing DRL) There are advantages to either approach. Round tripping is not required at this stage. Approach a) This involves iterating through the Patterns and Actions, and adding to a DRL string, which will then be fed to the normal parser (but just for a single rule). Approach b) Similar to above, but creating instances of Descr objects. the complication with this approach (which I am not sure how to solve) is if there is a DSL sentence involved - this HAS to be expanded, and then put through the parser - that may make it difficult or impossible. Unlike the Descrs, the RuleModel has classes for specific actions. There will need to be some intelligence for when user entered values are to be treated as strings: If the field on a fact is a string, then obviously we are dealing with a string UNLESS: 1) The user has placed a "=" at the start - to indicate its a "formula" or b) the value is the same name as a bound variable. -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-647?page=comments#action_12360642 ] Edson Tirelli commented on JBRULES-647: --------------------------------------- Was talking to Fernando today about the ROM -> Descr conversion and we came to a conclusion. Besides all we talked about supporting directly ROM->Descr without serializing to DRL, if a rule is "contaminated" by a single DSL sentence, the whole rule MUST be expanded to a DRL and use the parser to convert it to a descriptor. That is because someone could write in the BRMS (mixing DSL and DRL sentences) something like: rule xyz when Cheese() // drl sentence - whose type is "brie" // dsl sentence then // RHS end In the above case, the DSL sentence is a constraint (type == "brie") that needs to be added to the Cheese() pattern. So, once contaminated by a DSL sentence, the direct conversion can't be done. Once we understand that we need to have a ROM -> DRL dumper for cases where the ROM is contaminated, the question that rises is "what good does us to have a ROM->Descr converter? does the performance gain of not using the parser justifies the disadvantage of code complexity and maintanance of another 'converter'?". I know I pushed for direct ROM->Descr conversion, but I didn't know about the DSL/DRL sentence mixing possibility. I would say now that we should simply: 1. drop the BRXMLtoDescrConverter 2. make BRLPersistence an interface and rename the current implementation to something like XMLBRLPersistence. 3. implement a DRLBRLPersistence to dump ROM to DRL format 4. create a new BRXMLtoDescrConverter that is simply a helper, higher level API that does ROM->DRL->Descr conversion using above class + drl parser. What do you think? -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-647?page=comments#action_12360644 ] Edson Tirelli commented on JBRULES-647: --------------------------------------- Michael, I added the persister capable of doing ROM -> DRL transformation. Although, the round trip is something that worries me a bit. Basically, we delliberatelly added some restrictions to the modeller and to the ROM ( like no arbitrary nesting of CEs ) that don't exist in the pure core engine (and in the DRL). How do you think we should handle such restrictions when "importing" DRLs into the BRMS? I'm asking that because the round trip code is where this needs to be implemented, right? []s Edson -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-647?page=comments#action_12360785 ] Edson Tirelli commented on JBRULES-647: --------------------------------------- Michael I added the integration of the conversion to the BRXMLContentHandler and added the test case in ServiceImplementationTest. Look for the test named: testBinaryPackageCompileAndExecuteWithBRXML. The only thing I'm not sure is how you differentiate Strings from other constants, like numbers in the model. For instance, in the test, I wanted to set the integer "age" field of the person object. As a way to differentiate the value from a regular String value, I made it a "formula", adding the "=" as the first character. Although, I'm not sure that this is the best way of doing it. Can you plz advise what you imagined for that? Example: This: ActionSetField action = new ActionSetField("p"); ActionFieldValue value = new ActionFieldValue("age", "=42"); action.addFieldValue( value ); Is converted to (in DRL): p.setAge( 42 ); Thanks. -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-647?page=comments#action_12360857 ] Edson Tirelli commented on JBRULES-647: --------------------------------------- I will try to make the type inference to be transparent for the user, so no changes in the GUI. -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-647?page=comments#action_12360963 ] Michael Neale commented on JBRULES-647: --------------------------------------- OK, I woke up this morning in a panic (I tend to wake up like that - I hate the clarity and perspective that waking up brings): What about date literals? Dates are also kind of a special case I think. On the LHS in drl dates are pretty easy, we just slap quotes around them and the compiler takes care of it. But on the RHS we need to new java.util.Date() - although MVEL may take care of it. Some general questions I am not sure about (regarding the RHS): * Do we allow a field to be set to a bound variable? * We can deal with string/number literals, but what about dates? * Say we want to set a field to a calculation, for a non String, this should work as it is now right? so we have a "value" of "x *3.0 - someVar" then that will be: boundVariable.setSomeField(x * 3.0 - someVar) UNLESS it is a string, in which case it will try to wrap quotes around it (which is not really a problem, as you generall don't do calculations with a string). I guess my original question remains: shoudl we ask the user to classify if they are doing a literal, a formula or choosing from a list of variables? or is that overkill and unhelpful? -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-647?page=comments#action_12360993 ] Edson Tirelli commented on JBRULES-647: --------------------------------------- My suggestion is the obvious one: lets start simple and build over it. Yes, the old java Date issue. I think what we need to do is to define a general (maybe configurable) mask for dates and automatically parse strings into dates in the input fields. This can be based on the field type, as we already do manipulations for strings (adding quotes) and formulas (removing the = sign). Sure. From a code generation perspective, it is already supported. Just a matter of allowing users to chose or type variables in the Web GUI. See above. The way it is now, from code generation perspective, it is already working. The key thing is that if the field type is String and you want to do manipulations, you MUST use the '=' sign prefixing the expression so that the engine knows it is a formula. If it is not a String, that the '=' is optional. It will work both with and without it. Lets do something similar to what Excel does... if it is a literal, variable, etc, the user simply types/selects it. If it is a formula, user can start the expression with '=' (exactly like excel) or maybe use a wizard when we build one. Only thing is not there yet, but easy to implement as soon as we define how it will work is Date parsing. Regarding the "type" field in ActionSetField, I think it is a useful declarative information for the model and it is good to have it there, independent of the SuggestionCompletionEngine. I think we may not have the SCE always available everywhere to use and having the field type information makes it kind of "self-contained". So, what we do regarding Dates? Does JodaTime has anything useful we can use here? -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-647?page=comments#action_12361209 ] Edson Tirelli commented on JBRULES-647: --------------------------------------- Yes, best thing would be to support a specific Date type in the SCE. Will look into doing that... do you see any problem? Yes, everything else is covered from an engine perspective, IMO. -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-647?page=all ] Michael Neale resolved JBRULES-647. ----------------------------------- Fix Version/s: 4.0.0.MR3 Resolution: Done -- 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