[rules-dev] quick design questions to mull over - regarding the repo

[Felipe Piccolini]

Hi Michael, yes we (at my work) used drools ina a large proyect in  
2005-2006. We did some things with
desicion tables, but never had access to CVS, no needed.

Send u files directly. Cya.

On 03-02-2007, at 20:33, Michael Neale wrote:

> Hi Felipe - can you send me the files directly? seem to be stripped  
> off.
>
> Transparent popups generally mean that the CSS for the popup isn't  
> sticking for some reason - should be easy to resolve with some  
> experimentation.
>
> Felipe - you were a contributor to drools 2.x right? as in, you had  
> CVS access etc?
>
> Michael (sans macbook pro :( )
>
> On 2/3/07, Felipe Piccolini <felipe.piccolini at bluesoft.cl> wrote:
> Hi Michael,
>
>    Yes, im using GWT 1.2.
>
>    And yes, all pop-up windows looks transparents and some frames  
> dont looks good.
>
>   Im using Firefox ( 2.0, but was the same with 1.5) and I will  
> check the CSS file.
>
>   Im using a MacBook Pro, OS X 1.4, Eclipse 3.2 (last release) and  
> JBossRules 3.0.5 and
> for the jbossrules-jbrms Im using the SVN sources with the JBRMS- 
> compiler and launcher
> modified (not much, just some paths).
>
>  I attached this 2 files so u can see them. If I get any results  
> messing with the CSS I will tell u.
>
>   Thanks.
>
>   Great work BTW!
>
> On 01-02-2007, at 21:28, Michael Neale wrote:
>
>> Hi Felipe - are you using the GWT bit?
>>
>> I assume you mean the popup windows look bad?
>>
>> GWT normally does a really good job cross browser - are you safari  
>> or firefox?
>> Basically, what you are saying sounds like it is the CSS screwing  
>> up - so if you track down the CSS that sets that up you may be  
>> able to change.
>> Also, with EditCSS in Firefox 1.5 or 2, you can browse and change  
>> the CSS onscreen in real time.
>>
>> Can you share what you have done? is it generic enough?
>>
>> Michael.
>>
>>
>> On 2/2/07, Felipe Piccolini <felipe.piccolini at bluesoft.cl> wrote:
>> Hi Michael,
>>
>>   Iv been following your work in the brms/repository very closely  
>> because Im working in something very similar by
>> my self for a project using JBossRules, and as I cant wait much  
>> longer I decided to use your work as a base to
>> put something on production until you guys do the "real-cool" thing.
>>
>>   About your questions, IMHO,
>> -Q1: I think dsl should be an attribute (as far as I know, you can  
>> put only 1 dsl expander on drl files) and
>> there should be only one reference to expand the rule sentences,  
>> if you have multiple dsl, then have mutiple drl (packages).
>> -Q2: I think object models (or business models to use as facts for  
>> your rules) should be assets, so u can organize your model/classes
>> not thinking in drools or any other framework, so you can extend  
>> your model or rules with just a pointer as a dependency, just as you
>> can put or remove jars from your classpath.
>>
>>  One thing I wanted to tell you for some time about drools-brms is  
>> that for some reason I dont know, the gwt ui looks awfull on mac  
>> (OS X),
>> I made it works changing some things on the .launcher and .shell  
>> files, but its looks like no modal window has a background, or  
>> complete
>> messed up.. can you check it out? or help me to guiding me what to  
>> check to see it right? Thanks.
>>
>>
>> On 01-02-2007, at 3:23, Michael Neale wrote:
>>
>>> BUT this also applies to the file structure for "packages" in a  
>>> file system/IDE (forget monolothic DRL for a moment - but instead  
>>> imagine a folder which is a rule package containing lots of rules).
>>>
>>> (in no particular order);
>>>
>>> Q1: Should DSL "language configurations" be stored as an "asset"  
>>> inside a package (ie a file, perhaps multiple ones of them?) - or  
>>> are they an attribute of a package?
>>> Q2: The object model: should this be stored as an attribute of a  
>>> package - or just another asset of which there can be muliple  
>>> ones uploaded (as a jar, for instance).
>>> This is needed for validation/tooling. Obviously in the IDE the  
>>> classes will be on the classpath, but in the repo they have to be  
>>> stored somewhere.
>>>
>>> Note versioning works well in all scenarios (subtle differences  
>>> between a package attribute and asset for versioning, but ignore  
>>> them for now).
>>>
>>> I have opinions, but wanted some discussion (attachment  
>>> screenshot shows the package managment screen).
>>> <Screenshot-JBoss Business Rules Management System .png>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> Felipe Piccolini M.
>> felipe.piccolini at bluesoft.cl
>>
>>
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> Felipe Piccolini M.
> felipe.piccolini at bluesoft.cl
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev


Felipe Piccolini M.
felipe.piccolini at bluesoft.cl




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070205/b2278215/attachment.html