DO NOT REPLY [Bug 19132] New: - Better encapsulation for CommandLineOptions

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19132>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19132

Better encapsulation for CommandLineOptions

           Summary: Better encapsulation for CommandLineOptions
           Product: Fop
           Version: 1.0dev
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Minor
          Priority: Other
         Component: general
        AssignedTo: fop-dev@xml.apache.org
        ReportedBy: glenmazza@yahoo.com


It currently works fine, but moving forward in 1.0, the CommandLineOptions 
class should probably be better encapsulated:

(1) CLO is currently involved in creating InputHandlers, Starter objects and 
determining Driver Renderers but these actions are outside the usual scope for 
a command-line parsing object.  
  
(2) The predefined constants for the (correctly private) inputmode and 
outputmode member variables are being declared PRIVATE instead of PUBLIC. This 
limits the ability of CLO to communicate with objects legitimately requesting 
this data via inputmode/outputmode's accessor functions.

For (1) above, the three classes getInputHandler(), getRenderer(), and 
getStarter() are the functions that appear outside of scope.  I think the more 
proper design would be to have the CLO just supply the parsed options it knows 
of to classes requesting that information, and in turn have those classes use 
the business logic contained within those functions to determine which object 
to create.

For these three functions in CLO:

-- CLO.getInputHandler() is called only once, within CommandLineStarter.  It 
may be better to have CommandLineStarter call CLO.getInputMode() instead and 
subsequently use appropriate business logic to determine which InputHandler to 
create.  

-- CLO.getStarter() is also only called once, within class Fop.  Likewise, the 
Fop class should call getOutputMode() instead, and after getting a response, 
determine the proper Starter object to create.  

-- CLO.getRenderer() is called once within CommandLineStarter.  This function 
places the burden on the CLO to determine the Renderer that the Driver class 
should use, based on the Output Mode parsed out by the CLO.  But this 
determination should be for the Driver class to make, not the command-line 
parser.  The Driver class appears to need a setRendererbyOutputMode() function 
for CommandLineStarter to call:

so, in CommandLineStarter (line 99), perhaps move from
driver.setRenderer(commandLineOptions.getRenderer());
to something like
driver.setRendererByOutputMode(commandLineOptions.getOutputMode());

which essentially moves CLO's getRenderer functionality to the Driver class, 
and (properly, I think) removes all references to the Driver class within the 
CLO.

As for (2) above:  the predefined constants for the inputmode and outputmode 
variables need to be externally viewable.  FO_INPUT, XSLT_INPUT, PDF_OUTPUT, 
AWT_OUTPUT, etc., need to be made public so classes accessing CLO's 
inputmode/outputmode information via their accessor functions can work 
meaningfully with these two fields.

Glen

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org