Need a dynamic Subform

[SaranacLake]

I want to build a webpage where an employee can key in an order, including the order details.

Building an entry form for just the order is easy enough, because it is simply one webpage with a set number of fields.  And when you need to enter in a new order, you simply load a new blank form.

But the order details part seems trickier, because one order can have one-to-many order details, and so I need a subform that expands as more items are entered.

For instance, let's say this is in a restaurant, and a large group of people walk in.  There is no telling how many items they might order, but I would need a way to let the waiter keep adding items to their bill as long as necessary.  

On the web, I'm not sure even where to begin with this?!   

 

 

Edited May 18, 2019 by SaranacLake

[requinix]

There are two basic ways you approach this: either you have the subform as a "template" in your Javascript and you keep adding copies of it as needed, or you use AJAX to load a new subform from the server.

Which makes more sense to you?

[ginerjm]

One of the first things you need to do is design your database.   It is obvious that you will need a pure 'orders' table to register each single order, probably using an "order_no' column as the key.  Then you will need a second table that holds those 'sub-form' entries, the line items.  Those would have a key of order_no and some sequential number to differentiate each line item from all of the others on that order.   So - design your table and show us how it looks and while you're at it you may start to see how your web page(s) will look.  Be careful how you name your columns and use intelligent names as well, ie, don't just label it "item" when "item_no" would be more clear.

[nik_jain]

Use JavaScript to keep adding more input fields. I suggest to use jQuery for this . See jQuery docs or google to find how to append elements using jQuery. Something like:

if (clicked on last form element){
	$parentForm.append('<input>New elements />')
}

This will require learning and getting familiar with jQuery and maybe javascript as well.

This is the frontend part. You will also need to pass these new form values to server. For this Each field should have a unique 'name' html attribute or you can use an array See this. Then handle the POST data with PHP.  And store appropriately in a database.

[Barand]

Use the forums code boxes (<> button on the toolbar) and stop posting black text on a black background.

[nik_jain]

@Barand - sry didn't realise about the black text on black background thing, as I was using a 'dark night extension'

[ginerjm]

If JS/JQ is not yet in your vocabulary, I suggest simply using php to do your line item posting.  It's easy.  Create a form to handle all of the item fields and when submitted add them to your "item" table.  You can then sned them back out on that same form using an html table that will contain all of the rows of already-posted items with a form for another entry.  You could also add a column to that html table to edit a row which you would handle by re-sending the same page with the values for that row in the entry form along with the key values so that your script will properly post it when re-submitted.

[SaranacLake]

10 hours ago, requinix said:

There are two basic ways you approach this: either you have the subform as a "template" in your Javascript and you keep adding copies of it as needed, or you use AJAX to load a new subform from the server.

Which makes more sense to you?

I guess you answered one question, in that I need to handle this on the client side, right?

As far as your comments above, I'm not sure I entirely understand what you mean, since I don't know Javascript.

How difficult would it be to learn how to do all of this?  I have a good idea in my head what I want, but am just unsure where to begin since this is on the web.

 

[SaranacLake]

4 hours ago, ginerjm said:

One of the first things you need to do is design your database.   It is obvious that you will need a pure 'orders' table to register each single order, probably using an "order_no' column as the key.  Then you will need a second table that holds those 'sub-form' entries, the line items.  Those would have a key of order_no and some sequential number to differentiate each line item from all of the others on that order.   So - design your table and show us how it looks and while you're at it you may start to see how your web page(s) will look.  Be careful how you name your columns and use intelligent names as well, ie, don't just label it "item" when "item_no" would be more clear.

Thanks for the reply.  My background is with databases, so yes, I feel very comfortable with the data model part.  It's just that I have been away from programming for several years, and my web programming skills are "light" (e.g. I don't know any of the fancy Javascript stuff).  When I did used to do web development, it was mostly html pages/forms and serverside PHP, although I think I even forgot how to do that!

 

As far as the database part, just doing this on the fly, I'd likely have this...

	CUSTOMER
	- id
	- and so on...
	 
	ORDER
	- id
	- order_date
	- vendor
	- location
	- subtotal
	- discounts
	- taxes
	 
	ORDER_DETAILS
	- id
	- order_id
	- product_id
	- unit_sale_price
	- quantity
	 
	PRODUCT
	- id
	- name
	- description
	- unit_price
	- category
	- and so on...
	

 

What I really need help with is figuring out how to build a control for the order details that acts like a spreadsheet where you can keep adding row after row as long as the customer is ordering more items.

 

[SaranacLake]

1 hour ago, ginerjm said:

If JS/JQ is not yet in your vocabulary, I suggest simply using php to do your line item posting.  It's easy.  Create a form to handle all of the item fields and when submitted add them to your "item" table.  You can then sned them back out on that same form using an html table that will contain all of the rows of already-posted items with a form for another entry.  You could also add a column to that html table to edit a row which you would handle by re-sending the same page with the values for that row in the entry form along with the key values so that your script will properly post it when re-submitted.

If I understand you, that is the design I am trying to avoid, i.e. a static order details form with a finite number of entry fields.

Let's say this was for Walmart and not a restaurant - although the problem exists in either - and Customer A buys one banana.  That is easy to design a subform for that,  - I could just have 5-10 slots and I'm safe.

But let's say that Customer B is buying a monthly order for their family of 15...  There could be HUNDREDS of order details, and you just cannot program a static subform and *hope* there are enough slots - plus it would look sloppy.

How hard is Javascript to learn?

While I want to keep learning, what I do NOT want is to get stuck spending learning Javascript all summer long. 

If I accept this new project, I would need to turn around a working prototype in under a month, and then once I have someting that at least works, then I can more easily invest time to becoming a Javascript guru while I work on version 2.

 

[ginerjm]

Quote

 

You will design a static order form and a dynamic table of line items for the order.  It is not finite and you will not specify how many there are.  No "5-10".  And you won't store any total values - they are always obtained by doing a query of the records in your item table and calculating the total at that time.

[mac_gyver]

 

6 hours ago, ginerjm said:

If JS/JQ is not yet in your vocabulary, I suggest simply using php to do your line item posting.  It's easy.  Create a form to handle all of the item fields and when submitted add them to your "item" table.  You can then sned them back out on that same form using an html table that will contain all of the rows of already-posted items with a form for another entry.  You could also add a column to that html table to edit a row which you would handle by re-sending the same page with the values for that row in the entry form along with the key values so that your script will properly post it when re-submitted.

 

5 hours ago, SaranacLake said:

If I understand you, that is the design I am trying to avoid, i.e. a static order details form with a finite number of entry fields.

ginerjm's reply wasn't about a static form with x predefined sets of input fields. it was about entering one line item of data at a time, submitting the data (where it would be validated, so you can correct any errors as they occur), and then presenting an empty set of input fields for the next data item. the already entered data items would be shown with edit/delete buttons.

to do just the entry of data, you don't need any javascript. you may however want to use javascript to do auto-suggest item selection. you should not expect the user to be typing in a large amount of item information. your user interface should allow selecting from existing items to help prevent data entry errors.

your code layout would be -

post method form processing, for Create(insert), Update, and Delete operations. you would trim and validate input data, storing validation errors in an array. if there are no validation errors, use the submitted data in an appropriate sql query.

retrieve any existing order item data and display with edit/delete buttons for each item.

if there are validation errors, display the form (which has only one set of input fields), re-populating the field values from the submitted form data. the user would correct any errors and re-submit the form.

if there are no validation errors, display the form with empty field values. the user would enter the next set of data values and submit the form.

[SaranacLake]

Does this website not support BBCode?  (It's a real PITA to use...)

 

> ginerjm's reply wasn't about a static form with x predefined sets of input fields.

> it was about entering one line item of data at a time, submitting the data (where it would be validated,

> so you can correct any errors as they occur), and then presenting an empty set of input fields for the next data item.

> the already entered data items would be shown with edit/delete buttons.

 

Okay, I follow you/him now.  The problem is that I don't want to do things piecemeal because that isn't how you'd do data entry in the real world.

If this was for an order, at the top of the page you would enter customer and order information, and then below that on the same screen you would enter the order details for as long as necessary.  (It would be insane to enter the customer and order info, click "Submit", and then get another page to enter the 1st item out of 100 items, click "Submit" and then get a another screen to enter the 2nd of 100 items and so on!!)

With just PHP, you would either have to hard-code in A LOT of blank line item fields or do what you are are proposing, but neither really represents how the real world works, which leads me to think I need Javascript - which i don't know.

Edited May 19, 2019 by SaranacLake

[ginerjm]

My approach was to accomodate your skills.  Sure - you can build a complex form that encomapasses everything but that's a PIA itself.  Don't know what you mean by "a log of blank line item field" either.

BTW - You could rename the "id" field to be "cust_id" to make it very clear what it is.  And I don't think you need 'cust_id' on the product table.  The products are generic and used by all customers eventually.  And 'category' should be a 'category_id' pointing to a table of various category names.  Also I think you need some thought on how to store the discounts amount.  You define a unit price in the product table and than a unit sale price in the item table and the discount at the order table as a whole.  I think you may want that discount amount moved to the item table to apply it on each item.  You may also have a discount at the order level but I'm thinking of a quantity discount for any individual item, as a "sale" discount on certain items.  And again - name them more appropriately.