I am working with an ASP.Net web app that allows users to create an "application."
They define fields and their data types. Based on that, I generate a query to create a table.
I would like to use the metadata from the table to generate an input form to display to users.
Is this a good approach?
Has anybody done a similar project
that can share some lessons learned?
How about creating and altering
tables at runtime?
Does anybody see any problems with
that?
You will need to accomadate for all userdefined field types (text, number lookup, dropdowns, check boxes, dates, etc).
These will have to be save to the database per field type per user per forms.
Further you will have to allow the user to define their own layout. this will mean that you have to same the entire form layout, per user per form per control.
There are some apps available, that applies this logic, (I think SharePoint has this type of approach).
I have done this once before, but it was using WinForms, using XtraLayoutControl , DevExpress Layout Controls.
This did allow me to save the layout, but did not create the controls for me automatically. I still had to implement that my self.
If you have any specific questions, regarding db table layout, client integration, or performance of these queries, Please feel free to ask.
Related
I am starting to build an app, using Meteor, that includes user-populated company profiles (including both financial data and text). I will be looking into a datafeed for public company information but much of the information for private companies will be user-populated.
I know I will need to create a form for the user to fill in so that the company information will be captured by the database. However, can I make this same form available to the user to both display the data and to allow them to edit the data in the future? Or do I need to build a separate view using tables for this purpose? My preference is the former, just one screen to create and edit as needed.
Any examples of similar instances would be very appreciated.
Thank you.
This is less of a meteor specific question, rather a general web technology question. Meteor can provide the data in the template of course, and it can offer events to process data and insert/update this to a database. This is the same as any underlying architecture. The question is really how to approach the problem with HTML & JavaScript.
A couple of potential methods:
Write your HTML to display the content in its non-editable form. Then provide an edit button to switch mode. When clicking this button switch on 'contenteditable' for the elements you wish to be edited: http://html5doctor.com/the-contenteditable-attribute/
Also reveal a save button, then process the event through meteor. Use selectors to extract the fields by referencing either designated class names, data attributes or name attributes. It would also be a good idea to alter the appearance of editable elements with a background or outline. The disadvantage here is that it's slightly non-standard and you may have the need for more complex data-types like dropdowns or checkboxes etc.
Create view with a standard form HTML. Style it in a way that shapes the information primarily for display rather than editing, eg. hide form field borders. Provide an edit button that when clicked alters the CSS and reveals form field borders, also reveal/replace elements which need more complex controls like dropdowns, perhaps turn on field labels too and of course a save button. The disadvantage is slightly more complex CSS and JavaScript.
In visual Web devlepoer I have my database connection in my project if My project database has several tables that I want users to entered data to into my webform and be submitted to my database is there an easy way to replicate my tables fields in a form. Like gridview for input.
I can manually sit here and create tables and add textboxes etc in html but seems a little redundant when the tables are already visible in the database explorer.
Want to be sure I am not taking the long version of an easy process. There are plenty of easy forms and tables for viewing database data but what about for submitting it?
The back-end is completely Separate from the UI. At a later date it might be decided to group the fields in a different order, etc. Using a GridView only adds unnecessary overhead.
From a UI design perspective, you should not have too many form fields on a single page as the user is less likely to complete the form - basic usability issue. If this is the case, try splitting up the fields using a Wizard control and perhaps keep the user informed of their progress ( page 2 of 5, etc.).
So I have a .Net website I made and part of it is a page where a database table can be filtered, queried, and displayed. Then I allow users to select an individual row to either edit or delete. Both of these functions are performed on their own separate pages. Recently I was asked to add functionality to the first page to allow for the query filtering to be preserved between visits. For example, if a user edits a row then returns to the table, the filters they selected should still be in place.
My question is what's the easiest way to do this. The problem is that many of the filters are dynamically generated based on another table in the DB so they aren't statically coded into the page. One option would be passing the filter string in the query string but this seems unpractical because of the possible great length it may be. I also thought about opening a new window but there are concerns about security and data duplication. I could also use an iframe to load the pages and hide the original content until done editing but I'm not sure how to access clicks from within the iframe in the surrounding page, or if this is even a good idea.
Any help/suggestions would be greatly appreciated.
Thanks!
You could encapsulate your functionality into a User Control that both pages can use.
How to: Convert Web Forms Pages into ASP.NET User Controls
You could use a SESSION variable to store a Dictionary<string, object> or something similar which contains keys identifying each table and values representing the filter. The actual filtering options shouldn't be too much information to store for a given session.
Without knowing how your application captures the concept of a filter it's a little difficult to offer a fully-qualified solution, but session seems like a decent option.
You can keep the filter in a cookie on the user side. Granted not a perfect solution but it's one way to go.
We have about 10 applications that basically do the same thing, all written using the Wizard Control for .Net 2.0. The flow they follow is pretty simple:
1. User selects option from a drop downs.
2. Next page has more options more narrowed.
3. User sees confirmation page.
4. Report is generated.
Some of these applications have optional pages, such as allowing the user to upload custom images for the report and allowing the user to select specific lines of data.
I'm attempting to merge these applications, but I'm not sure I'm approaching this the correct way. My first inclination is to create configuration tables in SQL to drive the menus that appear. So, for example, there might be a table with the WizardId, Name, Theme, etc., also a table of steps, and another table to link everything together.
Is there an easier way to approach this that I'm just missing?
We've been thinking through this issue lately and I've come up with two options that both seem valid, just have different uses. One way to do it, similar to what you have described, is to create the following:
A table that holds the wizard information
A table that lists the types of questions to be asked in each wizard
A table to hold the data entered by the user for each question
This is very flexible, but the problem is you have to dynamically generate all the controls you need to collect the information (textbox, drop down, radio, file upload, etc) and store how to display that control in your database.
The other approach that we have tried out on a recent project is to associate a user control with either each wizard or type of wizard step. It isn't as modular, but you have a lot of control over how the controls are arranged and how you collect the data.
I think both approaches are useful in different scenarios. Going with a database driven approach allows you to generate new questions and wizards easily, but lacks the user friendly approach that we wanted for our new application.
I'm about to create a web application that requires a lot of different web forms where the user needs to be able to input a lot of different types of information. What I mean is that one of those forms may require some text input fields, some integer input fields, some decimal input fields, some date input fields, some datetime input fields, etc.
I would like to have a, maybe JavaScript-based, control library that I can simple provide with some text labels, input types and default values. The control library would then somehow render the form in HTML without me having to create an HTML table, select the appropriate standard web controls and all that.
I have used dhtmlxGrid to create quite a lot of tables and that works well for me. What I need now is something that can help me in a similar way when creating something like card forms.
I have also found ActiveWidgets, but it looks like it will require a lot of work on my behalf. I'm not only looking for individual web controls, but rather something like a library that can help me with the overall card.
I'm guessing many of you have had this problem before. Looking forward to hearing what solutions you have found to be the best. BTW: I'm working in VisualStudio with ASP.NET.
I would be tempted to look at Ext JS for this.
Ext JS
have you had a look at InputEx
I know it doesn't answer the question, but I have always written my own, or rather written it once and tweaked it for other apps. When I store the questions in the DB I store what input type it is, then on the form I dynamically create the appropriate control depending on which input type the question needs and add that control to a dynamically created table cell as I go.
If you choose to do that just remember when processing the form that the controls don't exist on postback, you need to recreate them.
It is not too bad to write it, if you have the time. My current form module is running a few dozen forms from the one module.