incubator-droids-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eugen Paraschiv (JIRA)" <>
Subject [jira] Commented: (DROIDS-119) Allow SaveHandler to decide the location (directory) where it saves the content
Date Wed, 02 Mar 2011 21:33:36 GMT


Eugen Paraschiv commented on DROIDS-119:

First off, cool patch, very similar to what I have locally. 
One question about the strategy setter - would it be easier to use constructor injection instead
of setter injection for the strategy? I'm suggesting this for two reasons - first, it would
clarify the API, and second - usually I think of setter injection as a mechanism used for
optional collaborators and constructor injection for required collaborators without which
the object is inconsistent (hence the javadoc - "Before using make sure you have set the SaveContentHandlerStrategy").

Thinking about the flexibility issue related to this decision, the SaveHandler is lightweight
enough so that we don't need to worry about any performance hit in instantiating a new one
if needed. What is more, the strategy should indeed have the same lifetime as the SaveHandler
(meaning you instantiate them once and do not reuse them for another job). 
So, in conclusion, we can either choose not to introduce the complexity of mutability and
simply use constructor injection and no setter (my suggestion), or both. 
Hope this makes sense. 

> Allow SaveHandler to decide the location (directory) where it saves the content
> -------------------------------------------------------------------------------
>                 Key: DROIDS-119
>                 URL:
>             Project: Droids
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 0.0.2
>            Reporter: Eugen Paraschiv
>             Fix For: 0.0.2
>         Attachments: DROIDS-119-2.patch, droids119.patch
> At this point, SaveHandler doesn't provide a way to configure where the content is saved,
other than a single directory path, which clearly lacks flexibility. 
> A common scenario is to crawl a site and configure where the content gets saved based
on some particular logic, as opposed to having all content (which may be a lot) saved in one
single directory. 
> For example, I may want to save 
> into directory a category1 directory and 
> into directory a category2 directory. 

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message