I am creating a database in MS-Access to manage product specifications. Some products have overlapping specifications and some are unique.
My initial approach to this problem was to create multiple forms. For Example: an extension cord specification needs copper, compound and plug information. This information is also needed for a power strip specification, as well as other information that is ONLY pertinent to power strips. Currently I have created multiple forms for the different products. Is it possible to save multiple forms into a pdf for the same part number?
I know I can create a long form that is split on different pages, this method could work if I could not save or print certain pages depending on the product too. Any help is greatly appreciated.
I have shown in the picture below a portion of the forms and how some information is relevant only to the product class.
I know I could create forms for a basis of every category of inventory, but then I would have to create a full specification form for over 10 products, I am trying to streamline and reduce the amount of front end work required to generate specs from our database
Related
Using jqGrid free (version 4.15.6) to show very basic information about invoices (ie: date created, date due, client, total, status). The invoices grid only has a few pertinent columns that are displayed because it is just not needed to show more than that. In reality there are a lot of other invoice-related fields that are not shown. I would like to offer end-users the ability to filter the grid based on a lot of these other parameters that are simply not part of the grid contents.
I know jqGrid offers built-in searching, and you can easily just add hidden columns with all the data, but I feel this is not good for us--invoices contain a lot of data--data that is not necessarily present in just the invoices database table. We want the grid to provide many other filtering options outside of the base invoice data but we do NOT want to use the built-in filter options. Instead, I would like to use a separate HTML table with a bunch of search fields that our server-side code would know how to pull back). When one decides to invoke the external filter, we want the grid to load all invoices matching that combined filter. And if one chooses to navigate using the grid's paging buttons, we want the grid to continue using the original external filtering parameters.
Hope this makes sense. Maybe I am just overthinking this but I am fairly certain the grid is designed to use it's built in filtering/searching tools/dialog and I have not found anyway to override this behavior. Actually I have using an older jqGrid but that involved using jQuery to completely REPLACE the default pager with custom HTML and event handling. I never could figure this out with older jqGrid so I chose to write it myself. But that code is less than optimum and even I know it is subject to much criticism. Having upgraded to 4.15.6, I want to do this the best way and I want to keep it logical and practical.
I have tried using beforeRequest() and onPaging() events to change the 'url' parameter, thinking that if I modified the url, I could change the GET to include all of our custom filtering fields. It seems that does not work as the url NEVER changes from the originally defined value. Console logging does show the events firing but no change to url. On top of that, the grid ALWAYS passes its own page field, _search field, etc. to the server so the server NEVER sees the filter request.
How does one define their own custom filtering coupled with paging loader and still take advantage of the built-in paging events? What am I missing?
**** DELETED CODE THAT WAS ADDED TO QUESTION THAT DID NOT PERTAIN TO ORIGINAL QUESTION ISSUE *********
It's difficult to answer on your question because you didn't posted code fragments, which shows how you use jqGrid and because the total number of data, which could be needed to display in all pages isn't known.
In general there are two main alternatives implementing of custom filtering:
server side filtering
client side filtering
One can additionally use a mix from both filtering. For example, one can load from the server all invoices based on some fixed filters (all invoices of specific user or all invoices of one organization, all invoices of the last month) and then use loadonce: true, forceClientSorting: true options to sort and to filter the returned data on the client side. The user could additionally to filter the subset of data locally using filter toolbar of searching dialog.
The performance of client side is essentially improved last years and loading relatively large JSON data from the server could be done very quickly. Because of that Client-Side-Filtering is strictly recommended. For better understanding the performance of local sorting, filtering and paging I'd recommend you to try the functionality on the demo. You will see that the timing of local filtering of the grid with 5000 rows and 13 columns is better as you can expect mostly from the round trip to the server and processing of server side filtering on some very good organized database. It's the reason why I recommend to consider to use client side sorting (or loadonce: true, forceClientSorting: true options) as far it's possible.
If you need to filter data on the server then you need just send additional parameters to the server on every request. One can do that by including additional parameters in postData. See the old answer for additional details. Alternatively one can use serializeGridData to extend/modify the data, which will be set to the server.
After the data are loaded from the server, it could be sorted and filtered locally before the first page of data will be displayed in the grid. To force local filtering one need just add forceClientSorting: true additionally to well known loadonce: true parameter. It force applying local logic on the data returned from the server. Thus one can use postData.filters, search: true to force additional local filtering and sortname and sortorder parameter to force local sorting.
One more important remark about using hidden columns. Every hidden column will force creating DOM elements, which represent unneeded <td> elements. The more DOM elements you place on the page the more slow will be the page. If local data will be used (or if loadonce: true be used) then jqGrid hold data associated with every row twice: once as JavaScript object and once as cells in the grid (<td> elements). Free jqGrid allows to use "additional properties" instead of hidden columns. In the case no data will be placed in DOM of the grid, but the data will be hold in JavaScript objects and one able to sort or filter by additional properties in the same way like with other columns. In the simplest way one can remove all hidden columns and to add additionalProperties parameter, which should be array of strings with the name of additional properties. Instead of strings elements of additionalProperties could be objects of the same structures like colModel. For example, additionalProperties: [{ name: "taskId", sorttype: "integer"}, "isFinal"]. See the demo as an example. The input data of the grid can be seen here. Another demo shows that searching dialog contains additional properties additionally to jqGrid column. The commented part columns of searching shows more advanced way to specify the list and the order of columns and additional properties displayed in searching dialog.
Forgive my answering like this but this question started out on one subject related to filtering and paging but with using an external filtering source. Oleg actually has several demos over many threads that I was able to use to accomplish the custom filtering and maintain default built-in paging. So his answer will be the accepted answer for the original question topic.
But in the solution of original, I encountered another issue with loading the grid initially. I wanted to have the grid load with default filtering values should no other filter already be in place. That really should have been a different question because it really did not affect the first.
I found yet another Oleg reply on a completely different question:
jqGrid - how to set grid to NOT load any data initially?.
Oleg answered that question and that answer solved our second need to load one way, then allow another way.
So, on initial load, we look for the filter params server-side. None given? We pull records using default filtering. Params present? We use initial provided params. The difference with initial loading we do not AJAX exit. We instead json_encode the data and place it in the grid definition as follows:
$('#grd_invoices').jqGrid(
...
url: '{$modulelink}&sm=130',
data: {$json_encoded_griddata},
datatype: 'local',
...
});
Since the datatype is set to 'local', the grid does NOT go to server initially, so the data parameter is used by the grid. Once we are ready to filter, we use Oleg's solution from yet another answer on yet another question to dynamically apply the filter as follows:
var myfilter = { groupOp: 'AND', rules: []};
myfilter.rules.push({field:'fuserid',op:'eq',data:$('#fuserid').val()});
myfilter.rules.push({field:'finvoicenum',op:'eq',data:$('#finvoicenum').val()});
myfilter.rules.push({field:'fdatefield',op:'eq',data:$('#fdatefield').val()});
myfilter.rules.push({field:'fsdate',op:'eq',data:$('#fsdate').val()});
myfilter.rules.push({field:'fedate',op:'eq',data:$('#fedate').val()});
myfilter.rules.push({field:'fwithin',op:'eq',data:$('#fwithin').val()});
myfilter.rules.push({field:'fnotes',op:'eq',data:$('#fnotes').val()});
myfilter.rules.push({field:'fdescription',op:'eq',data:$('#fdescription').val()});
myfilter.rules.push({field:'fpaymentmethod',op:'eq',data:$('#fpaymentmethod').val()});
myfilter.rules.push({field:'fstatus',op:'eq',data:$('#fstatus').val()});
myfilter.rules.push({field:'ftotalfrom',op:'eq',data:$('#ftotalfrom').val()});
myfilter.rules.push({field:'ftotal',op:'eq',data:$('#ftotal').val()});
myfilter.rules.push({field:'fmake',op:'eq',data:$('#fmake').val()});
myfilter.rules.push({field:'fmodel',op:'eq',data:$('#fmodel').val()});
myfilter.rules.push({field:'fserial',op:'eq',data:$('#fserial').val()});
myfilter.rules.push({field:'fitemid',op:'eq',data:$('#fitemid').val()});
myfilter.rules.push({field:'ftaxid',op:'eq',data:$('#ftaxid').val()});
myfilter.rules.push({field:'fsalesrepid',op:'eq',data:$('#fsalesrepid').val()});
var grid = $('#grd_invoices');
grid[0].p.search = myfilter.rules.length>0;
$.extend(grid[0].p.postData,{filters:JSON.stringify(myfilter)});
$('#grd_invoices').jqGrid('setGridParam',{datatype:'json'}).trigger('reloadGrid',[{page:1}]);
This allows us to have the grid show initial data loaded locally, and then subsequent filtering changes the grid datatype to 'json', which forces the grid to go to server with new filter params where it loads the more specific filtering.
Credit goes to Oleg because I used many of his posts from many questions to reach the end result. Thank you #Oleg!
Recently within our team, we were discussing to create a generic form creation tool which can create dynamic form with desired fields (text box, drop down, radio button etc. etc.)
the user can add as many as fields he wants to add (though normally it would not exceeds more than 20), can share the form with other users who can answer the questions or it could be simply just a data entry form for the single user.
We are trying to execute this step by step and in the first phase we would be doing something like:-
the user will have the option to create a new form.
there would be few predefined fields exists i.e. name label and textbox, address label and textarea, state drop down with some values, gender radio with options and some other sample fields.
above-displayed fields on the newly created form are just to help user to understand what kind of different fields he can create.
user can add/ delete fields, fields type would be textbox, textarea, dropdown, radio, multi-select checkbox etc.
after completing the desired fields user would save the form with "create form" button. entire data -field type, their values if it is drop down radio, will get saved in the database.
To access the form user will access the URL like form/5 and fill it and save.
We are creating a dynamic form and saving the form inputs as well.
My Initial Thoughts
When user will create a new form entire data would be saved as a single JSON object on NoSQL database.
when other or same user try to access the created from to fill the values same JSON object will be fetched and HTML would be created, In phase 2 we would might need a JSON to HTML converter program. but to keep it simple for now, we would just generate HTML from JSON at the client side. (web app/mobile app)
after users complete their inputs and save it. a new JSON object will be saved in another table named Records.
I read somewhere that for reporting and analytics purpose relational database is recommended so I was thinking of Maintaining all data in another relational database as well, duplicating our entire database. I am not sure about this and it could be a bad design.
This application can replace our several applications - some survey application, few data forms thus no. of records could easily reach into millions.
I am looking forward to any suggestion on the architecture/design and database type.
https://www.makeuseof.com/tag/finest-14-google-forms-alternatives-try/
Update 1: I agree with #SerejaBogolubov comment and not looking for the High-level/low-level design that includes Classes, Interfaces, their relations, functions and design patterns.
The question mentioned few steps and building block I would be using at the start and would like to know about various recommendations and thoughts.
Honestly, I see no design ideas in your post. The place you gonna save (and format of the text file or whatever else) is secondary. Design is about interfaces, functions signatures, applied patterns, etc.
As a suggestion, you (obviously) have to separate form representation from the way it is rendered. Thus something like FormRepresentation -> Html appears. Then the question is how you gonna structure your FormRepresentation? I would suggest a (monoidic) binary operation: FormItem -> FormItem -> FormItem also known as kind of Composite OOP pattern; within associativity of the composition you might get parallezation for free and avoid performance headache, as well as keep your signatures really simple yet meaningful.
So, that was just a sketch. I would offer you to update your post appropriately such that design details (rather than implementation details) become clear.
I need to design about 20 forms for various business processes.
We have to do this for about 10 countries and need some form of object prietnted approach because each country has different business rules and some different bits of data. However, there is also common data between some of these countries.
For example, we have 5 bits of data, 4 are common to every country, 1 is specific for individual countries.
eg common Name, Address, Telephone, Male/Female
eg Bonus payment
It's a question of how do you manage all the code changes easily in an enterprise application without the code being too unwieldy?
It's not just the languages, that would essentially be driven by a config code that lists the names for the lables...but also each form may have most of it's design from a gloabl form and then less from a local form, local to the specific country.
Isn't there some way to build a dynamic form on the fly so that you have 1 form ProcessBonus for every country, that form inherits fields from MainForm, and then it checks configuration Class in the background to build the form dynamicaly for each country?
I'm trying to avoid having 10 form types and then another 100 local forms for each country, that would be well over 1000 forms and would be unmanageable wouldn't it?
Actually what you need to achieve is Multiple Inheritance. .Net technologies , PHP, FLEX etc some other languages doesn't support multiple inheritance. Thus, Interfaces are used as a hack to achieve multiple inheritance.
You can find the implementation of interfaces in this link.
http://www.codersource.net/MicrosoftNet/CBasicsTutorials/CNetTutorialInterfaces.aspx
!!! UPDATED !!!
We have spreadsheets of complex product data coming in from multiple sources (internal, customers, vendors).
Since the authorship is so diverse, it's impractical to try governing formatting details such as column order and the number of header-rows.
These CSV spreadsheets will be uploaded to our DB via an existing form.
(My first Zend_Form ... I'm almost done with it)
The user needs to see a sample from a given spreadsheet so they can Map the columns and start-row.
To achieve that, I need to generate an html table of that dynamic content, and weave the form elements in and around the table data.
The user would select which values are to be found in each column, and identify the first row of data (after any header rows).
CLICK HERE to see an example.
(NOTE: Most of my work here is under an NDA, so contrived examples is the best we can get :)
In this example, I'd expect the output to be:
_POST('first_row'=>2, 'column0'=>'mi', 'column1'=>'lName', 'column2'=>'fName', 'column3'=>'gender')
With all those scpecifics mapped/defined, the uploaded spreadsheet can then be parsed and accurate data can be added to the product_history database.
Is ZF a good tool for this particular problem, or should I just write something from scratch?
How would you aproach this?
I am finally JUST BARELY starting to get this ZF stuff straight in my head, and this one has got me totally lost :)
Any and All advice appreciated.
~ Mo
I think in your case, using Zend_Form would be helpful for this situation.
The tricky part to it is of course that your forms are going to be largely dynamically generated on-the-fly based on the header and first row content of the CSV file.
Whether you used Zend_Form, or pure PHP, or some other solution, a lot of what you will be doing is the same (analyzing the CSV, providing dynamic inputs based on the CSV, and then error checking the selections). I think using Zend_Form has the advantage of making something like this very cleanly.
Given Zend_Form's nature, e.g. how it validates existing forms based on the elements added to the Zend_Form itself, you need to take a special approach with the form. Basically, after the user uploads the CSV once, you will create a Zend_Form object based on the number of columns, their positions in the CSV, and the name of the column.
Since you don't want to bother the user to upload the CSV multiple times if they make incorrect selections, I would parse the CSV into some sort of structure, maybe a simple object or array, and then build your Zend_Form based on that data. This way, you can save that structure to the session, so you can continue to regenerate the form based on the parsed data without having to read the file each time. This is because the main challenge with Zend_Form and dynamic forms, is that not only does the form need all of the elements and their properties when you want to display the form, but they are also required in order to validate the form and re-display the validated form.
I remember seeing this functionality many years ago in a PHP script, which I found is still available. Perhaps you could look at it for ideas. I won't post the link here since the screenshots and script are mostly adult website related and the site is NSFW for the most part, but it is called TGPX by JMBSoft. The 7th of the 8th screenshot on the main product page shows the import process where it lets the user map fields to data, exactly what you are doing.
Hope my advice is helpful, feel free to comment with any questions.
What are some possible designs to deal with frequently changing data forms?
I have a basic CRUD web application where the main data entry form changes yearly. So each record should be tied to a specific version of the form. This requirement is kind of new, so the existing application was not built with this in mind.
I'm looking for different ways of handling this, hoping to avoid future technical debt. Here are some options I've come up with:
Create a new object, UI and set of tables for each version. This is obviously the most naive approach.
Keep adding all the fields to the same object and DB tables, but show/hide them based on the form version. This will become a mess after a few changes.
Build form definitions, then dynamically build the UI and store the data as some dictionary like format (e.g. JSON/XML or maybe an document oriented database) I think this is going to be too complex for the scope of this app, especially for the UI.
What other possibilities are there? Does anyone have experience doing this? I'm looking for some design patterns to help deal with the complexity.
First, I will speak to your solutions above and then I will give my answer.
Creating a new table for each
version is going to require new
programming every year since you will
not be able to dynamically join to
the new table and include the new
columns easily. That seems pretty obvious and really makes this a bad choice.
The issues you mentioned with adding
the columns to the same form are
correct. Also, whatever database you
are using has a max on how many
columns it can handle and how many
bytes it can have in a row. That could become another concern.
The third option I think is the
closest to what you want. I would
not store the new column data in a
JSON/XML unless it is for duplication
to increase speed. I think this is
your best option
The only option you didn't mention
was storing all of the data in 1
database field and using XML to
parse. This option would make it
tough to query and write reports
against.
If I had to do this:
The first table would have the
columns ID (seeded), Name,
InputType, CreateDate,
ExpirationDate, and CssClass. I
would call it tbInputs.
The second table would have the have
5 columns, ID, Input_ID (with FK to
tbInputs.ID), Entry_ID (with FK to
the main/original table) value, and
CreateDate. The FK to the
main/original table would allow you
to find what items were attached to
what form entry. I would call this
table tbInputValues.
If you don't
plan on having that base table then
I would use a simply table that tracks the creation date, creator ID,
and the form_id.
Once you have those you will just need to create a dynamic form that pulls back all of the inputs that are currently active and display them. I would put all of the dynamic controls inside of some kind of container like a <div> since it will allow you to loop through them without knowing the name of every element. Then insert into tbInputValues the ID of the input and its value.
Create a form to add or remove an
input. This would mean you would
not have much if any maintenance
work to do each year.
I think this solution may not seem like the most eloquent but if executed correctly I do think it is your most flexible solution that requires the least amount of technical debt.
I think the third approach (XML) is the most flexible. A simple XML structure is generated very fast and can be easily versioned and validated against an XSD.
You'd have a table holding the XML in one column and the year/version this xml applies to.
Generating UI code based on the schema is basically a bad idea. If you do not require extensive validation, you can opt for a simple editable table.
If you need a custom form every year, I'd look at it as kind of a job guarantee :-) It's important to make the versioning mechanism and extension transparent and explicit though.
For this particular app, we decided to deal with the problem as if there was one form that continuously grows. Due to the nature of the form this seemed more natural than more explicit separation. We will have a mapping of year->field for parts of the application that do need to know which data is for which year.
For the UI, we will be creating a new page for each year's form. Dynamic form creation is far too complex in this situation.