Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drag validation #32

Closed
wants to merge 2 commits into from
Closed

Conversation

danielbeeke
Copy link
Contributor

d.org issue: https://www.drupal.org/node/2868539

In this commit are a settings form, a bit of preprocessing data-attributes and a little proof of concept javascript. The javascript is not yet bug free. I am still trying to wrap my mind around how the tabledrag things work.

What are the opinions about the approach? What needs to be changed?

@tonystar
Copy link
Collaborator

tonystar commented Apr 12, 2017

For reference — here is how Bricks settings looks like:

screenshot 2017-04-12 16 16 17

@tonystar
Copy link
Collaborator

tonystar commented Apr 12, 2017

I am still trying to wrap my mind around how the tabledrag things work.

I'm still trying to understand it! Tabledrag is kind of big black box =)))

@tonystar
Copy link
Collaborator

tonystar commented Apr 12, 2017

Initial review is completed. Conceptually it's very good! Configuration form looks clear and straightforward. And I can confirm that nesting validation is working (with some bugs, but working)!

Bug 1:

  1. Go to Bricks settings > enable Text inside Columns.
  2. Create a new node, add Columns and Text inside it. Validation works.
  3. Add second Text brick and try to drag inside Columns => no success.

@danielbeeke
Copy link
Contributor Author

I have been working on this, it is a bit difficult,
will try to work on it more this weekend

@tonystar
Copy link
Collaborator

@danielbeeke sure- no pressure!

@danielbeeke
Copy link
Contributor Author

It is a bit better now, but still one ugly bug that I can not find.

https://youtu.be/QCYEYjBb0ps

@tonystar
Copy link
Collaborator

It's much, much better!!! Main validation functionality works for me.

I reproduced the same bug in a more simple way: https://youtu.be/cthjwseTQmM. Probably this can help. Also, some ideas:

  1. Here you allow to nest under prev non-leaf row:
// Do not go deeper than as a child of the previous row.
maxIndent = $prevRow.find('.js-indentation').length + ($prevRow.is('.tabledrag-leaf') ? 0 : 1);

So if the following conditions will be skipped => we can have a bug.

  1. Comparing to previous row may be not enough. Like on my YouTube video - any parent of previous row is also a candidate (it's probably related to // TODO this may need more recursive like code.).

@danielbeeke
Copy link
Contributor Author

https://www.youtube.com/watch?v=v4VIbKz3wKg&feature=youtu.be&t=34

I still got one very strange bug.
The link starts at the right point, before that I demonstrate that things work fine. On 34 seconds I try to move a group out of its parent. It gets blocked by the first child of the outer parent.

Strange!

@@ -1,3 +1,12 @@
tabledrag.relationship-all:
js:
js/tabledrag.relationship-all.js: {}

nesting-validation:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This validation is:

  1. for tabledrag
  2. Bricks-specific

=> so I think a better name would be tabledrag.bricks-validation or just tabledrag.bricks (can be used further for over UI stuff).

@@ -0,0 +1,5 @@
bricks.settings:
title: 'Bricks settings'
parent: system.admin_config_media
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about system.admin_structure? Imho, more obvious (like ECK, View modes, Paragraphs etc).

bricks.module Outdated
/**
* Returns the nesting settings in a format that the javascript can handle.
*/
function bricks_get_nesting_data($return_entity_type = NULL) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_bricks_get_nesting_data?

bricks.module Outdated
@@ -187,6 +187,9 @@ function _bricks_preprocess_tabledrag_form(&$variables, $element_key, $widget, $
if ($key !== 'add_more') {
$depth = $element[$key]['depth']['#value'];

$variables['table']['#rows'][$key]['data-depth'] = $depth;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to store depth as data-attribute? We already have hidden input with depth and can get value right from there! https://github.com/highweb/drupal-bricks/blob/8.x-1.4/bricks.module#L234

@@ -0,0 +1,7 @@
bricks.config:
path: '/admin/config/media/bricks'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/admin/structure/bricks?

var prevBundle = $(prevRow).attr('data-bundle');
var parentBundle = $(this.group[0]).prev('tr').attr('data-bundle');

if ($.inArray(prevBundle, settings.bricks.nesting[currentBundle]) !== -1 || $.inArray(parentBundle, settings.bricks.nesting[currentBundle]) !== -1) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is currentBundle nestable under prevBundle? => increment values.max. Why to care about parentBundle?

Also: not sure but what if this code is running for say depth 3? Shouldn't values.max equal 3+1?

And what if there is no parent? (depth = 0, delta = 3 in example)

@danielbeeke
Copy link
Contributor Author

I have been working on this, but it seems more difficult.
Will work on it more this week.

I am also replacing the validSwap function

@tonystar
Copy link
Collaborator

@danielbeeke the code looks much better! Are we still have some critical bugs or must-have refactoring?

@tonystar
Copy link
Collaborator

tonystar commented Jun 4, 2017

@danielbeeke the implementation seems to be not that straightforward and simple…

I suggest the following:

  1. Simplify the logic in Bricks core. In example we can rely on tabledrag-leaf behavior and allow to configure which bundles are "leafs" (ie Images, Text etc). This gives us ~80% of use cases covered with a minimal code.

  2. Wrap everything else from this PR in a separate contrib module. Say, Bricks Restrictions. For complex setups. And it can be updated independently from core.

What do you think?

@tonystar tonystar reopened this Mar 19, 2018
@tonystar tonystar closed this Mar 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants