Activity report on

  *[JIRA] Improvement SKER4404 - Automatically assign config settings in 
readSearchConfiguration where there is a setter*

  Scarab Link: http://sesat.no/scarab/issues/id/SKER4404
  Module: Sesat> Kernel


  Activity generated by Mick Semb Wever ([EMAIL PROTECTED]) Håvard Frøiland 
([EMAIL PROTECTED]) at 08/19/2008 12:36

  *Reasons for the changes*


  *Comments*
  - By Håvard Frøiland - 08/19/2008 12:36 ---
  "Removing before & after in r6766"

  - By Mick Semb Wever - 08/19/2008 12:37 ---
  "Great to hear about (a). But check it out, i'm only presuming Introspection 
(with a little help from BeanInfos) will satisfactorily replace the current 
code.

Re (b), i think it's important that the delegation order remains 
SearchModeFactory->SearchConfiguration implementation(->deserialisation helper 
[functor]).
SearchModeFactory should, ideally, only be responsible for determining the 
correct deserialisation approach (W3C, jdbc, ejb3, etc) and not have any direct 
knowledge of the deserialisation helper for any given deserialisation approach.

Re (c), i think it's better that readBefore.. & readAfter.. methods remain 
encapsulated. This means they cannot be defined in an interface. Since 
readSearchConfiguration is the main entry point into any SearchConfiguration's 
deserialisation it makes sense that it is public. Since the 
pseudo-introspection code forms a decent chunk of code it warrants to come out 
of AbstractSearchConfiguration (where it is tied to one particular 
implementation of SearchConfiguration) and into a deserialisation helper class 
(meeting the functor pattern). If it is within such a deserialisation helper 
class then it can be delegated to from alternative SearchConfiguration 
implementations and not just those extending AbstractSearchConfiguration. This 
does bring to light that the readSearchConfiguration method should be moved out 
of SearchConfiguration interface and into a 
SearchConfigurationW3cDeserialisation interface. "
_______________________________________________
Kernel-issues mailing list
[email protected]
http://sesat.no/mailman/listinfo/kernel-issues

Svar til