Hello Is there a reference or sample code somewhere that demonstrates how tos of developing a master details form using HTML5/CSS3? I need to develop this for Customer (master record) and its addresses(detail records). A customer can have multiple addresses. So all addresses will be in a detail multi-record data grid look like form or block for its corresponding master customer record. Hope this makes sense. Please advise Darsh
No it doesn't. Post your code so there is some point of reference and we can see what you are trying to do.
Yeah, "master details" is vague at best, meaningless at worst... dog of a time deciphering the engrish moist goodry. What HTML 5 or CSS3 even has to do with it is beyond me since nothing has changed from HTML 4 on that front apart from some new type attribute values -- you'd need a server-side language like PHP and a database like mySQL to do anything meaningful with it. But if I'm following your question at all, you have a person's main record with their name, and multiple addresses. This is more of a SQL question in concept so you'd have a unique ID on each user, and a field in the addresses table that would hold that same ID as a reference, with a separate unique ID for each address. "users" id INT NOT NULL AUTO_INCREMENT username CHAR(126) NOT NULL PRIMARY KEY (id) "addresses" id INT NOT NULL AUTO_INCREMENT user_id INT NOT NULL address1 CHAR(126) address2 CHAR(126) city CHAR(126) state CHAR(2) zip CHAR(10) INDEX(user_id) addresses.user_id would point at the corresponding users.id Form-wise the easiest way to handle that would be to use the user ID as a suffix on the field ID's and a index on the names so you can have more than one of each client-side, and then also use the unique ID for the address as a suffix/index on each address. A hidden input containing which user ID the address line is for would also be essential... Something like this would be the markup: <form action="whatever" method="post"> <fieldset class="info"> <label for="userName_001">User Name:</label> <input type="text" name="username[001]" id="userName_001"> </fieldset> <fieldset class="address"> <label for="address1_200">Street Address:</label> <input type="text" name="addr[200][address1]" id="address1_200"><br> <input type="text" name="addr[200][address2]" id="address2_200"><br> <label for="city_200">City:</label> <input type="text" name="addr[200][city] id="city_200"> <label for="state_200">State:</label> <input type="text" name="addr[200][state]" id="state_200"> <label for="zip_200">Zip:</label> <input type="text" name="addr[200][zip]" id="zip_200"> <input type="hidden" name="addr[200][user]" value="001"> </fieldset> <fieldset class="address"> <label for="address1_240">Street Address:</label> <input type="text" name="addr[240][address1]" id="address1_240"><br> <input type="text" name="addr[240][address2]" id="address2_240"><br> <label for="city_240">City:</label> <input type="text" name="addr[240][city] id="city_240"> <label for="state_200">State:</label> <input type="text" name="addr[240][state]" id="state_240"> <label for="zip_200">Zip:</label> <input type="text" name="addr[240][zip]" id="zip_240"> <input type="hidden" name="addr[240][user]" value="001"> </fieldset> <!-- etc, etc, etc for each address per user --> </form> Code (markup): Where 001 is the unique ID of the user, and 200 and 240 are the unique ID's of the addresses. You could then just foreach the addresses as returned. Given this would mean passing a LOT of information client side that probably shouldn't go client side I would be damned sure to store what user and address ID's are being edited in the session, so MITM or post-post attacks are more likely to fall flat on their face -- invalidating those session values when the edited result is submitted. I'd also be VERY careful of what accounts I'd allow to access/edit this information which is why you'd need some good server side verification. What any of that has to do specifically with HTML 5 or CSS3 is beyond me.
correction, to simplify server-side processing, it might be better to just make the user ID the top-most index of the nested array results. <form action="whatever" method="post"> <fieldset class="info"> <label for="userName_001">User Name:</label> <input type="text" name="username[001]" id="userName_001"> </fieldset> <fieldset class="address"> <label for="address1_200">Street Address:</label> <input type="text" name="addr[001][200][address1]" id="address1_200"><br> <input type="text" name="addr[001][200][address2]" id="address2_200"><br> <label for="city_200">City:</label> <input type="text" name="addr[001][200][city] id="city_200"> <label for="state_200">State:</label> <input type="text" name="addr[001][200][state]" id="state_200"> <label for="zip_200">Zip:</label> <input type="text" name="addr[001][200][zip]" id="zip_200"> </fieldset> <fieldset class="address"> <label for="address1_240">Street Address:</label> <input type="text" name="addr[001][240][address1]" id="address1_240"><br> <input type="text" name="addr[001][240][address2]" id="address2_240"><br> <label for="city_240">City:</label> <input type="text" name="addr[001][240][city] id="city_240"> <label for="state_200">State:</label> <input type="text" name="addr[001][240][state]" id="state_240"> <label for="zip_200">Zip:</label> <input type="text" name="addr[001][240][zip]" id="zip_240"> </fieldset> <!-- etc, etc, etc for each address per user --> </form> Code (markup):
Sorry folks, I should have been more clear. I am coming from relational database side where "Master-Detail" term is always understood. I did not know it will be considered vague in web development. my bad. So let me explain in detail. By Master detail I meant, one parent, or group level record can have more than one child records. For e.g. Customer "ABC Barber" has 10 stores across town. That means that customer has 10 addresses. So, in HTM5, you would have one input field on top to enter customer name. And then you will have table grid of input fields (10 grid lines in our example) to enter address details for 10 stores. And then save button. Once save button is clicked, the form saves the records to database and clears the page for new record entry(i.e. new customer and its addresses) after refresh. Now let's say, another customer may have 500 different locations. Then the detail data grid can not be limited to only 10 records, and putting 500 grid lines on HTML form would make the web page look very ugly. So, there needs to be a vertical scroll bar around this grid where one after the another new records can be inserted for 500 different locations in our example. I am only looking for HTML5, Javascript, CSS scripting here. Not expecting any php/python or mysql server side logic at this time. Hope this helps. Darsh
I'm an old school database guy, and the only place I ever heard that relationship used in that sense was in Access... and I never really dealt with Access being more of a dbase/paradox guy. First off, to tell you what HTML to use, we'd need to see a sample of your ACTUAL data fields. HTML exists to say what things ARE, and NOT what they look like, so until we know what the content is, we can't make HTML... or at least we shouldn't. ... and that's HTML, since HTML 5 doesn't add jack **** of any meaning to this topic that didn't already exist. None of it's new tags (that are redundant nonsense) do anything that's actually new in that sense. Really for what you've said, there's also little reason to get scripttardery involved -- all that would do is piss on the accessibility. In general without markup it's impossible to make much in the way of meaningful CSS... but if all you want is a semi-fixed height wrapper that has a scroll bar cutoff past a certain number of rows: HTML: <div class="locations"><!-- put the markup for your locations here --></div> Code (markup): CSS: .location { max-height:20em; overflow-y:auto; } Code (markup): That max height would be the line-height plus any padding/margins on your data lines, times the number of lines you want to show. That said, fixing the height or cutting it off to have a second scrollbar on the screen is considered piss-poor accessibility/usability -- at that point I would first write the it to use LIMIT to create pagination with multiple separate pages.... "page 1 of xxx" at the bottom with links to +/- 5 or so pages. Then if you have bloated rubbish markup on the rest of the page and want to enhance it with scripting, you ajax in the page content. This would save a lot of bandwidth by people not loading values they aren't using or looking at. Really though if you've built the HTML with separation of presentation from content and proper leveraging of caching models, there is NO excuse for a pageload to be noticeably better than AJAXing in values. ... and if scripting is added, you have to keep in mind the unwritten rule of JavaScript -- if you can't make the page work without scripting FIRST, you likely have no business adding JavaScript to it. Again why database engines typically have LIMIT or some similar function. Pull a count of matches, pull a small sampling (10...15 values), and paginate it. Though it SOUNDS like you are thinking in "grids" which is one of the FASTEST ways to piss on the usability and accessibility of a website, particularly if you are thinking about UI design that has a fixed resolution or screen size. If you're coming from native application development -- particularly from things with "form building" nonsense like Access, most of what you know about interface design is the antithesis of how a website is built. Your just SAYING "grid" has me thinking you don't quite grasp what a web layout is yet.
Since you're saying there can be an arbitrary number of locations, depending on what business is being added, I would suggest you make the form dynamic. Create an input field for the business name, and either an input field for the number of entries, or set it at a fixed number, say 10, and add something that will allow to either add one more entry, or a "new page". Personally, I would go with the initial input for the amount of address fields, and just wrap them with pagination. Make sure you add some functionality to check for multiple entries with the same info, and make it possible to show all in one list as that makes it easier to check spelling and other things.
Am I understanding you correctly, you're letting the client/customer make db entries? Do be sure to have robust server-side validation, access control, authorization and authentication. Simple forms may be used. Once your 'master record' is established, the store level data may be entered/edited within one or more fieldsets (restrict the number to a sane value, rather than overwhelming the entry operator) consisting of whatever inputs you need for the location. @deathshadow's example above should work well, as do his comments on page reloads. I would not deal with IDs on the form, as they must be GUIDs and should be best assigned by the DBMS. Also let the mid tier pass the data to the query API. Mid tier, after querying the DB, should question apparent duplicate entries. In other words, this is a mid tier and back end issue. Entries and edits are sent to the right tables and relationships are defiined by the queries If you're retrieving data, then your queries will return an array or list which may be structured in whatever manner seems best for that page. cheers, gary OT @deathshadow: Back in '89 or thereabouts, a friend of mine repped several software companies, not Borland, though. I asked her about the various brands of RDBMSes and spreadsheet apps. After hearing her comparisons of the lines she repped, all top level, I asked which she used. She seemed embarrassed by the question as she answered, Paradox and Quattro Pro. So that's what I bought. ~gt
I guess my education must be lacking. I have worked with relational databases for about 30 years and I have never heard to term which you are using to describe what appears to be a one-top-many relationship. What you are describing looks very error prone and tedious. I'm not sure a web page is the best way to do initial input if you are looking at occurrences as high as 500. That should come in as a text file, or even a spreadsheet and scripting used for the load. What you want seems okay for maintenance if you apply a unique index to the addresses; but I cannot imagine the kind if tantrum you would get if a user was entering 199 of 200 and crashed. Trying to do this with a web page is a design error involving the selection of the wrong tools to do the job. You can mitigate the usability issues with pagination, but from a security standpoint, you better really know your stuff; and the access better really be limited or you are going to be fighting spambots that see hundreds of inputs waiting to be populated.