Re: [Repast-developer] More thoughts on Controllers

[Mark R. D. <mdi...@la...>]

Yes, in relation to jelly as an example the following becomes apparent 
when dealing with Controllers and the initSim() method idea.

Here is an example of a jelly script to start a simple GUI based 
Controller Simulation.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="jelly:org.mrd.jelly.repast.RepastTagLibrary">

       <controller
            var="cntrl_x"
            class="uchicago.src.sim.engine.Controller"
        />

        <model
            var="model_x"
            class="your.project.Model"
            controller="${cntrl_x}">

            <setProperties object="${model_x}"
                 someModelParameter1="x.x"
                 someModelParameter2="y.y"
                 someModelParameterN="z.z"
             />

         </model>

         ${cntrl_x.display()}

</project>

The real point of interest is in ${cntrl_x.display()}. If this were an 
example using BatchController, I'd have to call ${cntrl_x.begin()}.
This is an example of using "Jexl" script for picking up an object in 
the JellyContext and calling a method on it (or also passing an instance 
of it onto another object.). While I like Jexl script for doing things, 
I'm trying to minimize my use of it for tasks like this and rely on the 
tag library to support it in the Java Implementation of the Repast 
<project>, <controller> and <model> tags. This is to keep the file as 
much like a Configuration/Properties file as possible and less like a 
program script.

Right now, I could write code into the </project> end tag such that the 
appropriate method (begin or display) was called to startup the 
simulation. However, this would not be very flexible in relation to the 
fact that any Implementation of "IController" could be placed into the 
controller tag (even custom implementations). The extensibility gets 
lost as soon as one starts conditionally casting or instantiating 
directly into the extended classes to get at methods only available in 
those classes.

So having a common "initSim" method for "starting up" all Controllers 
would make the code behind this </project> tag simpler and much cleaner 
in the long run. Plus it would fit well with the extensible 
functionality employed in the <controller> tag.

For SimInit, it could make the code a little simpler. It could even be 
the case that instead of a boolean option to pickup and use either the 
Controller or the BatchController one could provide an IController based 
class name and that class could be instantiated via reflection. Thus 
providing the same extensibility mechanisms into SimInit as I'm making 
available in my Repast JellyTagLibrary.

It could even then be the case that I could actually use such a modified 
SimInit behind the project tag to startup the simulation thread instead 
of my own custom code. Then the Tag Libraries I'm writing would really 
just be wrappers around already existing Repast functionality. If some 
other really cool environment other than Jelly came down the pipeline, 
then that same functionality could be made available in that environment 
as well.

Also, if this modified SimInit existed I could easily replicate all the 
demos to startup and be parameterized via Jelly scripts to show as 
examples of the Jelly strategy. Once I'm ready to present this to the 
group I can post the entire project to the list to experiment with and 
get opinions of.

For DataRecorder, it would make the class a little less dependent on the 
implementation of the BatchController and more dependent on the 
isBatch() method for determining behavior. I think the cast to 
BatchController here is not really required now that IController 
supports the addSimEventListener(this) and isBatch() methods.


     if (isBatch) {
       BatchController control = (BatchController)model.getController();
       control.addSimEventListener(this);
       dynParams = dfHeader.getDynParamMethod();

       Enumeration e = dynParams.keys();
       while (e.hasMoreElements()) {
         String key = (String)e.nextElement();
         //System.out.println(key);
         DataSource s = new ObjectDataSource(key, model,
					    (Method)dynParams.get(key));
         sources.add(s);
         data.addToHeader(key);
       }


While, I don't think your development of the IController interface 
probably should be solely determined by my suggestions here, I am glad 
to have a good "layer" of criticism to factor out any of the poorer 
suggestions I may make. Thanks for entertaining my ideas. I also think 
it would be good to go back and look over the refactoring ideas we threw 
around before the 2.0 release an make sure we are interested in those still.

-Mark


Nick Collier wrote:
> Hi,
> 
> I agree with you on both the issue of adding isGui() and initSim() to
> IController. In fact, my original IController had an isGui() in it. I
> forget now why I dropped it.
> 
> However, I can see how something like isGui() or isBatch() can be used
> polymorphically in DataRecorder. It receives an IController from the
> SimModel.getController() and then behaves appropriately depending on the
> result of isBatch(). What's less clear to me is how the polymorphic
> initialization and running of a simulation would work. As it stands now,
> SimInit creates either a BatchController or a Controller. It could
> certainly treat these uniformly as an instance of an IController, but
> considering that it needs to create either one depending on a command
> line switch, there is little (although certainly something) to be gained
> here. All this is not a criticism of adding something like initSim() but
> rather a request for information on the benefits / the context of
> polymorphic initialization. Maybe you've described this before in the
> context of Jelly, but I don't recall.
> 
> Nick
> 
> On Mon, 2002-12-30 at 14:01, Mark R. Diggory wrote:
> 
>>I took ThinController and used it as an example, I also added the 
>>begin() method from BatchController to it (name actually called 
>>initSim()). This is because the begin method provides a transition point 
>>wherer the creation of the new thread occurs, making ThinController do 
>>alittle bit of thread startup management as well.
>>
>>
>>I'm concerned about the multiple methods used to "initialize" the 
>>Controller under different IController implementations.
>>
>>1.) display() is used in the GUI Controller
>>2.) begin() is used in the BatchController
>>3.) nothing is really available in the ThinController
>>
>>Would it be good to also have an "initialize()" style method that could 
>>be used to consolidate these different methods in IController?
>>
>>
>>public void initSim(){
>>	
>>	1.) in Controller this calls "display()"
>>
>>	2.) in BatchController this calls "begin()"
>>
>>	3.) a simple example in ThinController is attached.
>>
>>}
>>
>>
>>I guess its a question of whether or not the setup should be done in a 
>>"Caller/Wrapper" or be done inside the IController. In this example it 
>>makes life easier in the caller. Given that BaseController is completely 
>>implemented in an asynchronous fashion, it is my opinion that 
>>Implementations that extend it should have at least some simple startup 
>>init like in display() (Controller) and begin() (BatchController).
>>
>>Maybe if non-asynchronous control of the sim were wanted (simulation 
>>runs in the same thread as the controller). Then thread management 
>>issues would be managed in the Caller of the Controller, in which case, 
>>the controller would be very simplified. Maybe one would have 
>>AsynchronousBaseController and NonAsynchronousBaseController 
>>implementations with
>>
>>Controller extends AsynchronousBaseController
>>BatchController extends AsynchronousBaseController
>>ThinController extends AsynchronousBaseController
>>
>>and
>>
>>SimpleController extends NonAsynchronousBaseController
>>
>>this example would move threading issues completely out into the Caller.
>>
>>These are just ideas, I'm sure of my opinion an this stuff, I'm not sure 
>>  how valuable something like SimpleController would really be. It might 
>>be usefull in situations where Parallel Processing is managed externally 
>>to the Repast Sim, like in massively parallel supercomputer systems.
>>
>>Primarily, I think it would at least be wise to have something like 
>>initSim() in the IController.
>>
>>-Mark
>>
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>Repast-developer mailing list
>>Rep...@li...
>>https://lists.sourceforge.net/lists/listinfo/repast-developer