The hardware and bandwidth for this mirror is donated by dogado GmbH, the Webhosting and Full Service-Cloud Provider. Check out our Wordpress Tutorial.
If you wish to report a bug, or if you are interested in having us mirror your free-software or open-source project, please feel free to contact us at mirror[@]dogado.de.

The event cycle in fiery

fiery is using an event-based model to allow you to program the logic. During the life cycle of an app a range of different events will be triggered and it is possible to add event handlers to these using the on() method. An event handler is simply a function that will get called every time an event is fired. Apart from the predefined life cycle events it is also possible to trigger custom events using the trigger() method. Manual triggering of life cycle events is not allowed.

Life cycle Events

Following is a list of all life cycle events. These cannot be triggered manually, but is fired as part of the normal lifetime of a fiery server:

Custom Events

Apart from the predefined events, it is also possible to trigger and listen to custom events. The syntax is as follows:

# Add a handler to the 'new-event' event
id <- app$on('new-event', function() {
  message('Event fired')
})

# Trigger the event
app$trigger('new-event')

# Remove the handler
app$off(id)

Additional parameters passed on to the trigger() method will be passed on to the handler. There is no limit to the number of handlers that can be attached to custom events. When an event is triggered they will simply be called in the order they have been added. Triggering a non-existing event is not an error, so plugins are free to fire off events without worrying about whether handlers have been added.

Triggering Events Externally:

If a fiery server is running in blocking mode it is not possible to communicate with it using the trigger() method (though these can be fired by other callbacks in the server logic). Instead it is possible to assign a directory to look in for event trigger instructions. The trigger directory is set using the trigger_dir field, e.g.:

app$trigger_dir <- '/some/path/to/dir/'

Events are triggered by placing an rds file named after the event in the trigger directory. The file must contain a list, and the elements of the list will be passed on as arguments to the event handlers. After the event has been triggered the file will be deleted. The following command will trigger the external-event on a server looking in '/some/path/to/dir/':

saveRDS(list(arg1 = 'test'), '/some/path/to/dir/external-event.rds')

These binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.
Health stats visible at Monitor.