I am doing some prototyping on the process api and JGrass processing
modules and I have to say I find the api quite invasive, given the
fact that it should lead people to bring their algorithms to be
compatible with geotools.

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
- the fact that i am forced to create a factory class and even pass it
to my module constructor, also

In fact it looks far to much work to me to make modules compatible
with all this.
Are there working examples of someone that migrated many modules to
the process api? With Sextante it went the way round, right? I guess
they didn't adapt to the process api.

Any comments are welcome, in the meanwhile I will look out to find if
the factory and process can be generated somehow from annotations.

Cheers,
Andrea


[1] http://docs.codehaus.org/display/GEOTDOC/Implementing+a+new+Process






On Sun, Mar 14, 2010 at 3:46 AM, Michael Bedward
<michael.bedw...@gmail.com> wrote:
> On 14 March 2010 13:01, Jody Garnett <jody.garn...@gmail.com> wrote:
>> Ah that is just it - not supposed to run the process in the event thread :-)
>>
>
> I'm proud of my continuing ability to discover most of the mistakes
> that one can make with GeoTools.
>
> I'm using SwingWorker in the example now (not committed yet) and it's
> quite neat because it keeps the multi-threading, task polling etc.
> from obscuring the point of the example.
>
> However, there's still a problem with the progress window not
> updating. I discovered that the RasterToVectorProcess never actually
> starts the progress monitor :-(  Fixed that but it still doesn't
> update properly, even though I give it a task that takes a few seconds
> to run.  I don't think I understand SubProgressListener.
>
> Michael
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>

------------------------------------------------------------------------------
Download Intel&#174; 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

Reply via email to