This items requires the reduce framework.
The tree command will be known as draw and is a new sub-command on jay; the default behaviour of the tree command directs its output to the console. Rendering to the console necessitates the concept of 'owner-draw' (in the parlance of legacy MFC/ActiveX tech of old). This means whatever view is in force is disabled and all output is controlled by sub command, not the configured view. An alternative would be just to introduce a simplified tree view, which works in a similar way to the linear view, but only draws the tree branches and the node names, without the extra bells and whistles. To avoid code duplication with the linear view, a refactoring would be required to ensure that common functionality is extracted out so that it can be shared.
To generate a file, like xml, you have another flag on draw command that sends the output to file. The forest will probably need an output file system to enable this. Theoretically draw command output file system should be outside the navigation tree, so a check needs to be made upfront. For the draw command, the type of the accumulator will the XML document or the XML generator.
Need a new section in the application config to capture file/directory element names. Need to check if the current config has sub-command level configuration. If its not currently there, we should set this up, as there will be the requirement for sub-command level of configuration for future commands.
Note: usually there is no point in replicating the functionality of an existing command. But this version will be seen as an enhancement as the standard tree command uses long element names to represent files and directories. We can improve this by defaulting the element names to 'f' and 'd', with the facility to override these. We'll also be able to add different attributes as required. One interesting property would be to create a size property represent the size of that item on disk. The resultant file could be used by a GUI application to represent disk file usage, without having to compute this itself; ie useful as a cache on directory structure that do not change often so the cached version could be adequate for this purpose.
Also, if this tree command is defined, it proves that the navigation framework can implement reduce type operations.
An alternative to rendering our own tree, we can just reuse the tree that charm's lipgloss/bubbles provides. We could just perform a full navigation of the directory tree in the same way the the preview operation does for PeerInfo for the walk command. The intention here would be to create an internal full representation of the directory tree, populate the internal tree representation with any decorations that we need, this would probably include the peer info. Using this approach would relieve us from implementing functionality that has already been defined by charm. This is now the preferred approach as it means we don't have to refactor existing code to avoid code duplication. Note that probably only applies to rendering to the console, unless the charm tree allow serialisation to a file. If the output format is simply text, then we can probably render charm's tree output straight to file. If another format is required, eg XML, then will we implement this is out own custom way, providing support for other formats like JSON and yaml.
Accumulator needs to be made available to ascend/descend.
This items requires the reduce framework.
The tree command will be known as draw and is a new sub-command on jay; the default behaviour of the tree command directs its output to the console. Rendering to the console necessitates the concept of 'owner-draw' (in the parlance of legacy MFC/ActiveX tech of old). This means whatever view is in force is disabled and all output is controlled by sub command, not the configured view. An alternative would be just to introduce a simplified tree view, which works in a similar way to the linear view, but only draws the tree branches and the node names, without the extra bells and whistles. To avoid code duplication with the linear view, a refactoring would be required to ensure that common functionality is extracted out so that it can be shared.
To generate a file, like xml, you have another flag on draw command that sends the output to file. The forest will probably need an output file system to enable this. Theoretically draw command output file system should be outside the navigation tree, so a check needs to be made upfront. For the draw command, the type of the accumulator will the XML document or the XML generator.
Need a new section in the application config to capture file/directory element names. Need to check if the current config has sub-command level configuration. If its not currently there, we should set this up, as there will be the requirement for sub-command level of configuration for future commands.
Note: usually there is no point in replicating the functionality of an existing command. But this version will be seen as an enhancement as the standard tree command uses long element names to represent files and directories. We can improve this by defaulting the element names to 'f' and 'd', with the facility to override these. We'll also be able to add different attributes as required. One interesting property would be to create a size property represent the size of that item on disk. The resultant file could be used by a GUI application to represent disk file usage, without having to compute this itself; ie useful as a cache on directory structure that do not change often so the cached version could be adequate for this purpose.
Also, if this tree command is defined, it proves that the navigation framework can implement reduce type operations.
An alternative to rendering our own tree, we can just reuse the tree that charm's lipgloss/bubbles provides. We could just perform a full navigation of the directory tree in the same way the the preview operation does for PeerInfo for the walk command. The intention here would be to create an internal full representation of the directory tree, populate the internal tree representation with any decorations that we need, this would probably include the peer info. Using this approach would relieve us from implementing functionality that has already been defined by charm. This is now the preferred approach as it means we don't have to refactor existing code to avoid code duplication. Note that probably only applies to rendering to the console, unless the charm tree allow serialisation to a file. If the output format is simply text, then we can probably render charm's tree output straight to file. If another format is required, eg XML, then will we implement this is out own custom way, providing support for other formats like JSON and yaml.
Accumulator needs to be made available to ascend/descend.