PrimeFaces Converter CLI Desktop Application

rat-moonshine commented 5 years ago

ActionScript application to run on command-line to convert nsf-xml to PrimeFaces xHtml.

As an example: Converter --publish-to-primefaces source.xml target.xhtml

Working path/documentation: https://github.com/prominic/XHTMLConverterCLI

Following are the steps per priorities:

Create the application to accept command-line arguments and run without a GUI
Incorporate the converter library file with #428
Communicate with the library file and generate necessary xhtml file
Upon completion, quit (we may need to finalize a way to notify the caller when a process is completed)
Run on Windows, macOS in initial step
Run in headless-mode to a Linux server

Sub-goals:

[x] Create the application to accept command-line arguments and run without a GUI
[x] Test command-line injection on Windows, macOS, do some process, exit
[x] Integrate and process library file with #428
[ ] Run in headless-mode on Linux server

rat-moonshine commented 5 years ago

As there is no straight-forward way to notify the 'caller' when a conversion process is done, we can do something as we did for other such processes in past.

We can generate a given file upon conversion process completion and just before application exit, 'caller' can look for that named file existence and start its next queued task.

rat-moonshine commented 5 years ago

The compiled executable from Ant build on macOS, set as non-sandbox, so we can easily access paths anywhere in the file-system without getting into any restriction formalities.

piotrzarzycki21 commented 5 years ago

Couple of suggestions before we will to far for go back: 1. I see class FileUtils placed inside class actionScript. I think that implies some strict bound to specific language. Please move utils up to hierarchy of folders and remove actionscript folder. 2. Logging logic should be moved to separate class called Logger. Logger should be created at the beginning, create or use log file based on specific rules. - We have to agree on: 2.1. Log file should be created per each conversion 2.2. Log file should be created one per day where name of the log is date-log.txt (personally this is my favorite) 2.3. One log file 3. Instance of Logger class should expose simple methods called info, warrning, error. Those methods should print specific prefixes to give us immediate information what has happened when we look into the logs 4. We shouldn't print to the logs content of converted File

That's all for now ;)

rat-moonshine commented 5 years ago

I admit I wasn't sure how we wants the log file. Whether one log file and keep appending day-to-day process - will cause larger file and probably troublesome to read. Or, separate log files for each process - but that will also reason junk of files. So, this could be a thing to discuss on.

On second note, what you meant by implies strict bound to specific language by having 'actionScripts' named folder?

piotrzarzycki21 commented 5 years ago

On second note, what you meant by implies strict bound to specific language by having 'actionScripts' named folder?

It means that if you some day take that code and decide - Hey I wanted to rewrite to C#, but save folders structures - What will happen with actionScript folder ? You will have to change name etc. That's why I'm proposing to be a bit more agnostic than you get used to.

rat-moonshine commented 5 years ago

I have updated most of the messages as you wanted @piotrzarzycki21 , sorry for my poor English troubled you to understand efficiently.

piotrzarzycki21 commented 5 years ago

@rat-moonshine Thanks! @JoelProminic could you review this typical log file and correct our messages: @rat-moonshine point more log messages which are not in this typical file if needed in comments.

[info] Conversion started: 12/20/2018 10:20 AM
[info] Arguments (3):

--publish-to-primefaces
d:\somepoath\SomeView.xml
d:\somepoath\myview\SomeView.xhtml

[info] Source file read starts at: d:\somepoath\SomeView.xml
[info] Source file read succeed at: d:\somepoath\myview\SomeView.xhtml

[info] Starting the conversion..
[info] Conversion completed successfully
[info] Saving results of conversion to:  d:\somepoath\myview\SomeView.xhtml
[info] Save file completes at:  d:\somepoath\myview\SomeView.xhtml
[info] Application has been closed.

======================================

rat-moonshine commented 5 years ago

Relative path support added to the CLI application.

rat-moonshine commented 5 years ago

For bulk conversion process, following is how @JoelProminic envisioned:

Rather than run XHTMLConverterCLI for each file, I would prefer to have XHTMLConverterCLI support iterating over a directory of XML files:

The inputs would be the directory with XML files (i.e. visualeditor-src) and the output directory (src)

The converter should iterate over all of the XML files in first directory

The converter should output an XHTML file for each XML file, mirroring the directory structure.

Having that in the discussion, we agreed that the CLI application needs to support following command format as well:

XHTMLConverterCLI --publish-to-primefaces <source directory path> [optional <target directory path>]

User can omit the target directory path in this case, CLI application will generate XHTML files to the source directory folder only.

Additionally, user shall able to provide following parameter now, which will able to overwrite any existing XHTML application to the generating folder (default is false), this shall be available for file-conversion case, too:

--overwrite

However, I'm not sure the idea behind "mirroring the directory structure" from Joel's plan if he envisioned this to check through sub-folders also; But that is doable, too.

rat-moonshine commented 5 years ago

@atinprominic , now you can bulk-conversion XML files to xHTMLs, directory wise. For updated command format, please refer to https://github.com/prominic/XHTMLConverterCLI.

The conversion process for directory-wise conversion is recursive, and works including the sub-directories pointed as source. You can also have an option now to choose whether to overwrite (if any xHTML file already exists) at destination by using --overwrite command.

A typical log output will look like as follows after directory conversion (considering I have three different XML files available to the source directory when one also has trouble):

Command XHTMLConverterCLI.exe --publish-to-primefaces "C:/Users/User/Desktop/NewVisualEditorProject/visualeditor-src" --overwrite

Log output

[info] Conversion started: 1/10/2019 12:31:53 PM
[info] Started from: C:\Program Files (x86)\XHTMLConverterCLI
[info] Arguments (3):

--publish-to-primefaces
C:/Users/User/Desktop/NewVisualEditorProject/visualeditor-src
--overwrite

[info] Source file read starts at: C:\Users\User\Desktop\NewVisualEditorProject\visualeditor-src\main\webapp\ABCD.xml
[info] Source file read succeed.

[error] Error while XML conversion: TypeError: Error #1085
    at MethodInfo-66()
    at MethodInfo-23()

[info] Source file read starts at: C:\Users\User\Desktop\NewVisualEditorProject\visualeditor-src\main\webapp\NewVisualEditorProject.xml
[info] Source file read succeed.

[info] Starting the conversion..
[info] Conversion completed successfully
[info] Saving results of conversion to: C:\Users\User\Desktop\NewVisualEditorProject\visualeditor-src\main\webapp\NewVisualEditorProject.xhtml
[info] Save file completes at: C:\Users\User\Desktop\NewVisualEditorProject\visualeditor-src\main\webapp\NewVisualEditorProject.xhtml

[info] Source file read starts at: C:\Users\User\Desktop\NewVisualEditorProject\visualeditor-src\main\webapp.xml
[info] Source file read succeed.

[info] Starting the conversion..
[info] Conversion completed successfully
[info] Saving results of conversion to: C:\Users\User\Desktop\NewVisualEditorProject\visualeditor-src\main\webapp.xhtml
[info] Save file completes at: C:\Users\User\Desktop\NewVisualEditorProject\visualeditor-src\main\webapp.xhtml

[info] Saving file(s) completed at: C:\Users\User\Desktop\NewVisualEditorProject\visualeditor-src
[info] Application has been closed.
======================================

Please, let me know if you have any query on above execution ways.

rat-moonshine commented 5 years ago

@JoelProminic provided a Linux system recently, which has no GUI but Terminal, which should be fine for our tests. After many conceived thoughts on this, I finally able to give some tests on Linux using a macOS binary-build.

This didn't worked well, so far.

Having the .app file ported to the Linux system, tried by following command thrown an error:

# 'XHTMLConverterCLI.app/Contents/MacOS/XHTMLConverterCLI' --publish-to-primefaces NewVisualEditorProject.xml NewVisualEditorProject.xhtml
-bash: XHTMLConverterCLI.app/Contents/MacOS/XHTMLConverterCLI: cannot execute binary file

I tried to make sure that the executable has an executing permission, here is the output of the permission to the binary:

# ls -l XHTMLConverterCLI.app/Contents/MacOS/XHTMLConverterCLI 
-rwxr-xr-x 1 root root 33196 Nov 27  2017 XHTMLConverterCLI.app/Contents/MacOS/XHTMLConverterCLI

Reading further on this, it seems that a macOS binary may needs some more help to able to run this on a Linux platform. One interesting lead to this is Darling, but this do not support GUI but Terminal applications only. I'm not sure, but even the CLI app do not displays itself, it may have its GUI layer which may terminate during the process using Darling, but maybe we can give a try. The installation of the translation layer seems technical and needs Joel's help, if requires.

The other lead on this subject is AppImage; which runs converted .app file to .appImage file to run with its GUI on Linux, but this also seems technical to install.

Reading through different discussion one point attract my attention that is system linkage could be different between Linux and macOS even they are Unix. So we may or may not face any further system level problem during file-system access through the CLI app on Linux (however, it suppose to use bundled Flex SDK but file-system access anyway something primitive). Maybe, using through some translator like Darling or AppImage may help to overcome those unknown factors.

If anyone have anything in mind on test variations, let me know, I shall try to perform the test.

There is another option other than Wine probably is using OSX VM, but this may has licensing complexities.

piotrzarzycki21 commented 5 years ago

@rat-moonshine maybe we should use stuff which Justin recommended which allows launch such apps on Linux ? Have you considered that to install ?

rat-moonshine commented 5 years ago

The one option that Justin mentioned is using of CrossOver/Wine on Linux system and using in a VM environment. Such installation probably requires Joel's involvement. That is the only last option, though.

Having the existing AIR app, which anyway probably have a GUI layer within. The other links from Justin's email are fairly old, and discussed APIs are now obsolete. Since AIR/FP is no longer supports in Linux, having an AIR file is not a viable solution, either. The only way forward I think probably using the AIR runtime as provided by Adobe; In that regard perhaps a try to Darling may worth.

Beside that, any new 'virtual' type of thing, we need to decide on and therefore Joel can plan to have them installed on the Linux VM, at this moment I'm not sure how to access those 'virtual' environment in a non-GUI mode, though.

Moonshine-IDE / Moonshine-IDE

PrimeFaces Converter CLI Desktop Application #429