#542: WebSearch - all-containing perform_request_search() makes it very hard to
re-use search engine
------------------------+----------------------
Reporter: rchyla | Owner: rchyla
Type: defect | Status: assigned
Priority: major | Milestone:
Component: WebSearch | Version:
Resolution: | Keywords: refactor
------------------------+----------------------
Comment (by jblayloc):
Replying to [comment:15 rchyla]:
> - note (kwargs, one=None, !**kwargs) is a syntactically incorrect in
Python
> - I thought it is better to name it !**rest (as that means - 'we are not
using it, it is there to deal with what we have to deal with....')
In this case may I suggest !**dummy?
> > * Method visibility - You've created a lot of utility methods. When I
suggested before that they should be inner functions of p_r_s, you said
that solr needed access to them. I wonder if solr needs access to all of
them? Those that it does, I think should be documented
> solr is using search, sorting, filtering, ranking and display (but only
for citation summaries); this means it is using 3/5 of the new functions
are created. That is not insignificant.
No indeed.
> > as being part of the API for solr connectivity and otherwise made
first-class components. Those utility methods that solr doesn't call I
still think should be hidden.
> and what about being private? (in python sense)
Well, if they're inner methods then naming them using the underscore
convention is a point of style on which my own practice tends to vary -
and not for any good reason but just because I can't make up my mind. My
usual inclination is to not follow the underscore convention, because I
think it looks nicer and because I think that making inner methods inner
is sufficient to communicate that they're special snowflakes that oughtn't
be messed with. Sometimes I doubt my opinions though.
> > * In websearch_templates you introduce a checkbox for solr. Is this a
developer comfort feature? I don't think we would want this in
production.
> sure, but if you were testing solr you would find it very useful ;)
Indeed I'm sure I would. :-)
> which proves my point when I resisted writing unittests for something
that was half-cooked, as a code, it proves the point where the refactoring
goes and it actually *works*, but I never considered it finished
I typed a whole screed here about test-first philosophy, but will spare
you and the rest of the community. Suffice it to say that I think we
should talk about testing more when next we see each other. :)
HTH. Good luck.
Joe
--
Ticket URL: <http://invenio-software.org/ticket/542#comment:16>
Invenio <http://invenio-software.org>
