перемещение узла в ENestedSetBehavior

[Bartholomew]

В ENestedSetBehavior при перемещении узла (moveNode()) обновляются только поля, отвечающие за позиционирование узла.
Тогда как при addNode() сохраняется все.
Т.е. если в редакторе можно менять какие-нибудь атрибуты наряду с родительским узлом, то изменения не сохраняются.
Поэтому приходится отключать поведение, сохранять как обычно, потом включать его обратно и перемещать узел.
Может и не стоит считать это багом, но поведение кажется мне слегка нелогичным.

[creocoder]

Зачем отключать поведение? Сохранить узел можно при помощи метода saveNode(), либо $model->[behavior_alias]->save(). И сразу после этого сделать перемещение. Что касается момента изменения каких либо данных совместно с перемещением узла, то как вы себе это представляете в реальной жизненной задаче?

P.S. Мухи отдельно, котлеты отдельно В данном случае лишь теоретически может казаться что такая возможность может быть интересна... С другой стороны если вы приведете конкретный жизненный пример/вариант интерфейса при котором такое возможно на практике, тогда я посыплю голову пеплом и включу эту фичу.

[Bartholomew]

ОК, я не совем правильно выразился - не нелогично, а неочевидно)
Да, можно сначала засейвить, потом переместить. Но это я понял, только после того, как человек мне сообщил, что у него изменения не сохранились (страница редактирования категории каталога, где кроме родительской категории можно настроить название, описание, метатеги и все такое).
Может быть, стоит тогда крупными буквами в доках написать, что при перемещении остальные данные не сохраняются. И пример использования.

[Ekstazi]

creocoder, надеюсь, api от этого не изменится так как я сейчас пишу расширение для AL + MP с таким ;t api. Сейчас только с позициями и сортировкой проблема.

[creocoder]

ОК, я не совем правильно выразился - не нелогично, а неочевидно)

Очевидно, что метод, который занимается перемещением узла - перемещает узел. Добавление в метод перемещения узла функционала для сохранения данных не даст никаких преимуществ ни в плане кол-ва SQL запросов, ни в плане большей логичности, к тому же потребуется изменение сигнатуры метода, т.к. сохранение подразумевает под собой ещё и набор атрибутов (см. параметр $attributes метода saveNode()) которые требуется сохранить.

creocoder, надеюсь, api от этого не изменится

Не изменится, т.к. это не обосновано

обновляются только поля, отвечающие за позиционирование узла

Вот если бы это было полностью так, то да, можно было бы сэкономить на кол-ве SQL запросов. Но это изменение реально лишь часть общей картины происходящего при перемещении узла. При детальном рассмотрении всей картины становится ясно почему метод не занимается сохранением измененных атрибутов, а занимается лишь перемещением. Оптимальнее со всех точек зрения вначале сохранить изменения в узел (saveNode()), а затем переместить его. Скомбинировать оба действия в один запрос не получится. А только последнее могло бы быть обоснованием совмещения функционала сохранения и функционала перемещения в рамках одного метода.

[Bartholomew]

да понятно, я говорю, напишите в доках, чтобы не было недоразумений в дальнейшем)

[samdark]

Можно вот сюда напоминалочку про доки закинуть https://github.com/yiiext/nested-set-behavior/issues, тогда точно не забудем.

[Ekstazi]

Написал на трекере об неизменяемости апи.

[creocoder]

чтобы не было недоразумений в дальнейшем)

Не примите за дерзость, но недоразумений с этим не было полтора года, а расширением пользуется огромная масса народа. Я не думаю, что стоит упоминать в документации, что метод по перемещению узла всего лишь перемещает узел. Упомянуть о чем то был бы как раз смысл, если бы метод делал что-то ещё, что выходит за рамки его назначения. Тут такой ситуации нет, поэтому упоминать не о чем.