I am very new to React to JS and also this is my first question to the community so please help me.
I want to create a table which will display the data from a JSON file (it should display some 50 rows per page), also I need the capability to modify the data in the same table and later update the contents of the JSON accordingly.
I need to have the following types of cells in the table: Normal uneditable text box, editable text box, Select Lists (showing data from another JSON file), Number fields, calendar, etc..
I know it might feel like a stupid question to many of you but please help me understand how to approach this problem.
(I am not asking for working code, please help me on how to get started with it.)
Thank you.
Tons of libraries on github can do what you need.
For example:
https://react-bootstrap-table.github.io/react-bootstrap-table2/
https://github.com/tannerlinsley/react-table
https://material-ui.com/demos/tables/
There are many many others, which one should be used is based on your detail requirement and then find the best fit.
For table :
1. Create a component
2. Store the json value in state.
3. construct table. In tbody use state.map and return rows.
For uneditable text-box make it read-only.
we want to realize the following:
Generate PDF with Template,which means set value in AcroFields
Create a big details table (structure of table is also in template). In this progress, the details will occupy more than one page.
If the detail table is on multi pages, the header of the table should be also on top of the new page.
We found some examples on following website:
http://kuujinbo.info/cs/itext_template1.aspx
http://kuujinbo.info/cs/itext_template2.aspx
But the details the founction is omitted there.
Add content; the code for _do_form_fields(), _get_transaction_details(), and _transaction_summary() are omitted, since they only return strings to add to ColumnText. ColumnText is smart; each call to Go() renders as much text that will fit on the current page and returns a status code that tells you: (1) how much text (to write) is remaining, and/or (2) how much space is still available on the page. On each iteration you add text to the current page, call ColumnText.HasMoreText() to inspect the status, and then Document.NewPage() if necessary.
Is there anyone who had same situation before? We are appreciated that you could offer some tips or suggestions.
Thank you.
best regards,
Cheng Gong
You are already making a mistake in the first step of your requirements.
You say "Generate PDF with Template,which means set value in AcroFields."
The first part is OK: you want to generate a PDF with a template. However, this doesn't mean setting values in AcroFields. That's only one option. It's the option you take if you consider PDF being the digital equivalent of paper. The form is static: every coordinate is fixed. You just fill out data at the appropriate places. If the data doesn't fit the designated areas, you're out of luck. I already referred to chapter 6 of my book in a comment. You can also see how AcroForms work in a longer tutorial: https://www.youtube.com/watch?v=6YwDME0Fl1c (This tutorial is almost completely dedicated to creating a report from a data set.)
Another way to create PDF from a template is by using the XML Forms Architecture. In this case (if you have a pure XFA form), your PDF is a container for XML. You can then inject XML data into this form and the form will adapt itself depending on the data. A one-page form can easily grow into a 20-page document when filled out. This is explained in this video: https://www.youtube.com/watch?v=h0wzj84tnmw (Note that the video dates from 2012. The product I present has been finished and the results are much better now.)
Alternatives to this approach could be to create a template in HTML. I often refer to this solution as a poor man's XFA solution. This solution requires XML Worker. You can see an example in this video: https://www.youtube.com/watch?v=clWoDrEEl50
This is a general answer. I couldn't be more specific because your question isn't clear. You first need to make your mind up regarding the approach. Right now, you talk about AcroFields and at the same time about ColumnText. In the long tutorial, this is described as the hard way. See also the corresponding online samples. It is very confusing why you're asking a very difficult question before asking the simple questions. Unless of course, you already have the answer to those simple questions. If so, please share these answers.
I am struggling myself thinking about which component to use in my new app.
The first screen I am using Collection View with big images. Once the user touches one cell, it goes to the second screen ... and here is the problem.
I have three columns, similar to a dictionary with first language, second and third. The user will be able to choose which column he wants to search, and according to his criteria it will show the result that matches. I am not sure how to implement this, which component gives the best experience to the user. Any idea is more than welcome. Thank you in advance. Alex
If your data is several rows each with 3 columns, I would recommend customizing a UITableView. I followed this tutorial when I was trying to set up something similar.
The Table View will also give you efficiency if you have a lot of data, and you can build the custom table cells in the interface builder so that makes life a little easier.
-Ken
I am building a form for parents to enter health information for their students. Our nurses want to build it similar to what you fill out when you see a new doctor where they have categories and then conditions within the category that you would check if they apply to you. They want the number of categories and conditions to be variable so they can change them willy nilly as desired.
I need some ideas as to how to approach the UI side. My initial thought is a parent gridview with a row for each category and then inside that, a child gridview for each condition with its own checkbox. I already do a bit of work with gridviews and know how to access the nested objects so I'm not terribly worried about how to get the data back.
My question is this: Is there a better way and what suggestions would the community make that might be different or more efficient than using nested gridviews?
+1 for asking is there a better way?
What I'm about to suggest may end up being a little more complicated at first, but rest assured it will be worth it in the end.
There is a JavaScript framework named Knockout.js that is perfect for situations like these. Knockout vastly simplifies situations that where a variable amount of UI controls are needed.
http://knockoutjs.com/
Here is a tutorial on the website that has a similar situation to yours:
http://learn.knockoutjs.com/#/?tutorial=collections
I'm using asp.net and I need to build an application where we can easily create forms without recreating the database, and preferably without changing the create/read/update/delete queries. The goal is to allow customers to create their own forms with dropdowns, textboxes, checkboxes, even many-to-one relationship to another simple form (that's stretching it). The user does not have to be able to create the forms themselves, but I don't want to be adding tables, fields, queries, web page, etc. each time a new form is requested/modified.
2 questions:
1) How do I structure a flexible database to do this (in SQL Server)? I can think of two ways: a) Create a table for each datatype (int, varchar(x), smalldatetime, bit, etc). This would be very difficult to create the adequate queries. b) Create the form table with lots of extra fields and various datatypes in case the user needs 5 integers or 5 date fields. This seems the easiest, but is probably pretty inefficient use of space.
2) How do I build the forms? I thought about creating an xml sheet that had the validations, data type, control to display, etc. as a list. Then I would parse through the xml to build the form on the fly. Probably using css to do the layout (that would have to be manual, which is ok).
Is there a better/best way? Is there something out there that I could look at to get ideas? Any help is much appreciated.
This sounds like a potential candidate for an InfoPath solution. At first blush, it will do most/all of what you are asking.
This article gives a brief overview of creating an InfoPath form that is based on a SQL data source.
http://office.microsoft.com/en-us/infopath-help/design-a-form-template-based-on-a-microsoft-sql-server-database-HP010086639.aspx
I have built a completely custom solution like you are describing, and if I ever did it again I would probably opt for either 1) a third-party product or 2) less functionality. You can spend 90% of your time working on 10% of the feature set.
EDIT: reread your questions and here is additional feedback.
1 - Flexible data structure: A couple things to keep in mind are performance and the ability to write reports against the data. The more generic the data structure, the harder these will be to achieve (again, speaking from experience).
Somewhat contrary to both performance and report-readiness, Microsoft SharePoint uses XML fragments/documents in generic tables for maximum flexibility. I can't argue with the features of SharePoint, so this does get the job done and greatly simplifies the data structure. XML will perform well when done correctly, but most people will find it more difficult to write queries against XML. Even though XML is a "first class citizen" to SQL Server, it may or may not perform as well as an optimized table structure.
2 - Forms: I have implemented custom forms using XML transformed by XSLT. XML is often a good choice for storing form structure; XSLT is a monster unto itself, but it is very powerful. For what it's worth, InfoPath stores its form structure as XML.
I've also implemented dynamic forms using custom controls in .Net. This is a very object-oriented approach, but (depending on the complexity of the UI) can require a significant amount of code.
Lastly (again using SharePoint as an example), Microsoft implemented horrendously complicated XML list/form definitions in SharePoint 2007. The complexity defeats many of the benefits. In other words, if you go the XML route, make your structures clean and simple or you will have a maintenance nightmare on your hands.
EDIT #2: In reference to Scott's question below, here's a high-level data structure that will avoid duplicated data and doesn't rely on XML for the majority of the form definition.
Caveat: I just put this design together in SQL Management Studio...I only spent 10 minutes on it; developing a flexible form system is not a trivial task, so this is an over-simplification. It does not address the storage of user-entered data, just the definition of the form.
The tables:
Form - top-level form table which contains (as you would guess) the collection of fields that comprise the form.
Field - generic fields that could be reused across forms. For example, you don't want 50 different "Last Name" fields for 50 different forms. Note the "DataTypeId" column. You could store any type you wanted in this column, like "number, "free text", even a value that indicates the user should pick from a list.
FormField - allows a form to contain 0-many fields in its definition. You could even extend this table to indicate that the user can ADD as many of this field as they need.
Constraint - basically a lookup table that defines a constraint type (maybe it's max length, max occurrences, required, etc.)
FormFieldConstraint - relates a constraint to a particular instance of a form field. This table combines a specific form with a specific field with a specific constraint. Note the metadata column; this potentially would be a good use for XML to store the specifics of the constraint.
Essentially, I suggest building a normalized database with few or no null values and no duplicated data. A structure as I've described would get you on the path to that goal.
I think if you need truly dynamic forms saved into a database, you'd have to create a sort of "dictionary" data table.
For example...
UserForms
---------
FormID
FieldName
FieldValue
FormID relates back to the parent form (so you can aggregate all of the fields for one form. FieldName is the name of the text field entered from. FieldValue is the value entered/selected for that field.
Obviously this isn't a perfect solution. You could have issues typing your data dynamically, but I leave the implementation of that up to you.
Anyways, hopefully this gives you somewhere to start thinking about how you'd like to accomplish things. Good luck!
P.S. I've found using webforms with .NET to be a total pain when doing dynamic form generation. In the instances I had to do it, I ditched it almost entirely and used native HTML elements. Then rewired my form by using the necessary values from Request. Probably not a perfect solution either, but it worked the best for me.
We created a forms system like the one you're describing with a schema very similar to the one at the end of Tim's post. It has been pretty complicated, and we really had to wrestle with the standard WebForms controls like the DetailsView and GridView to make them be able to perform CRUD operations on groups of answers. They're used to binding straight to properties on an object, and we're forcing them to look up a field ID in a dictionary first. They don't like it. You may want to consider using MVC.
One tricky question is how to store the answers. We ended up using a table that's keyed on FieldId, InstanceId (for example, if 10 people are filling out your form, there are 10 instances), and RowNumber (because we support multi-row forms for things like employment history). Instead of doing it this way, I would recommend making your AnswerRow a first-class concept with its own table tied to an Instance, and having the answers be linked to the AnswerRow and Field.
In order to support different value types, we had to create multiple answer fields on our answer table (AnswerChar, AnswerDate, AnswerInt, AnswerDecimal). Each of these maps to one or more Field Types (Date, Time, Number, etc.). Each Field Type has its own logic to represent the value in the UI, and put the value into the appropriate property on our answer objects.
All in all, it's been a lot of work. It's worth it for us, since this is the crux of the product, but you will definitely want to keep the cost in mind before embarking on a project like this.