Hi,

I need to develope a WPF desktop application with full customization support in the input form. The end user of the application must be able to add few more fields or remove or disable few fields from the standard fields. User should also be able to change the layout of the form for his use.

Please suggest best design practice for this requirement and also is there any readily available framework.

---

Mr Genius

Start by reading about the most trendy frame concepts used by developers these days:
- MVVM as for Model-View-ViewModel;
- Prism or CAL as form Composite Application Library;

I think the closest to your request out-of-the-box you'll find is Prism.
But...this is the "but" I refered to before...none of them is really generically dynamic. Meaning, in the bottom line, none of them will change persistency to store a new data structure, for instance, a new property in an object that would need a new table column in a database, nor creates a new property on the object if the object has a new column added to its table in the database.

As stated before, figuring this out is 90% of you task. The UI part is very simple maths.

If you are only dealing with one form and refering to only one type of object, it's very easy persisting, as you said, having a table holding a list of property information and another refering to object instance (id), property info (id) and property value. But what if you want to have another form, meaning for a new object type? Do you creat new pair of tables in persistency? How does you're UI knows there is a new type of object?

You can implement something like this that would be reflected equality on persistency and on runtime lists of objects.

Table/List:Types
Columns/Properties: Id, Name, the name of the tables that hold its property values if want to separate different Types information.

Table/List: Properties
Columns/Properties: Type_Id, Id, Name, Type, maybe UI control type that holds its value visually and for input, maybe some validation values.

Table/List: Value (maybe one per Type)
Columns: Type_Id (if same table holds all property values), Property_Id, Value

This is, as I said before, very poorly performant. If your concern is strictly dynamics, this is the way to go.
Starting from here, just generate everything dynamically in every direction.
-Get List of properties from persistency to build UI;
-Construct persistency communication regarding Type Properties (SQL query, for instance).

None of this is very hard work to implement. It's some work but it's not very complicated because you'd be constructing every little piece independently regarding entered parameters. For instance, using Property information to build caption and input field controls. It' work but you'd only have to implement once for each type of property or control.

It's matter of choice.

---

Bigsby, Lisboa, Portugal - O que for, quando for, é que será o que é... http://bigsby.eu

It depends on what you actually mean.

1. Is there supposed to be persistency? If so, what kind?
2. By layout you mean, color, size, position?

The answer to these questions changes the whole ordeal regarding conceptual implementation.

---

Bigsby, Lisboa, Portugal - O que for, quando for, é que será o que é... http://bigsby.eu

Hello MrGenius,

WPF gives several ways to customize the apperance of application.

It include Style, ControlTemplate etc.

You can start from:

http://msdn.microsoft.com/en-us/library/ms745025.aspx

http://msdn.microsoft.com/en-us/library/ms752339.aspx


Thanks.

---

Please mark the replies as answers if they help and unmark them if they provide no help

Just think as a product, which client/customer wants to customize this product as per their requirement. Customer may use click once deployment to install the application for all the application users.
Lets say an Employee Management system. Which has got a standard Employee form through which employees can be created. The client/customer of this application wants to add few more fields, some times, they may even want to change the captions of the field as they wish in the form. The customized form will be persistsed and loaded for all the users of this application.

Layout represents here rearranging the fields , may be reordering, one field in a row/line or multiple fields in a row/line.

---

Mr Genius

Now, I see exactly what you mean.

You want (1) dynamic persistency (possibility to add/change properties), and (2) dynamic UI.

(1) To achieve this you need to persist all data dynamically and here you have to options: have generic tables in persistency or have to possibility for your application to change the persistency model (your ITs will love this one).
Coding wise and don't any way of having this without implementing and object that is just a dictionary of Property/Value pairs. Needless to say, this is not very performant.

(2) This is the easy part. You can easily persist form information and build the control content dynamically according to saved data. The caution to have here interchanging between relative and absolute positioning. For instance when a Caption/Field pair is relative to another and is changed to an an absolute position, this may cause all kinds of mayhem in the UI.

Before thinking about (2) you'll have to have (1) totally figured out and (1) is the continuos struggle since the first computers saw the light of day.

---

Bigsby, Lisboa, Portugal - O que for, quando for, é que será o que é... http://bigsby.eu

If iunderstand correctly from your (1) that, i might have to have a generic tabledesign
one table contains all the fields/properties information(table FieldType)
second table will have form,field and layout information/relationships(table FormFieldMap)
third table will have field values stored (table FieldValue).

But the above design may require complex logic when it comes to sorting on these dynamic fields.

i am also thinking the requirement is very common in any product of this type. Is there any readily avaiable framework from microsoft or any article on it?

---

Mr Genius

Start by reading about the most trendy frame concepts used by developers these days:
- MVVM as for Model-View-ViewModel;
- Prism or CAL as form Composite Application Library;

I think the closest to your request out-of-the-box you'll find is Prism.
But...this is the "but" I refered to before...none of them is really generically dynamic. Meaning, in the bottom line, none of them will change persistency to store a new data structure, for instance, a new property in an object that would need a new table column in a database, nor creates a new property on the object if the object has a new column added to its table in the database.

As stated before, figuring this out is 90% of you task. The UI part is very simple maths.

If you are only dealing with one form and refering to only one type of object, it's very easy persisting, as you said, having a table holding a list of property information and another refering to object instance (id), property info (id) and property value. But what if you want to have another form, meaning for a new object type? Do you creat new pair of tables in persistency? How does you're UI knows there is a new type of object?

You can implement something like this that would be reflected equality on persistency and on runtime lists of objects.

Table/List:Types
Columns/Properties: Id, Name, the name of the tables that hold its property values if want to separate different Types information.

Table/List: Properties
Columns/Properties: Type_Id, Id, Name, Type, maybe UI control type that holds its value visually and for input, maybe some validation values.

Table/List: Value (maybe one per Type)
Columns: Type_Id (if same table holds all property values), Property_Id, Value

This is, as I said before, very poorly performant. If your concern is strictly dynamics, this is the way to go.
Starting from here, just generate everything dynamically in every direction.
-Get List of properties from persistency to build UI;
-Construct persistency communication regarding Type Properties (SQL query, for instance).

None of this is very hard work to implement. It's some work but it's not very complicated because you'd be constructing every little piece independently regarding entered parameters. For instance, using Property information to build caption and input field controls. It' work but you'd only have to implement once for each type of property or control.

It's matter of choice.

---

Bigsby, Lisboa, Portugal - O que for, quando for, é que será o que é... http://bigsby.eu

Hi,

MS supports this kind of application by providing visual Designers for Tables, DataSets and Forms. The normal way to do it would be to edit these objects in VS, and recompile the application. Also, you could use Access as a basis for your application, which allows you to do the same things without having to recompile.

If you don't want that, first thing you need is a data dictionary, which describes the tables and fields in the backing store, and the forms and fields in the UI. I'd use an XML file for that. Then you'd have a generic SQL engine that
a) creates the tables in the backing store from the definitions in the data dictionary
b) creates SQL statements from the data dictionary and uses them to fill DataTables, basically duplicating what the DataSet designer in VS does.
Third, you want some generic ViewModel classes which know how to validate data, control edit operations on DataRows, and how to commit this data to the backing store.
Fourth, you want some XSL templates which you can use to create XAML for the forms from the form definitions in the data dictionary, and some general classes which handle getting the correct form and loading it into the UI, using the ViewModel classes from step three. I wouldn't create the forms at runtime, but save them into an accessible location and load them into the application through the Navigation framework.
Finally, you'd want some UI Editor that allows the users to edit the data dictionary without allowing them to break the application, and to create new versions of tables and forms.

A lot of work, but once you have it, you can run your whole business from it...

I'd say I agree conceptually but not with the implementation. It makes no sense, in my opinion, to have different persistency sources for the same thing. Even less if you're using the worst performant the is like XML and XSL.

XML is a great standard for interop communication but its of no use for performant using. I'd use a pipe separated text file over a XML.
XSL is nice. Very nice idea but, it's not least performant and there's no point in using a new language to generate UI if you can do it all just in XAML and C#(or VB.Net if you really must).

Using DataTable and DataSet with WPF is possible for legacy reasons but makes very little sense in WPF object oriented binding. Why would you want to set some value to table[rowIndex][columnIndexOrName] if you can bind (both ways, with validation and whatmore) directly to object property?

I think there's to many WPF (and Silverlight) implemented as if it was Windows Forms (or ASP.Net) where object type is irrelevant because objects are returned and parsed as and from string. But not anymore. That's not what WPF (and Silverlight) is all about. It's much more than just easilly implementing gradients and animations.

Just some thoughts.

---

Bigsby, Lisboa, Portugal - O que for, quando for, é que será o que é... http://bigsby.eu

Hi Bigsby,

thanks for your insights. I thought, since one requirement was that the database schema can be changed by the user, it would probably be easier to implement that using raw DataTables, which are in principle the property/value pairs you wrote about in your first post.This way,you don't have to recompile your business logic when you change the database schema. However, if the database schema was fixed, I'd probably use objects as well. Although, looking at the way WPF supports Validation, I thought it might be a good idea to separate business logic from the actual database objects, and in that case, one can as well use the DataSet designer... I tend to use SQLCompact instead of SQL Server because it is easier to deploy, so I haven't done anything with LINQtoSQL Entities, yet, but this would also be the way to go, imho.


How are you doing validation in your WPF projects? Are you using ValidationRules at all?

Using XSL was because then you could hide most of the implementation details of the forms in the XSL style sheet, and separate user input from program code. In a maintenance release, one could simply replace the style sheet and generate the forms again from the data dictionary, which would be impossible when you only save user generated XAML.