Outputting Response When Running Dev Tasks
74 views
Skip to first unread message
Matthew Bonner
Dec 12, 2014, 6:17:08 AM12/12/14
to silverst...@googlegroups.com
When running any task under the dev/tasks feature, unless I'm doing something wrong, it seems that the majority of people just use echo to output content. This seems a bit prehistoric to me and I was wondering:
1) If this is actually the right way to output content
2) If this is the currently accepted way of working, would it not be better to have a response class and a response buffer class that allows a more complex flow of output
3) The task itself outputs content which is annoying because if you want to force a file download you have to clear the buffer, so surely it should be down to the developer on what is output rather than assuming we want a title output to start with
1) If this is actually the right way to output content
2) If this is the currently accepted way of working, would it not be better to have a response class and a response buffer class that allows a more complex flow of output
3) The task itself outputs content which is annoying because if you want to force a file download you have to clear the buffer, so surely it should be down to the developer on what is output rather than assuming we want a title output to start with
wi...@willmorgan.co.uk
Dec 12, 2014, 10:06:20 AM12/12/14
to silverst...@googlegroups.com
Currently it's down to you. There's nothing "prehistoric" about it unless you have a lot of work to do with the output.
In the future for core, I would like to implement the proper PSR logging standard and use one of the nice CLI output components available on Packagist.
In my own opinion (definitely not reflective of the rest of the core team), I'd like to see the CLI features for SilverStripe redefined as a module. I don't feel that heavyweight task running is something that SS needs to reinvent, and it's not really part of its core USP.
Will.
Matthew Bonner
Dec 15, 2014, 5:55:07 AM12/15/14
to silverst...@googlegroups.com
I'm not a big fan of leaving things down to a developer because like Microsoft I believe you should never assume a developer will do something the right way. I also believe that there should only ever be 1 echo statement in the whole of a framework, which is the bridge between the framework and PHP.
I'd like to see quite a few things put into modules and shipped with the core package, so that you have the option to remove them if you want, but they are there for you when you first download the package. This is because we use tasks quite heavily in terms of SilverStripe upgrades and deploying new themes, and I suspect others do too, so I feel it is fundamental to have such a system available upon downloading the SilverStripe package. However, as I could go into great detail here it is probably best off discussed in a new topic.
I've decided that I'm going to use the MVC pattern and create a new module based on the way the current dev/tasks work but by using the MVC I'll have access to views, fields and the response class.
I'd like to see quite a few things put into modules and shipped with the core package, so that you have the option to remove them if you want, but they are there for you when you first download the package. This is because we use tasks quite heavily in terms of SilverStripe upgrades and deploying new themes, and I suspect others do too, so I feel it is fundamental to have such a system available upon downloading the SilverStripe package. However, as I could go into great detail here it is probably best off discussed in a new topic.
I've decided that I'm going to use the MVC pattern and create a new module based on the way the current dev/tasks work but by using the MVC I'll have access to views, fields and the response class.
Matthew Bonner
Jan 21, 2015, 11:07:12 AM1/21/15
to silverst...@googlegroups.com
It has been a while but I've worked out a better solution for this so here is my RFC, which I will use to write the functionality.
A LoggableTask which extends Task as described as follows.
A task can be run on either the command line or in the browser, therefore different types of output are required. In order to fulfil this purpose, a new task logging system can be introduced.
The task logging system should allow for one or more logging interfaces and should be configurable.
By default, when running the task in a web browser, a HttpLogger will be automatically added to the list of loggers. When running in the command line, a CommandLineLogger will be added.
The logging can also be configured on the command line by using parameters like so:
php framework/cli-script.php dev/tasks/MigrateSiteTreePages "logger=MyCustomLogger" "logger=FileLogger"
You can also configure the loggers in the browser like so:
/dev/tasks/MigrateSiteTreePages?logger[]=MyCustomLogger&logger[]=FileLogger
The logger will also be configurable in terms of verbosity. This can also be configured by passing parameters or by appending the URL with query string arguments.
When logging messages, the level of importance can be specified. The options for the levels are: high, normal, low
The verbosity levels are:
detailed, which displays all errors, warnings, messages (low, medium and high importance)
normal, which displays errors, warnings and messages with a medium or high importance
minimal, which displays errors, warnings and messages with a high importance
quiet, which displays errors and warnings
A new event system will be introduced, which will allow the task to raise events on various situations, such as:
task started
task message
task warning
task error
task finished
These events are raised either automatically by the LoggableTask, or programmed by the developer writing the task. For instance, task started, task finished, task warning and task error events will be raised automatically.
Each logger will be able to define what happens when each of these events is raised.
The LoggableTask will remove the default output, the task title, which SilverStripe adds, as it may not be desirable to output such information. This will be done by clearing the output buffer.
The LoggableTask, and accompanying classes, will be built as a module, and to use, your task should extend LoggableTask opposed to Task.
I welcome any questions or suggestions.
A LoggableTask which extends Task as described as follows.
A task can be run on either the command line or in the browser, therefore different types of output are required. In order to fulfil this purpose, a new task logging system can be introduced.
The task logging system should allow for one or more logging interfaces and should be configurable.
By default, when running the task in a web browser, a HttpLogger will be automatically added to the list of loggers. When running in the command line, a CommandLineLogger will be added.
The logging can also be configured on the command line by using parameters like so:
php framework/cli-script.php dev/tasks/MigrateSiteTreePages "logger=MyCustomLogger" "logger=FileLogger"
You can also configure the loggers in the browser like so:
/dev/tasks/MigrateSiteTreePages?logger[]=MyCustomLogger&logger[]=FileLogger
The logger will also be configurable in terms of verbosity. This can also be configured by passing parameters or by appending the URL with query string arguments.
When logging messages, the level of importance can be specified. The options for the levels are: high, normal, low
The verbosity levels are:
detailed, which displays all errors, warnings, messages (low, medium and high importance)
normal, which displays errors, warnings and messages with a medium or high importance
minimal, which displays errors, warnings and messages with a high importance
quiet, which displays errors and warnings
A new event system will be introduced, which will allow the task to raise events on various situations, such as:
task started
task message
task warning
task error
task finished
These events are raised either automatically by the LoggableTask, or programmed by the developer writing the task. For instance, task started, task finished, task warning and task error events will be raised automatically.
Each logger will be able to define what happens when each of these events is raised.
The LoggableTask will remove the default output, the task title, which SilverStripe adds, as it may not be desirable to output such information. This will be done by clearing the output buffer.
The LoggableTask, and accompanying classes, will be built as a module, and to use, your task should extend LoggableTask opposed to Task.
I welcome any questions or suggestions.
Reply all
Reply to author
Forward
0 new messages