Prepare for CLI usage

[fadookie]

This is a suggestion for how to clean up the implementation to allow the creation of a command-line interface.

Changes would need to be made so that it can handle loading local files. I don't know if that's possible in all cases using the current URL-load method, it certainly didn't work when I tried to run it under the CLI:

@$xml->open('zip://'.$odt_file.'#content.xml')

I'm not sure what the proper replacement for this would be, you might need to depend on zlib or something. Or maybe there's a way to get this working with local files somehow?

Also, right now, odt2html returns errors wrapped in HTML tags for easy presentation. In order for the caller to understand if this is an error or successful HTML output you'd need to structure the call a bit differently. Some alternatives I could think of are:

1. Make it return an object/array with 'error' and 'result' members that can be inspected by the caller.
2. Make it return an integer representing an error code (or a boolean representing succeed/fail) and pass the HTML output as a string parameter by reference.
3. Keep the API the same but throw an exception on error.

And I think the caller should be responsible for presenting errors... if they need to be wrapped in HTML that can be done by file_upload.php.

Thanks for considering this!

[lovasoa]

I agree about html errors.

But I think the "zip://" thing is handled by the PHP Zip extension, which is not "web-specific". Are there good reasons we should rely on something else ?

Le 6 août 2015 21:50:57 GMT+02:00, Eliot Lash notifications@github.com a écrit :

This is a suggestion for how to clean up the implementation to allow
the creation of a command-line interface.

Changes would need to be made so that it can handle loading local
files. I don't know if that's possible in all cases using the current
URL-load method, it certainly didn't work when I tried to run it under
the CLI:

@$xml->open('zip://'.$odt_file.'#content.xml')

I'm not sure what the proper replacement for this would be, you might
need to depend on zlib or something. Or maybe there's a way to get this
working with local files somehow?

Also, right now, odt2html returns errors wrapped in HTML tags for easy
presentation. In order for the caller to understand if this is an error
or successful HTML output you'd need to structure the call a bit
differently. Some alternatives I could think of are:

1. Make it return an object/array with 'error' and 'result' members
   that can be inspected by the caller.
2. Make it return an integer representing an error code (or a boolean
   representing succeed/fail) and pass the HTML output as a string
   parameter by reference.
3. Keep the API the same but throw an exception on error.

And I think the caller should be responsible for presenting errors...
if they need to be wrapped in HTML that can be done by file_upload.php.

---

Reply to this email directly or view it on GitHub:
#13

[fadookie]

@lovasoa Perhaps what's needed then is just more path cleaning. When I supplied odt2html with an absolute path, it said it was unable to read the file, so I figured the URL construct wasn't working. But i didn't take much time to investigate. You can try yourself with the snippet below:

<?php
//ophir_cli.php
require('ophir.php');
echo odt2html($argv[1]);

And run like so:

php ophir_cli.php '/PATH/TO/file.odt'

[fadookie]

Oh also, since I heard you're doing an OOP rewrite, it would also be good to make the config an array that gets passed to the ophir object instead of a global variable.