hah, I simply went one step deeper and found that AbstractProcess does nothing if not just implementing the Process interface.
So I have just one more question: if I implement the process interface, is that enough to make the models usable within geotools? Andrea On Tue, Mar 16, 2010 at 6:31 AM, andrea antonello <andrea.antone...@gmail.com> wrote: > [...] >>> Following the new process implementation link [1], I have some >>> comment, to which it would be great to have some back-comment. >>> - the fact that I have to extend a class instead of implementing an >>> interface is a bit strange to me >> >> You can change it over to an interface if you like. > > Yeah, that would be a good starting point. > >>> - the fact that i am forced to create a factory class and even pass it to >>> my module constructor, also >> >> I think that was trying to not duplicate the description of input >> parameters? Can you see any other reason for the factory to be needed? >> I would prefer some kind of process info; that is avaialble from both >> the factory and the process itself. > > The factory is ok for me, it usually helps a lot, but I don't see the > point of forcing people to have one. > >>> the process api? With Sextante it went the way round, right? I guess >>> they didn't adapt to the process api. >> >> What does Sextante do to describe input parameters and produced results? > > No idea about what and how sextante does. > >>> Any comments are welcome, in the meanwhile I will look out to find if >>> the factory and process can be generated somehow from annotations. >> >> If we could annotate the parameters and results that would be perfect. > > That has also to be taken with care. > > I have quite some experience in migrating scientific models to > frameworks and interfaces by now. What I know for sure it that to be > maintainable, you have to take all the burden from the model writer, > i.e. possibly he should be able to do no work at all. > > The OMS approach is to simply keep the model design but annotate the > input and output parameters and also the method to be executed. That > makes a model ok for linking for OMS, but doesn't change one thing in > the nodel itself (ideally speaking). > > In my opinion the process api would be ok, if, to make my model > geotools processing compatible, I just had to implement the an > interface that asks me to implement the execute method: > public Map<String, Object> execute( Map<String, Object> input, > ProgressListener monitor ) > > It would then be easy for me to create a few lines of code that inside > the method execute my model. > > The problem is that I will have no time at all to work on the geotools > side of this, mainly because I would have to study the process api. > But if it would be possible to change the AbstractProcess to an > interface I would be willing to implement that for all the JGrass > models that I am extracting to be a standalone library in order to be > used by the geotools community. > Not sure if you guys see it usefull, in the case a factory is not present. > > Micheal (refering to your last email), could you help me on the > geotools side of life? > > Thanks for the discussion, I really want to implement the modules to > be usefull under wps and whatever. > > Cheers, > Andrea > > >> >> Jody >> > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
