[SOLVED] Generating a UI on the fly
-
wrote on 20 Jun 2011, 18:09 last edited by
That would be in the scope of some example code. Hopefully I'll have some time this week to put it together, but that may take some days. Please stay tuned.
-
wrote on 20 Jun 2011, 18:12 last edited by
[quote author="Volker" date="1308593355"]That would be in the scope of some example code. Hopefully I'll have some time this week to put it together, but that may take some days. Please stay tuned.[/quote]
Please, don't waste too much of your time on me. I'll just read and try things by myself. I'm really grateful that you answer my questions, and I feel bad that you take so much of your time for me!
-
wrote on 20 Jun 2011, 18:12 last edited by
[quote author="Joey Dumont" date="1308593123"]
So how do I not need .h and .cpp implementation files that are stored in the DB. Otherwise, I have a nice UI that does nothing, no?
[/quote]
Very true. One thing you can do is iterate over all editable fields in the .ui file and save the value in the appropriate field in the database. You could encode the field in some property, e.g. the objectName. I actually had a very similar problem of dynamically providing UI's for certain user created content. At first I wanted to solve it with UiLoader, but it proved to be too limiting in the end. I ended up using a plugin for every that encapsulated the interface and provided a nice API (I also wrote a tool to convert .ui into a skeleton for these plugins - it worked really well, but it was still painful). I'm looking into switching to some kind of qml based ui, to be truly cross-platform.In conclusion, if you need complex interaction with your UI (i.e. everything you can't do with signal/slots), you'll have to find another solution.
[quote author="Joey Dumont" date="1308593123"]
Plus, most of my tests have different sets of results, so I would need to have a .UI file for each of them, or at least most of them.
[/quote]
Yes -
wrote on 20 Jun 2011, 18:19 last edited by
[quote author="loladiro" date="1308593555"]
In conclusion, if you need complex interaction with your UI (i.e. everything you can’t do with signal/slots), you’ll have to find another solution.
[/quote]I need to be able to take the data that was entered into the editable fields and commit it to the DB. I also need to fetch some data from the DB and display it in the UI.
[quote author="loladiro" date="1308593555"]
At first I wanted to solve it with UiLoader, but it proved to be too limiting in the end. I ended up using a plugin for every that encapsulated the interface and provided a nice API [/quote]That loosely sounds similar to my initial idea of subclassing QWidget for each test, which I guess I will have to resort to, given the low degree of redundancy of data entry format for my tests. What I mean by that is that some tests have tables as results, others a single line of text, others a single value, others have expected values and blah blah blah. They are very heterogeneous.
-
wrote on 20 Jun 2011, 18:34 last edited by
[quote author="Joey Dumont" date="1308593994"]
That loosely sounds similar to my initial idea of subclassing QWidget for each test, which I guess I will have to resort to, given the low degree of redundancy of data entry format for my tests. What I mean by that is that some tests have tables as results, others a single line of text, others a single value, others have expected values and blah blah blah. They are very heterogeneous. [/quote]I know the problematic. BTW, If I may ask, if you have so many different test with test data, do you just have a different SQL table for every test or do you somehow serialize the data and place it all in one table (I would do the first, but I've seen plenty of implementation that do the latter to keep the DB structure simple)?
-
wrote on 20 Jun 2011, 18:46 last edited by
[quote author="loladiro" date="1308594853"]
I know the problematic. BTW, If I may ask, if you have so many different test with test data, do you just have a different SQL table for every test or do you somehow serialize the data and place it all in one table (I would do the first, but I've seen plenty of implementation that do the latter to keep the DB structure simple)?[/quote]I do the former, but not to keep the DB structure simple, but they to be able to add tests at will. It is cumbersome to add tables every time, and I have over 300 tests, which you make the DB unwieldy.
Adding lines, on the other hand, is very easy, hence the single table structure.
-
wrote on 20 Jun 2011, 18:53 last edited by
I guess it would be easier using a NoSQL DB
-
wrote on 20 Jun 2011, 18:59 last edited by
Maybe, but since this is for a summer project, I don't think I have time to learn how NoSQL works and redo the work I've already done.
But thanks anyway for the heads-up on that ;)
-
wrote on 20 Jun 2011, 19:09 last edited by
[quote author="Joey Dumont" date="1308596394"]Maybe, but since this is for a summer project, I don't think I have time to learn how NoSQL works and redo the work I've already done.
But thanks anyway for the heads-up on that ;)[/quote]
Summer projects can be the most important ones out of all of them (you learn the most and you have the most fun, because you are motivated :) ). Also, can you post a screenshot or something when you're done with it? Just out of curiosity.
-
wrote on 20 Jun 2011, 19:21 last edited by
Of course. I can post a screenshot as soon as I have something interesting.
20/20