R – How would you design a form with many dynamic fields

data-entryuser interface

We have a form that allows a user to dynamically add inputs for fields. For example if you have a form for tracking projects, you want to dynamically add tasks to that project. Just to clarify my language: you dynamically add inputs for the task field. The problem is, we have 50 of those fields. Our current solution presents all 50 fields with a plus (+) next to the field to allow them to add another input box for that field. The labels for the field are to the left of the field and each input box that is added goes below the current input box.

Please trust that dynamically adding inputs is the right solution, please trust that it has been thought out, please trust that this is what the users wants, please trust that we have gone down various other roads and this is the best solution.

My question is about presentation: How would you do it?

Please keep the answers to UI design. We already have the database schema figured out.

Update

Current Solution is a web based application that uses JavaScript to dynamically add new inputs and looks very similar to Corey Trager's drawing:

Task     [.............] +  
         [.............] +  
         [.............] +  
         [.............] +

Foo      [.............] +
         [.............] +
         [.............] +

Repeat 50 times...

Best Answer

So, what you described can look something like this? If not, can you try "drawing" it please?

Task     [.............] +  
         [.............] +  
         [.............] +  
         [.............] +

Foo      [.............] +
         [.............] +
         [.............] +

Is this a web page or other technology?

Related Solutions

R – How to handle form customizations for different customers

This issue has three aspects: form layout, database storage and configurable business logic.

Configuration driven form layout

A flexible approach to form layout could be achieved by moving the layout to a descriptor file. Three GUI toolkits that support this are QT, WPF and XUL. However, AFAIK Swing does not directly support this capability. QT Jambi does allow you to use QT on Java as an alternative to Swing and QT 4.5 is going to be available with LGPL licensing. This is not a pure-java solution, but may be a possibility if this and the attendant re-write of the UI code is acceptable.

The advantage of the configuration driven form layout is that the customisations can be made without having to maintain a separate build for each customer, so even if you have an incumbent code base, you may wish to examine whether there is a business case to adopt such a toolkit vs. maintaining multiple customer-specific builds. However, for a compiled language, you may still need to set up some sort of plug-in framework for the generated form code.

Configurable database storage

This is more complex. You can do this in three ways, which have their pros and cons.

The first approach is to have a series of 'user' fields on the table, such as 'User1', 'User2' etc. Configured fields on the forms can be mapped to these fields - and a generic user field mapping facility should not be difficult to implement. This is the most efficient from a database query perspective but suffers from the limitation of a finite number of possible fields. If you have fields 'User1' to 'User20' you can only support 20 user defined attributes. Also, they will have to be nice, wide generic varchars, so you will get no type safety from the database.
The second approach is to have an attributes table hanging off the entity. This doesn't give you type safety, but it does let you have as many attributes as you want. Building a generic handler for this is also quite feasible but the query performance will be affected as you do multiple joins against the attributes table.
Persist the user defined fields in an XML blob. This has little to recommend it, as it makes the data harder to access through the database. However, I have seen it done.

Configurable business logic

This is a much more thorny issue. Without adding custom code and changing your build, you have a few options for doing configurable business rules: Rule engines, scripting languages or a set of standard on/off features such as mandatory fields.

Rule engines: You really have to design your application from scratch to use these, and they have their own limitations and foibles. ILOG, The incumbent in this field, is also quite expensive. For java, JESS might be an option.
Embedded scripting language: By adding an interpreter for Jython, Groovy or some other JVM-friendly interpreted language, you can write plug-ins for the system without having to issue a new build. Some testing workload will still be incurred, but this might be a maintenance win overall.
On/Off configuration for features. This is the least flexible option, but is relatively simple and adds relatively little in the way of external dependencies and licensing costs. It may also be your only choice if you're trying to retrofit configuration to something that started life as a bespoke application.

None of the Above

If the answer is 'None of the Above', you're probably stuck with custom builds. In that case, make a plug-in architecture for the forms so you can at least isolate the customer specific items into a separate module.

C++ – How to call created .ui design form in Qt with button.clicked() event

Using .ui files is explained in Qt's documentation: http://doc.qt.io/archives/qt-4.7/designer-using-a-ui-file.html

Summary: The easiest way to handle an .ui file is to run it through uic (the User Interface Compiler) at compile time. This is done automatically if the .ui file is included in your project (.pro) file. ("Add New" probably has done this automatically in your case.) Then you only need to include the generated C++ header file in your source file. Its name should be something like "ui_nameoftheoriginaluifile.hpp". Of course, after that you need to instantiate the form defined in the .hpp file.

Edited to add:

There are several issues with your code, starting from its readability. I don't know if you have used an object-oriented language before, but a very basic rule in C++ is to begin class names with capital letters to make them easier to distinguish from objects and other variables. So the class names should be "About", "Parent", etc.

The compilation error is caused by using "about" instead of the name of the class actually used in the "ui_about.hpp" file - "MainWindow". (Which is determined by the name of the form you have used in the .ui file.)

If you are using Qt Creator: hold down the Ctrl key and click on the name of the file "ui_about.h" in the include directive. This will open it for inspection. Try to figure out how it works.

You also haven't defined the opDialog() function as a member of the "parent" class in "parent.cpp", which causes another compile-time error.

You also shouldn't be using a QMainWindow for an about dialog. QMainWindow is supposed to be the main window of your application - there shouldn't be any more instances of it.

So, about.h:

namespace Ui {
    class MainWindow;
}

class about : public QMainWindow {
    Q_OBJECT
public:
    about(QWidget *parent = 0);
    ~about();

protected:
    void changeEvent(QEvent *e);

private:
    Ui::MainWindow *ui;
};

And the beginning of about.cpp:

#include "about.h"
#include "ui_about.h"

about::about(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);
}

Best Answer

Related Solutions

R – How to handle form customizations for different customers

C++ – How to call created .ui design form in Qt with button.clicked() event

Related Topic