Extending the generator

Use this forum to request new features or suggest modifications to existing features

Extending the generator

Postby doulos » Mon Sep 15, 2014 5:00 pm

Hello,

after completing our first project with QxOrm and QtQuick, we are looking at the lessons learned and also preparing for the next, bigger venture. In doing that we have decided that in order to minimize development overhead, we would like to add a few capabilities to QxOrm / QxEntityEditor which we consider quite important and which might also be useful for the general public. Before listing the requirements / capabilities, I would like to point out that if they cannot be met with the current functionality (which is our perception), we would be willing to implement them ourselves and contribute them back to the project, provided there is enough support from qxorm to enable this.

Heres the requirements:
  • We need to publish our classes to QML. We dont want to work with the QxModelView module however, but rather directly QML-enable our persistent classes. This means adding Q_PROPERTY and signal declarations to the generated header code, as well as adding code for emitting the appropriate signals from the setter methods. We want to apply this only to certain class members selectively
  • We want to persistence-enable certain properties in such a way that updates to these properties are immediately written through to the database. We are currently doing this by creating additional "persistent setters" in the custom cpp file which we then use in the WRITE clause of the Q_PROPERTY declaration. We yould much rather generate these setter methods

Point 1 and 2 would require additional annotations in the EntityEditor (which members should become Q_PROPERTIES? Which signals do they emit? What setter do they invoke?). For point 2 we would like to be able to automate the generation of the "auto-persistent" setter methods (see code sample below) as well.
Code: Select all
//Header:
Q_PROPERTY(double hourlyWages READ getHourlyWages WRITE setHourlyWagesP NOTIFY dataChanged)

//Setter implementation:
void Project::setHourlyWagesP(const double & val)
{
    setHourlyWagesNoAutomation(val);
    qx::dao::update(*this, 0, QStringList(column_HourlyWages()));
    emit(dataChanged());
}


It seems to me that the current generator customization mechanism is not flexible enough to meet these requirements. Please let me know what you would consider the best way to implement them. With regard to the additional annotations in EnityEditor we are also considering an alternative path based on text annotations inside C++ class declarations (or XML files, for that matter). This might be easier to maintain than using EntityEditor every time (and dealing with the non-versionable qxee file).

Regards,
Christian
gsvitec
doulos
 
Posts: 15
Joined: Mon Aug 11, 2014 1:24 pm

Re: Extending the generator

Postby qxorm » Mon Sep 15, 2014 6:52 pm

Hello,

I think this is more a QxEntityEditor request feature : so I will move your topic in the QxEntityEditor section later...

we would be willing to implement them ourselves and contribute them back to the project

Yes you can submit a patch or everything else : and your code could be added to a next version of QxOrm and/or QxEntityEditor.

we are looking at the lessons learned and also preparing for the next, bigger venture....We dont want to work with the QxModelView module

I think this is not the best option : for bigger projects, you should consider working with Qt model/view framework and QxModelView module.
But this is just my opinion, maybe I'm wrong.

It seems to me that the current generator customization mechanism is not flexible enough to meet these requirements.

I think with current version (QxEntityEditor 1.1.6) and the new javascript engine, you have everything you need to generate your custom Q_PROPERTY definition/implementation.
I could help you if you want to customize your generated project.

additional annotations in EnityEditor

You can use the meta-data section to add custom parameters : the meta-data section is available for entity/property/relationship/enum (see the bottom screen of entity parameters window for example).
All meta-data are available in the javascript engine : for example, you could imagine that by default, all properties generate a Q_PROPERTY definition.
And in the meta-data, you manage only exceptions (properties you don't want a Q_PROPERTY definition) : for example, a meta-data key named NO_Q_PROPERTY with a meta-data value set to 1.

we are also considering an alternative path based on text annotations inside C++ class declarations (or XML files, for that matter).

Yes why not, but I think it is not necessary with what you want to do.
Moreover, a qxee project is just a SQLite database, so you could imagine to write a script to update this database to apply your own modifications automatically.
qxorm
Site Admin
 
Posts: 476
Joined: Mon Apr 12, 2010 7:45 am

Re: Extending the generator

Postby doulos » Tue Sep 16, 2014 8:34 am

Yes you can submit a patch or everything else : and your code could be added to a next version of QxOrm and/or QxEntityEditor.

but we dont have the source code of QxEntityEditor resp. the generator, or do we??
I think this is not the best option : for bigger projects, you should consider working with Qt model/view framework and QxModelView module

we looked into this, and did not like what we saw. We would really prefer to avoid the additional ModelView layer, which hides our domain semantics and replaces them with row/column/index semantics (yuck!). Directly publishing our domain objects has worked well so far, so I see no reason to abandon this. What we haven't fully evaluated yet is working with persistent relationships, but I am confident this will work out as well. So, unless I have overlooked some fundamental benefit of ModelView, its not for us. But for now, this remains an open topic.
I think with current version (QxEntityEditor 1.1.6) and the new javascript engine, you have everything you need to generate your custom Q_PROPERTY definition/implementation.

ok, I'll check this out.
Yes why not, but I think it is not necessary with what you want to do. Moreover, a qxee project is just a SQLite database

the issue with the qxee format is lack of versionability / diffability. It is very hard to determine what persistent mappings were changed in what way between two source code versions. Moreover, it is near impossible to perform a merge operation for changes performed by several people concurrently. This would all be easier if there was an alternative text-based input format for the generator. I personally would prefer XML, because it is easier to write a parser. If there was a (well-documented ;)) API for the generator, we could use that and be done fairly quickly.

regards,
Christian
doulos
 
Posts: 15
Joined: Mon Aug 11, 2014 1:24 pm

Re: Extending the generator

Postby qxorm » Tue Sep 16, 2014 9:11 am

Hello,

but we dont have the source code of QxEntityEditor resp. the generator, or do we??

No QxEntityEditor is a closed source software.
But you can share your javascripts files to customize the generated export.

What we haven't fully evaluated yet is working with persistent relationships, but I am confident this will work out as well.

Yes, relationships are managed by the QxModelView module and the C++ model/view export plugin of QxEntityEditor.
But I don't know how you will manage them with Q_PROPERTY (QObjectList ?) : it is an interesting part, and I will wait for your solution to manage relationships with Q_PROPERTY.

unless I have overlooked some fundamental benefit of ModelView, its not for us.

With QxModelView module, everything is already written (even relationships) and you don't have to write any line of code or customize things to expose all your entities to QML !
You just have to understand how the Qt model/view framework work.

If you read this page from official Qt website : http://qt-project.org/doc/qt-5/qtquick- ... odels.html
It is written : QAbstractItemModel / This is the best approach if you have a more complex model that cannot be supported by the other approaches.
This is why I said that for bigger projects, you should consider working with Qt model/view framework and QxModelView module.

the issue with the qxee format is lack of versionability / diffability.

There is a feature in QxEntityEditor to manage versioning : go to the main menu "Actions >> Tag project state".
With this function, you can have an history of differents versions of your qxee projects.

If you want a XML file to perform some diff, you can also use the XML export plugin : this plugin will export your qxee project (and all its entities/properties) to a XML file.

Or, if the XML export plugin is not sufficient in your case, I think you can easily find some tools or scripts on the web to export a SQLite database (the qxee project) to a XML file.
qxorm
Site Admin
 
Posts: 476
Joined: Mon Apr 12, 2010 7:45 am

Re: Extending the generator

Postby doulos » Tue Sep 16, 2014 11:24 am

But I don't know how you will manage them with Q_PROPERTY (QObjectList ?)

yes, we already have used QObjectList in onle place for a readonly relationship. It remains to be seen how this works for deleting / inserting items, but I am confident that this will go smooth as well.
If you read this page from official Qt website : http://qt-project.org/doc/qt-5/qtquick- ... odels.html
It is written : QAbstractItemModel / This is the best approach if you have a more complex model that cannot be supported by the other approaches.

I have read that before, and for now, I'll go for the "that cannot be supported by the other approaches" part, as the QObjectList approach has already served us well. I really want a clean object model to deal with, and am appalled by the QAbstractItemModel API (insertRow, insertColumn, getIndex).
There is a feature in QxEntityEditor

The tagging feature doesn't seem to adress our requirement at all (how do you compare tags using a standard diff tool?). The issue with the qxee file being non-mergeable (and thus not concurrently updateable) remains. The export suggestions are clumsy workarounds. I still think the ideal solution would be to maintain all mapping information in XML files and use these as input to the generator.

I understand the EntityEditor and generator are closed source, and the latter may not have a documented API. Maybe there is a possibility for getting this done anyway. If not, we'll try to get along with the described workarounds.
doulos
 
Posts: 15
Joined: Mon Aug 11, 2014 1:24 pm

Re: Extending the generator

Postby qxorm » Tue Sep 16, 2014 2:23 pm

we already have used QObjectList in onle place for a readonly relationship.

QxOrm library is not designed to work with QObjectList class (QxOrm uses strongly typed list).
But if you find a solution to work easily with QObjectList, I'm interested !

I really want a clean object model to deal with, and am appalled by the QAbstractItemModel API (insertRow, insertColumn, getIndex).

You don't have to deal with the QAbstractItemModel API to expose your entities to QML views !
QxModelView module already implements the QAbstractItemModel interface.

But ok, I understand that you prefer working with Q_PROPERTY.
I will not insist more.

I still think the ideal solution would be to maintain all mapping information in XML files and use these as input to the generator.

QxEntityEditor projects (qxee files) are based on a SQLite database.
There is no plan for now to create a project based on XML files, sorry for that.
Maybe in the future, we will add an import plugin from XSD files, but I can't give you a date for that.
qxorm
Site Admin
 
Posts: 476
Joined: Mon Apr 12, 2010 7:45 am

Re: Extending the generator

Postby qxorm » Wed Dec 24, 2014 8:32 am

We want to persistence-enable certain properties in such a way that updates to these properties are immediately written through to the database.

FYI, this new feature has been developed and is available in QxOrm 1.3.1 (still in BETA version) in the QxModelView module.
You can download the current BETA version here (QxOrm 1.3.1 BETA 29) : http://www.qxorm.com/version/QxOrm_1.3.1_BETA_29.zip

To enable this feature, just use the new setAutoUpdateDatabase() method of qx::IxModel class :
Code: Select all
pMyModel->setAutoUpdateDatabase(qx::IxModel::e_auto_update_on_field_change);
qxorm
Site Admin
 
Posts: 476
Joined: Mon Apr 12, 2010 7:45 am


Return to QxEntityEditor - Feature request

Who is online

Users browsing this forum: No registered users and 1 guest

cron