tag:robotlegs.tenderapp.com,2009-10-18:/discussions/suggestions/38-modulesignalcontextRobotlegs: Discussion 2013-04-28T10:35:17Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/32491242010-10-06T16:41:57Z2010-10-06T16:41:59ZModuleSignalContext<div><p>Guys, I'm still getting to grips with the Robotlegs framework, Signals and a heap of other stuff so please excuse my naivety/confusion.</p>
<p>I've looked at two independent sets of sub-classes for Context, Command, CommandMap, etc. One was the Modular Utility and the other was Signal (which gave me ModuleContext and SignalContext etc). Is there an easy way of combining the two or would that require an additional set of sub-classes? Or is the Modular Utility eventually going to make use of Signals instead of Events anyway?</p>
<p>Just thought it may be useful to combine them. What do you think?</p>
<p>Thanks</p></div>Toby Streettag:robotlegs.tenderapp.com,2009-10-18:Comment/32491242010-10-06T17:08:23Z2010-10-06T17:08:23ZModuleSignalContext<div><p>Here's what I do:</p>
<pre><code>public class ModuleContext extends SignalContext implements IModuleContext</code></pre>
<p>So compile from source and just hack that in.</p>
<p>We've talked about finding a way to make 'special contexts' like decorators, or to do it all through bootstrapping. No answers yet.</p>
<p>For now just hack away - you don't sound naive at all, it's a very valid combination and just not something we've found a neater solution to yet.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/32491242010-10-07T07:02:39Z2010-10-07T07:02:39ZModuleSignalContext<div><blockquote><p>Or is the Modular Utility eventually going to make use of Signals instead of Events anyway?</p></blockquote>
<p>Not likely. Stray's approach is what I would do as well.</p></div>Joel Hooks