data() MVC из скрипта возможно ?, Прицепить data() MVC к скрипту !? Опции

[JohnZ]

Со старта прошу не пинать за то что ( возможно !) не в том разделе задаю вопрос, т.к. вероятнее всего это из раздела MVC.

Задача следующая, - есть класс формы с указателем на её модельку ...

Раскрывающийся текст

class fpTForma : public QDialog
{
Q_OBJECT

public:

Q_INVOKABLE fpTForma(int id, MainWindow *parent = 0, Qt::WindowFlags f = 0);
~fpTForma();

public slots:

Q_INVOKABLE bool initForm(int fpCmd = 0);
Q_INVOKABLE MainWindow *getParent() { return mParent; }
Q_INVOKABLE int getCurRow() { return curIndex.isValid() ? curIndex.row() : -1; }
Q_INVOKABLE QVariant getCurValue(int col);
Q_INVOKABLE QVariant getCurValue(const QString & name);
Q_INVOKABLE bool match(int col, QVariant value);
Q_INVOKABLE bool match2(int col, int col1, QVariant value, QVariant value1);
Q_INVOKABLE void refresh() { model->select(); }
Q_INVOKABLE void setSort(int colnum, int order, bool sel = false);
Q_INVOKABLE int exec();

// .... etc

protected slots:

void closeEvent(QCloseEvent *event);
void keyPressEvent (QKeyEvent *event);
void setCurrentModelIndex(const QModelIndex &idx);

// .... etc

protected:

QScriptEngine *engine; // ссылка на интерпретатор скрипта.
MainWindow *mParent;
QTableView *viewChild; // QTableView на этой форме

fpTableModel *model; // Форма работает с Таблицей !!!

QModelIndex curIndex;
QSqlRecord curRecord;
QDataWidgetMapper *dataMapper;

// .... etc
};

Он фактически выполняет роль Контроллера в MVC. В скрипте эти объекты видны как frmXXX.
Задача состоит в том, что-бы из скрипта "прицепить" к его модели ф-цию data() для подмены колонок в View !?
Вроде-бы когда-то видел такое в и-нете, но не уверен. Возможно-ли такое сделать ? Подскажите PLZ ...

Сообщение отредактировал JohnZ - 3.7.2017, 17:38

[lanz]

Плюсовые объекты из скрипта менять не получится кмк, я бы сделал
1. Прокси модель с полем - коллбэком, которое можно выставить из скрипта.
2. data в этой модели дергает коллбэк и если тот возвращает нормальное значение, то оно и возвращается
3. если коллбэк возвращает undef, то дергается data проксируемой модели.

[JohnZ]

Плюсовые объекты из скрипта менять не получится кмк, я бы сделал
1. Прокси модель с полем - коллбэком, которое можно выставить из скрипта.

А сама fpTForma может быть псевдо-Прокси ?
Дело в том, что форм у меня 3 шт ( Query Table и RTable ) и соответственно 3 модели,
и к каждой из них "рисовать" проксю невыгодно, т.к. эта-же data() может "состоятся" всего
1-2 раза на весь проект, а данные _всегда_ будут летать через проксю на всех создаваемых объектах ...

ВотЪ если-бы можно было-бы получить указатель на скриптовую ф-цию, и если он не NULL, отдать его модельке
на этапе init или create !?

2. data в этой модели дергает коллбэк и если тот возвращает нормальное значение, то оно и возвращается
3. если коллбэк возвращает undef, то дергается data проксируемой модели.

Именно так только нужно немного изменить схему, если можно, - дергать data из скрипта, если она существует !?
Так можно как-ни-ить сделать ?

Сообщение отредактировал JohnZ - 4.7.2017, 11:42

[lanz]

А сама fpTForma может быть псевдо-Прокси ?

Может, но это нарушение SRP, к тому же три раза придется писать один и тот же код

и к каждой из них "рисовать" проксю невыгодно

Не надо к каждой, на то она и прокси чтобы проксировать любую модель. Те, которые нужно, надо в нее оборачивать, те которые нет, нет.

1-2 раза на весь проект, а данные _всегда_ будут летать через проксю на всех создаваемых объектах ...

Вовсе нет, во первых - можно не все модели оборачивать, во вторых можно(нужно!) пренебречь С++ оверхедом, а вызывать скрипт только для определенных колонок, ну и т.п.

ВотЪ если-бы можно было-бы получить указатель на скриптовую ф-цию, и если он не NULL, отдать его модельке
на этапе init или create !?

Не вижу проблемы так сделать, ведь функционал известен. Тут компромисс между гибкостью и скоростью - для гибкости все формы должны поддерживать скрипт data, для скорости - не все

Именно так только нужно немного изменить схему, если можно, - дергать data из скрипта, если она существует !?

Можно в коллбэк передать указатель на нижележащую модель, но... meh, на этом этапе уже проще писать модель полностью скриптом

[JohnZ]

Цитата(JohnZ @ 4.7.2017, 11:36)
А сама fpTForma может быть псевдо-Прокси ?
Может, но это нарушение SRP, к тому же три раза придется писать один и тот же код
Цитата(JohnZ @ 4.7.2017, 11:36)
и к каждой из них "рисовать" проксю невыгодно
Не надо к каждой, на то она и прокси чтобы проксировать любую модель. Те, которые нужно, надо в нее оборачивать, те которые нет, нет.

Дык по-любому все объекты получатся проксируемыми, или я чего-то не догоняю ...
... и ХТО такой SRP ? Просвети plz, если можно ссыль ... ?
У меня действительно в моделях и формах некоторые куски кода дублированы, ввиду видимо неправильного изначального
проектирования. Делалось для проверки идеи по-быстрому, ну а далее уже сложилось так исторически :-)
Да и технически честно говоря я не предтавляю как эту схему можно было реализовать иначе, -
все SQL класы ( Query Table и RTable ) имеют общего предка и "растут" по-цепочке друг из друга. Писать вирт-й общий класс
и опять реализовывать то что в QT уже сделано (SQL-ные класы) по-крайней мере глупо. Вот если-бы они "росли" из одного
предка, тогда можно было-бы замутить виртуальный класс с общим кодом, а так xez :-( :-)
Сейчас эти объекты создаются через селектор в зависимости от условия прописанного в скрипте.
В основном это потомок QSQLTable ...

Цитата(JohnZ @ 4.7.2017, 11:36)
1-2 раза на весь проект, а данные _всегда_ будут летать через проксю на всех создаваемых объектах ...
Вовсе нет, во первых - можно не все модели оборачивать, во вторых можно(нужно!) пренебречь С++ оверхедом, а вызывать скрипт только для определенных колонок, ну и т.п.

Дык какая колонка чего должна показать и должна "разобраться" data() !? ... или я тебя не правильно понял :-(

Цитата(JohnZ @ 4.7.2017, 11:36)
ВотЪ если-бы можно было-бы получить указатель на скриптовую ф-цию, и если он не NULL, отдать его модельке
на этапе init или create !?
Не вижу проблемы так сделать, ведь функционал известен. Тут компромисс между гибкостью и скоростью - для гибкости все формы должны поддерживать скрипт data, для скорости - не все

LANZ - а можно по-подробнее сей момент "разжевать" ???

Цитата(JohnZ @ 4.7.2017, 11:36)
Именно так только нужно немного изменить схему, если можно, - дергать data из скрипта, если она существует !?
Можно в коллбэк передать указатель на нижележащую модель, но... meh, на этом этапе уже проще писать модель полностью скриптом

... и здесь, и если можно псевдо-кодом ? Заранее БлагоДарен !!!

[lanz]

См. приложение.

Дык по-любому все объекты получатся проксируемыми, или я чего-то не догоняю ...

Только те, у которых используется прокся

... и ХТО такой SRP ? Просвети plz, если можно ссыль ... ?

Single Responsibility Principle из SOLID
https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

Вот если-бы они "росли"

Prefer composition to inheritance

Дык какая колонка чего должна показать и должна "разобраться" data() !? ... или я тебя не правильно понял :-(

В ScripProxy можно завести другие проперти, которые позволят фильтровать уже в ScripProxy::data, не дергая скрипт, например если скрипт умеет обрабатывать только 1 колонку, то можно для остальных и не вызывать коллбэк.

LANZ - а можно по-подробнее сей момент "разжевать" ???

Тот же пример что выше - if по номеру колонки можно сделать в скрипте, тогда скрипт будет вызываться для всех колонок. А можно сделать в ScriptProxy::data и сравнивать с вынесенным property. Тогда скрипт будет вызываться только для одной колонки.

и здесь, и если можно псевдо-кодом ?

Вроде того:

function data(row, col, model) { return model.data() }

args << engine->newQObject(sourceModel())

Прикрепленные файлы

 proxies.tar.gz ( 1,19 килобайт ) Кол-во скачиваний: 421

 

[JohnZ]

См. приложение.

БлагоДарю !!!

Вот если-бы они "росли"

Prefer composition to inheritance

Sorry, не понялЪ про composition ...
... или здесь подразумевается множеств-ное наследование ?

Дык какая колонка чего должна показать и должна "разобраться" data() !? ... или я тебя не правильно понял :-(

В ScripProxy можно завести другие проперти, которые позволят фильтровать уже в ScripProxy::data, не дергая
скрипт, например если скрипт умеет обрабатывать только 1 колонку, то можно для остальных и не вызывать коллбэк.

О том что "скрипт умеет обрабатывать только 1 колонку" нужно выставить _предопределённые_ признаки
в пропертях и опрашивать их из С-шного кода в проксе ?

Тот же пример что выше - if по номеру колонки можно сделать в скрипте, тогда скрипт будет вызываться для
всех колонок. А можно сделать в ScriptProxy::data и сравнивать с вынесенным property. Тогда скрипт будет
вызываться только для одной колонки.

Так точно ! Именно этот случай, - в БД "лежат" 5 double, параметры для тех-самых ф-ций расчёта с динамич-м
именем в переменной , и показать их надо одной строкой БЕЗ нулевых значений, иначе у бух-а в глазах рябить
будет от нулей Без data(...) в скрипте сия траблема не решается, или я его не вижу ...

Вроде того:
function data(row, col, model) { return model.data() }
args << engine->newQObject(sourceModel())

А как СВОЮ модель "объяснить" скрипту ? Сколько я ни пытался, не получилось
Он хочет видеть QOject, а у меня в модели его нет, а оборачивать всю(е) модель(и) в QOject гиморно ...

[lanz]

... или здесь подразумевается множеств-ное наследование ?

https://en.wikipedia.org/wiki/Composition_over_inheritance

выставить _предопределённые_ признаки
в пропертях и опрашивать их из С-шного кода в проксе ?

Да, например так.

А как СВОЮ модель "объяснить" скрипту ?

Если своя модель наследует от какой-либо модели (QAbstractXxxModel) то она и так QObject. Если нет, то это хороший повод ее отнаследовать, т.к. можно будет использовать со стандартными вью/проксями и т.п.

показать их надо одной строкой БЕЗ нулевых значений

в сишной data проверять на 0?

[JohnZ]

Цитата(JohnZ @ 5.7.2017, 15:07)
... или здесь подразумевается множеств-ное наследование ?
https://en.wikipedia.org/wiki/Composition_over_inheritance

Неа, не мой случай.
Или моя твоя не понялЪ или наоборот
Они-ж и так в одной цепи наследования, с добавлением / изм-ем функционала, и я ещё им свой навешиваю ...

Цитата(JohnZ @ 5.7.2017, 15:07)
выставить _предопределённые_ признаки
в пропертях и опрашивать их из С-шного кода в проксе ?
Да, например так.

!!!

Цитата(JohnZ @ 5.7.2017, 15:07)
А как СВОЮ модель "объяснить" скрипту ?
Если своя модель наследует от какой-либо модели (QAbstractXxxModel) то она и так QObject. Если нет, то это хороший повод ее отнаследовать, т.к. можно будет использовать со стандартными вью/проксями и т.п.

Раскрывающийся текст

class fpTableModel : public QSqlTableModel
{
// Q_OBJECT

public:
fpTableModel(fpTForma * parent = 0);
~fpTableModel();

Qt::ItemFlags flags(const QModelIndex &index) const;
// QVariant data(const QModelIndex &index, int role = Qt::DisplayRole) const;

void refresh() { ;}
bool initModel();
void setTable (int TIdd);
void setFilter(const QString & filter);

void beginInsertRow(const QModelIndex &parent, int row);
void endInsertRow();

protected:

QSqlRecord mRecord; // in Model from Query
QSqlRecord tRecord; // in original Table

private:

fpTForma *fParent;

friend class fpTForma;
};

Если снять rem с Q_OBJECT, НЕ компилится, ошибок на 2 экрана.
Соответственно и скрипту необъяснимо
Я вроде-бы уже когда-то об этой проблеме спрашивал, так и не решилось, оставил AS IS ...

Цитата(JohnZ @ 5.7.2017, 15:07)
показать их надо одной строкой БЕЗ нулевых значений
в сишной data проверять на 0?

Дык Тогда нет смысла в скриптовой data() ?!
В том и смысл, чтобы формирование "уникальных" колонок отдать скрипту.
Т.е. "спастись" от кучи с-шных моделей.
Нужна гибкость и оч-чень желательно не потерять много в скорости !
В сишной data проверить флажок-признак в пропертях, надо-ли вызывать скриптовую data.
Но ведь ей опять-таки понадовится моделька ... Или можно как-ни-ить обойтись ?

Сообщение отредактировал JohnZ - 5.7.2017, 22:41

[lanz]

Если снять rem с Q_OBJECT, НЕ компилится, ошибок на 2 экрана.

Надо с этим разобраться, кидай сюда хоть что за ошибки.

Дык Тогда нет смысла в скриптовой data() ?!
В том и смысл, чтобы формирование "уникальных" колонок отдать скрипту.
Т.е. "спастись" от кучи с-шных моделей.
Нужна гибкость и оч-чень желательно не потерять много в скорости !

А в чем проблема с кучей сишных моделей?
На самом деле нет разницы где писать - и там и там код придется как то поддерживать и обновлять.
Более того, как ты думаешь насколько часто будет менятся логика убирания лишних нулей?