That is not correct, code completion works for classes imported using .* and all classes in the same package as the one the rules are defined in as well. Had to do some magic there ;)
Kris ----- Original Message ----- From: Michael Neale To: [email protected] Sent: Tuesday, December 12, 2006 12:33 PM Subject: Re: [drools-user] 3.0.5 Eclipse IDE I think you have to import classes indivually (rather then with wildcard "*") to get assistance with completions for fields on it. On 12/10/06, Kris Verlaenen <[EMAIL PROTECTED]> wrote: Udah, If I understand it correctly, you're not getting any content assistant popups when editing rules? Could you give me a little more context information: Are your beans and rules defined in the same project? Are your bean classes imported in the rule file? Note that the content completion currently only works for classes that are defined in an import statement (or are in the same package as the rule file). Also note that it only works for imports that were saved (try saving the content of your file, are you still not getting the content assistance you would expect?). Are you getting any content assistent anywhere in the drl (for example, at the beginning of your file, you should get stuff like rule, function, etc.) Any errors in the error log? (Window -> Show view ... -> Other and in the package PDE runtime select the error log) If you could send me a rule file or maybe even better a zipped eclipse project that I can use to reproduce the error, that would be even better. Kris ----- Original Message ----- From: Uday Kamath To: [email protected] Sent: Friday, December 08, 2006 4:08 PM Subject: [drools-user] 3.0.5 Eclipse IDE Folks When I have my Java beans set in the Eclipse project and I am writing conditions for these I don't see the help window that document suggest that pops up in terms of showing all getter APIs or RULE conditions like AND, bracket etc. If I mistype properties of beans I get red error blocks but don't get the popup completion help like other Eclipse Java projects have. Is there some other plug-in required or some setup in eclipse required achieving this? Any help is appreciated Thanks -Uday -------------------------------------------------------------------------- From: Michael Neale [mailto:[EMAIL PROTECTED] Sent: Friday, December 08, 2006 8:57 AM To: [email protected] Subject: Re: [drools-user] What is a ShadowFact? - crash course yeah that is the downside of a dynamic proxy: the no arg constructor is needed. Otherwise we would have to do class load time weaving (nasty). On 12/7/06, Dirk Bergstrom < [EMAIL PROTECTED]> wrote: Edson Tirelli was heard to exclaim, On 12/07/06 04:18: > Would you please submit your error as a JIRA bug? My error was a long-winded complaint about the lack of a no-arg constructor for the object type. The "beans" I'm using don't really conform to the javabean standard. I can file a bug asking for a friendly error message, but otherwise the error was my fault. What I really want is the ability to turn off ShadowFacts on a per-class basis. For one of my classes they're doing nothing but consuming memory and CPU, with no benefit to me. Is there a JIRA for that, if not, I'll be happy to file one. > Dirk Bergstrom wrote: > >>I just finished a big refactoring/rewriting, fired up my application with the >>latest code from Trunk, and got a nasty error about shadow facts... >> >>Edson Tirelli was heard to exclaim, On 12/03/06 15:05: >> >> >>> But, if you have a pattern in your application that, lets say, always >>>retract objects from the working memory, changes its attributes and >>>assert the object again, :) then you don't need ShadowFacts... but I >>>think this use case is not a real use case... is it? :) >>> >>> >> >>Yes, it is. >> >>I am doing almost exactly that. In my case, I have a hundred or so objects of a >>specific type that I cycle through the WM with assert/fireAllRules/retract (and >>another few hundred objects of two different types that stay in the WM all the >>time). I do this assert/retract dance because there is no value in having them >>in the memory once I've checked their compliance with the rules -- I need to >>update them with current data before running the rules again. >> >>So creating a ShadowFact for each one after I retract it does nothing for me. >>Well, except for crashing my system. >> >> >> >>>>>>Edson Tirelli wrote: >>>>>> >>>>>> >>>>>>> Regarding the feature, right now it is mandatory, but I was >>>>>>>talking to Mark to make it optional. Unfortunally Shadow Facts are >>>>>>>one of those necessary evils. If you ever change a fact attribute >>>>>>>in your network, that fact needs a shadow fact. So, unless you use >>>>>>>the engine simply as a discrimination network, you will need them, >>>>>>>but the idea is to make them optional and better yet on an object >>>>>>>type basis, in a way that users can turn it ON only for those types >>>>>>>where it is really needed. >>>>>>> >>>>>>> >> >>This would be very useful for me. I have three types, two of which stay in the >>WM, and get changed (I have PropertyChangeListeners on them), and one which is >>asserted and retracted. I'd like to turn off shadow facts for the third type. >> >> >> > > -- Dirk Bergstrom [EMAIL PROTECTED] _____________________________________________ Juniper Networks Inc., Computer Geek Tel: 408.745.3182 Fax: 408.745.8905 --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm for more information. Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
