Re: [Scaffoldhunter-devel] Issue while Implementing Data Import

[Shamshad A. <sha...@gm...>]

Hi Tills,

Thanks! I will learn the code and try to divide them into two part (Model
and Controller). It is also good to know that we shouldn't inherit
controller classes.

Thanks,
Shamshad


On Thu, Jul 17, 2014 at 9:36 PM, Till Schäfer <til...@tu...
> wrote:

> Hi,
>
>
> Am Donnerstag, 17. Juli 2014, 21:08:19 schrieb Shamshad Alam:
> > Hi everyone,
> >
> > I'm working on Command Line Interface and currently facing a problem
> while
> > implementing functionality to import dataset. There's already a class
> > 'edu.udo.scaffoldhunter.model.dataimport.Importer' available in SH to
> > manage import process. Importer class has runImport() method as an entry
> > point. But the runImport() method incorporates GUI and so I can't use
> this
> > method in CLI. However, some methods, such as
> > saveDatasetAndPropertyDefinitions(), which are defined with private
> > modifier in Importer class are useful in CLI too.
> >
> > At this point, I can either extends the Importer class, override
> > runImport() method and change accessibility of private methods which are
> > defined in Importer class to protected so that I can use them in extended
> > class or I can simply make the copy of whole code in Importer class and
> > then I'll modify it to met the requirement of CLI.
> >
> > In former case, which is an efficient solution, I will not modify any
> > internal code except methods' access modifier and will add some getter
> and
> > setter for the private field if it's required. Please let me know any
> issue
> > associated with such modification in any part of the existing code.
>
> Yes, Importer is a controller class. So it is the layer between the actual
> model an the GUI representation. However, it is uncommon to place such a
> class in the model package. Normally nothing in the model should reference
> anything GUI related. In my opinion this class should be moved in the
> corresponding gui package. If there are larger parts of gui independent
> functionality implemented in the controller class, they should be moved to
> a (new?) model class, such that they can be reused by the controller and
> your cli implementation.
>
> Regarding the method saveDatasetAndPropertyDefinition: i only see the
> ExceptionHandler as GUI dependent code (but i have not looked deeply in the
> code, so please check yourself again). In this case you can keep the
> unlocking in the controller and move the rest of the functionality to some
> model class.
>
> A last advice: please do not derive from the controller class for your cli
> code. This will destroy the model-view-controller design.
>
> Regards,
> Till
>
> >
> > Thanks,
> > Shamshad
> >
> >
> --
> Dipl.-Inf. Till Schäfer
> TU Dortmund University
> Chair 11 - Algorithm Engineering
> Otto-Hahn-Str. 14 / Room 237
> 44227 Dortmund, Germany
>
> e-mail: til...@cs...
> phone: +49(231)755-7706
> fax: +49(231)755-7740
> web: http://ls11-www.cs.uni-dortmund.de/staff/schaefer
> pgp:
> https://keyserver2.pgp.com/vkd/SubmitSearch.event?&&SearchCriteria=0xD84DED79
>



-- 
-Shamshad Alam

+91 9911631198

LinkedIn : in.linkedin.com/pub/shamshad-alam/58/939/70
GitHub: @shamshad-npti
Facbook: @shamshad.saralindia