`Draggable` components should emit `dragend`, not `drop` events.
`drop` should only be emitted by `Droppable` components, or the receiver
of a component that uses both won't be able to tell if a `drop` event
came from a component being dragged, or from an element where a dragged
element was dropped.
The reason is that an `id` specified on procedure level will be applied
to all the child requests.
This means that the first response from the first completed request will
be sent to Redis and mistakenly interpreted by HTTP listeners as the
return value of the whole procedure.
`Procedure.build` should instead calculate its own ID for the procedure,
and apply different IDs to the child requests.
- Added UI panel.
- Added support for entity types.
- Enhanced ability to edit procedures.
- Added ability to create, rename, edit, duplicate and delete stored
procedures.
- Added support for YAML dumps of non-Python procedures.
- Added support for visualizing Python procedures directly in their
source files.
This is to bridge the gap between pointer-based and touch-based devices
and provide a drag-and-drop implementation that exposes a consistent API
for both the interfaces.
These components work by wrapping an underlying draggable/droppable DOM
element and proxying the event handlers consistently when drag/touch
events are detected.
This allows to listen to high-level drag/drop events even on touch-based
interface based on touch start/move/end events.
Example usage:
```vue
<template>
<div class="draggable" ref="draggable">
I can be dragged.
</div>
<div class="droppable" ref="droppable">
Drop elements here.
</div>
<Draggable :element="$refs.draggable"
@drag="console.log('The element is being dragged')"
@drop="console.log('The element is been dropped')" />
<Droppable :element="$refs.droppable"
@dragenter="console.log('Entering')"
@dragleave="console.log('Leaving')"
@dragover="console.log('Dragging over')"
@drop="console.log('Dropped!')" />
</template>
<style lang="scss" scoped>
.draggable {
&.dragged {
opacity: 0.5;
}
}
.droppable {
&.active {
border: 1px solid green;
}
&.selected {
background: yellow;
}
}
</style>
```
- Adds the ability to select lines from the editor, which in turn will
highlight them.
- Adds the ability to load a file and scroll at a specific line if the
URL has with the `line` argument.
- Adds the ability to maximize the file editor modal.
- Added support for multiple element classes.
- Added `glow` property.
- Added support for absolute initial positioning.
- Added dynamic button size.
- Added FloatingButtons component to support groups of floating buttons.
- Don't propagate `close` events. This prevents underlying modals from
being closed on cascade when the current modal is closed.
- Added logic to filter out <ESC> keystrokes that have already targeted
the outermost open modal, so underlying modals won't be closed.
- Added `:before-close` property. This is a callback that can optionally
be passed to the component and it will run some custom logic before
the modal is closed. If it returns false then the modal will stay
open.
- Fail immediately if no branches are checked out.
- Rebase only if we're pushing on master (don't bother for feature
branches).
- Do a push force to Github.
- Update the cached representation of the procedure asynchronously on
the `publish_entities` callback. This prevents stale records from
being loaded from the db before the entities engine has persisted the
new ones.
- Don't re-publish all entities when calling `procedures.status` at the
end of `procedures.save`. This is both for performance reasons and to
avoid sending to the entities engine stale representation of the data.
- `procedures.status` should always sync with the db to ensure that the
action returns the most up-to-date version of the procedures.
- Store, return and propagate entity procedure metadata.
- `procedures.exec` now supports running procedures "on the fly" given a
definition with a list of actions.
- Fixed procedure renaming/overwrite logic.
- Access to `_all_procedures` should always be guarded by a lock.
Earlier any extra parameters passed to the `db` configuration other than
`engine` where ignored.
This enables engine-level configurations such as:
```yaml
db:
# Display all SQL queries
echo: true
```
Messages can be quite big and verbose, and they can anyway be subscribed
over Websockets.
Full dumps are anyway enabled when Platypush is started in verbose mode.
This commit replaces the dumps on INFO level with a quick summary
containing the message ID, request/event type and response time.