Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 6 of 6
  1. #1
    New to the CF scene
    Join Date
    May 2008
    Posts
    8
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Simple, generic (re-usable) function for dynamic addition of FORM elements

    Fellow programmers,

    I recently created a simple, generic (re-usable) JavaScript function for dynamic addition of FORM elements with the belief that many organizations need to collect all sort of data using FORM with variable elements and their length.

    Here it is, Re-usable JavaScript Function for Dynamic Addition of FORM Elements
    Feel free to play with it.

    And btw, I'm in Orland, Florida.

    Don

  2. #2
    Temporarily banned
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    1,667
    Thanks
    2
    Thanked 238 Times in 228 Posts
    "Feel free to try it by clicking on the [+] button below."

    What [+] button?

    Like a lot of scripted forms, I'd be worried mostly about the lack of graceful degradation; there's a reason scripted form generation is a giant middle finger to large swaths of users. That under the hood it's tables for layout (and even as tables it's semantic gibberish) with no fieldsets or labels? Way to tell people not on that perfect mix of screen size and pixel density to go **** themselves!

    It also feels like it's more complicated than just writing the HTML properly in the first place... sadly that describes a lot of this type of scripting.

    My overall impression? You don't know enough about HTML or CSS to be writing scripting that makes forms... as evidenced by outdated, outmoded, non-semantic GIBBERISH table abuse like this:

    Code:
    <tr> 
                    <td align="left"> First Name</td>   
                    <td align="left"> Last Name</td> 
    				<td colspan="6"></td>
    				</tr>
    				
    				<tr>  
    				<td valign="top"><input type="text" name="firstName1" id="firstName1" size="20" value="Enter first name..." onclick="document.getElementById('firstName1').value='';"></td> 
    				<td valign="top"><input type="text" id="lastName1" name="lastName1" size="20"></td> 
    				<td colspan="6" valign="top" width="25%"><input type="button" name="blankZ2" id="blanZ2" value="+" size="5" onclick="addSection(['firstName','input','text',20],['lastName','input','text',20],['insertBefore','propFlag4','',0]);"> 
        	</td>
    More so with the scripting doing placeholder's job, the COMPLETE lack of semantic relationship between what should be <label> tags and their associated inputs... and even if it WERE tabular, those first two TD should be TH... epic fail at web design and development.

    Do you know what a fieldset is? a label? Have you heard of the placeholder attribute? Do you know why tables for layout and tables in forms is garbage?

    Even just this:

    Code:
    <table width="90%" border="0" cellspacing="1" cellpadding="1">
    		        <tbody><tr> 
                    <td colspan="8"><span>DEEDS</span> </td> 
                    </tr> 
    	            <tr> 
                    <td align="left"> Document Type</td>   
                    <td align="left"> INS #/Page</td>          
                    <td align="left"> Cons./Loan Amt.</td>          
                    <td align="left"> Dated</td>          
                    <td align="left"> Recorded</td>                  
                    <td align="left" colspan="2"></td> 
                    </tr>
    colspanned TD doing caption's job, td+align doing TH's job, no THEAD... fith four attributes that haven't existed on the table element since 1998... that's some serious derp right there.

    Even IF that were to be a tabular data (which it clearly isn't) that would be:

    Code:
    <table class="deeds">
    	<caption>DEEDS</caption>
    	<thead>
    		<tr>
    			<th scope="col">Document Type</th>
    			<th scope="col">INS #/Page</th>
    			<th scope="col">Cons./Loan Amt.</th>
    			<th scope="col">Dated</th>
    			<th scope="col">Recorded</th>
    			<td colspan="2"></td>
    		</tr>
    	</thead><tbody>
    But again, NOT that said code should be used since that's not tabular data and those TH should be labels NEXT TO their fields and not separate from them halfway across the page telling non-visual users to bend over.

    I don't know who taught you to write HTML that way, but that's broken 15+ year out of date nonsense that wasn't even good practice THEN. Hell, even your show/hide section doesn't actually need scripting anymore to be done!

    You might want to learn to use HTML properly before making some giant bloated scripted mess.

    Oh, and given the behavior on exiting fields after visiting them once, you might want to read up on "placeholder is not a label" and "false simplicity".

    3 Types of False Simplicity - Articles - Baymard Institute
    https://www.nngroup.com/articles/for...-placeholders/
    Placeholder Attribute Is Not A Label! | Web Axe

  3. #3
    New to the CF scene
    Join Date
    May 2008
    Posts
    8
    Thanks
    0
    Thanked 0 Times in 0 Posts
    wow, never expect such vicious attack! what else can I say?

    1) Key value is to let junior developers to use / call this function to allow the addition of FORM elements without scratching head for coding
    2) Since such FORM is for considerable collection of data, mobile device is simply not suited (as stated).

    Additional comments:
    a) It does not make any fu??ing sense not to use TABLE for a good purpose.
    b) It has only 254 lines of code, but you accused it of "bloated".

    I have no idea of your motivation of attack.
    Last edited by justmejustme; 11-03-2016 at 04:31 AM.

  4. #4
    Temporarily banned
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    1,667
    Thanks
    2
    Thanked 238 Times in 228 Posts
    Quote Originally Posted by justmejustme View Post
    wow, never expect such vicious attack!
    Laugh is, that was watered down after three re-edits.

    Quote Originally Posted by justmejustme View Post
    I have no idea of your motivation of attack.
    I am an accessibility and usability advocate, who understands the POINT of HTML. You have outdated, outmoded, broken methodologies on your page that wholesale tells large swaths of potential users to go shove it up their backside! That's what your broken, incomplete, malformed markup and pointless scripting seems to entirely be based around.

    MAYBE you just haven't learned that about HTML, but with statements like this:

    Quote Originally Posted by justmejustme View Post
    It does not make any fu??ing sense not to use TABLE for a good purpose.
    It is clear you simply have either not been taught, or have failed to understand the POINT of HTML.

    HTML is for saying what things ARE, and NOT what they look like. That's why all the tags (other than <div>, <span>, and <a>nchor) have specific meanings and roles. H1..H6 means the start of sections and subsections, NOT "text in different sizes". HR means a change in topic where heading text is unwanted or unwarranted, NOT "draw a line across the screen". <p> means a grammatical paragraph, NOT "I want a double-break after this content".

    In that way <table> means tabular data, where the headings (th), rows (tr), cells (td) all have semantic relationships that can be established using the scope="" or axis="" attributes. You don't just use it because "I want columns" as the first time someone lands on the page with a screen reader or braille reader, you've told them to sod off!

    Are you familiar or at least even heard the term "tables for layout" and ANY of the reasons that it is bad -- bad in things like making it harder to make it mobile friendly (which for most of your claims of "considerable data" is mostly unfounded, you're just using broken layout methodology)

    Are you even at all familiar with <caption>, <fieldset>, <label>, <th>, <thead>, <tbody>? From what you have there it's clear that you're not. If you can't be bothered to use the tags correctly or form even the simplest of your markup semantically, well...

    Quote Originally Posted by justmejustme View Post
    1) Key value is to let junior developers to use / call this function to allow the addition of FORM elements without scratching head for coding
    Not seeing how what you have is any "easier" in that regard... seems more complex in fact though your using two to three times the markup certainly isn't helping. Again, I don't think you ever learned how to create a well formed form using all the tags that belong in a form (fieldset, label, legend) properly... which is what led you to throw scripting at it for no reason.

    Similarly you have the broken outdated "JS for nothing" rubbish of the onevent attributes. These don't even EXIST on newer sites/hosts that have started implementing the "new" (if a DECADE can be called new) Content Security Policy... and you've got them doing the placeholder attribute's job!

    Much less with the BROKEN implementation you have there, you enter a value, blur the field, reselect it, and the value you just typed in goes AWOL...

    Basically you've got this:
    Code:
    <input type="text" name="documentTypeY1" id="documentTypeY1" size="60" value="Enter a Mortgage Here..." onclick="document.getElementById('documentTypeY1').value='';">
    Doing what in MODERN code would be:

    Code:
    <input type="text" name="documentTypeY1" id="documentTypeY1" size="60" placeholder="Enter a Mortgage Here...">
    NOT that a placeholder (or the outdated artsy garbage scripted disaster equivalent) should be used for that since that's a LABEL tags job so that it's ALWAYS labeled. Hence those links I pointed at and even the specification itself saying:

    The placeholder attribute should not be used as a replacement for a label. For a longer hint or other advisory text, place the text next to the control.
    https://www.w3.org/TR/html5/forms.ht...lder-attribute

    Even with the scripted method that should NEVER have been done on websites in the first place, your approach is broken and incomplete... and unnecessarily complex since if you're GOING to use the onevent attributes we're NOT supposed to use anymore, just use 'this' instead of the slow getElementById!

    Your external script is really no better; writing to the document with innerHTML forcing a reparse instead of using the DOM properly, failing to copy essential attributes so users are left GUESSING as to what any of your copies are, failing to properly clone the node you want to clone...

    It's code like this that leads to broken hard to use bloated sites -- it's just clear you don't understand HTML enough to be making stuff for "Junior Developers" to be using in the first place!

    Sorry if that seems harsh or vicious, but it's the truth. You're using 1990's development methodology that was never actually valid or proper to begin with! Your code wholesale tells the audience for HTML (aka everyone, NOT JUST people on perfect size screens at the magical 16px font size with perfect vision) where to stick it!

    It's almost like you're learning from W3Schools or something...

    You need to learn more about HTML, specifically ALL the tags you are supposed to use and what they MEAN... You need to ease up on the "JavaScript for nothing" which is what about a third of your codebase actually is and learn all the things we can do very simply with CSS now instead of scripting.

    I'm on my way back to bed (Insomnia + non-24 sleep-wake disorder sucks) but if I find time tomorrow I'll do a rewrite to show you what I mean. I don't want to discourage you or make it sound like I'm not trying to help -- but really we need to fast-track your education about HTML, CSS, and JavaScript if you're going to try and make tools like this... before you start spreading around your faulty, broken, and outdated understanding of web technologies!

    But just to give you an idea what I mean: Your show/hide part?

    Code:
    <div id="#instructions">
    	<!-- your instructions here -->
    </div>
    
    <a href="#instructions" class="showInstructions"></a>
    <a href="#" class="hideInstructions"></a>
    Put the instructions in the DIV. Set to display:none or better hide off screen so braille/screen readers aren't left out in the cold. #instructions:target {} make it show. Then use generated content to populate the anchors as appropriate with adjacent sibling tags.

    You could also abuse a checkbox for this if you don't like the internal href's filling up the history, but on something like this the ability to hotlink to the page is the more desirable approach.

    Let's take your "deeds" section of your form... it has no real reason to vary much from:
    Code:
    <form action="#" method="post">
    	<h2>Deeds</h2>
    	<fieldset id="deeds" class="duplicate">
    		<label>
    			Deed Document Type<br>
    			<input type="text" name="deed_type[]"><br>
    		</label><label>
    			INS #/Page<br>
    			<input type="text" name="deed_insNumPage[]"><br>
    		</label><label>
    			Cons./Loan Amt<br>
    			<input type="number" name="deed_consLoadAmt[]"><br>
    		</label><label>
    			Dated<br>
    			<input type="date" name="deed_dated[]"><br>
    		</label><label>
    			Recorded<br>
    			<input type="date" name="deed_recorded[]"><br>
    		</label><label>
    			Grantor<br>
    			<input type="text" name="deed_grantor[]"><br>
    		</label><label>
    			Grantee<br>
    			<input type="text" name="deed_grantee[]"><br>
    		</label>
    	</fieldset>
    With CSS handling your desired layout, NOT abusing a table for something it's not meant for... A little responsive layout planning in the mix and boom, you can make it tablet friendly! (Might want one or two DIV to aid with that grouping some of those labels together). That way you aren't STUCK with the single layout that table is shoving down the user (and designer's) throat.

    I don't normally wrap with <label> preferring the for="" method, but in this case it would be easier to clone from the scripting so you don't have to pass the structure of that fieldset in the JS as you'd not have to worry about normalizing your ID's. No for="", the ID becomes optional.

    In fact the button to clone the fieldset could/would/should be auto-added by the script since it's a scripting ONLY element.

    ... and don't know if you've ever seen that name format, but using an empty [] will automatically generate an index every time there's a duplicate. This CAN go tits-up face-down on you if you start DELETING them, but if your only option is to add them, you're fine. One could always add a scripted index using a data- attribute as a hint or just scanning through the existing fieldsets.

    While that would be the proper semantic markup (semantic being a sick euphemism for "using HTML properly") if indeed this were to be scripting only telling users who block scripting to go plow themselves, I'd move ALL of the code into the scripting and generate it there, putting a NOSCRIPT tag in the markup instead.

    I'll toss together some CSS and scripting to show you what I mean tomorrow... but with a proper semantic structure like fieldsets and labels, it's relatively simple to just do a nodewalking clone.

    There's an old saying, your JavaScript is only as good as the HTML it is applied to... which is why it's important to know how to use HTML properly, and not just slop it out any old way completely ignoring EVERY structural rule and grammatical meaning of the tags you are using!

    BTW, NOT saying you have a bad concept -- it's just your implementation needs help.
    Last edited by deathshadow; 11-03-2016 at 09:10 AM.

  5. #5
    Regular Coder Strider64's Avatar
    Join Date
    Dec 2011
    Posts
    192
    Thanks
    5
    Thanked 29 Times in 29 Posts
    It's the truth and not a vicious attack.....

    While I don't agree with deathshadow on everything and sometimes I fall into the trap of taking it too personal myself, there is one thing that deathshadow doesn't do. That one thing is that he doesn't do is sugarcoat the truth, in my opinion telling the truth from the start is better than being mislead into thinking the code that you are writing is worthy. I agree with deathshadow in that you need to know HTML/CSS better and that your HTML is gibberish. That by adding javascript on top of the HTML only makes for more gibberish.
    Last edited by Strider64; 11-03-2016 at 01:51 PM.
    "A person who never made a mistake never tried anything new." ~ Albert Einstein

  6. #6
    Temporarily banned
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    1,667
    Thanks
    2
    Thanked 238 Times in 228 Posts
    ... and got waylaid by life, but here's an example of what I mean:

    Fieldset Duplicating Demo

    as with all my examples the directory:
    Index of /for_others/justmejustme/ - CutCodeDown

    is unlocked for easy access to the gooey bits and pieces. I added some DIV to help with specific styling groups when making it responsive:

    Code:
    			<fieldset class="deeds duplicate" data-duplicateButton="Add Deed">
    				<div>
    					<label>
    						Deed Document Type<br>
    						<input type="text" name="deed_type[]"><br>
    					</label><label>
    						INS # / Page<br>
    						<input type="number" name="deed_insNumPage[]"><br>
    					</label>
    				</div><div>
    					<label>
    						Cons. / Loan Amt<br>
    						<input type="number" name="deed_consLoadAmt[]"><br>
    					</label><label>
    						Dated<br>
    						<input type="date" name="deed_dated[]" placeholder="mm/dd/yy"><br>
    					</label><label>
    						Recorded<br>
    						<input type="date" name="deed_recorded[]" placeholder="mm/dd/yy"><br>
    					</label>
    				</div><div class="who">
    					<label>
    						Grantor<br>
    						<input type="text" name="deed_grantor[]"><br>
    					</label><label>
    						Grantee<br>
    						<input type="text" name="deed_grantee[]"><br>
    					</label>
    				</div>
    			</fieldset>
    The 'duplicate' class is the trigger to say we want the scripting to add a button to let us make new a new copy of this set of fields. The optional data-duplicateButton atttribute is there to say what text goes in that button -- if omitted the button will say "add row"

    I prefer having meaningful text in such buttons since a uselessly vague tiny little [+] tells me jack *** and is easily lost in the shuffle. That's part of why I linked to Baymard's "false simplicity" article earlier. (Your script crashes in Vivaldi, so I wasn't even getting those buttons here!)

    The script itself is pretty simple, at roughly a third the size of yours:
    http://www.cutcodedown.com/for_other...fsDuplicate.js

    Whilst certainly SOME of the savings comes from letting CSS handle that show/hide part (something I just wouldn't use JS to do anymore) more of it comes from doing a cloneNode of the parent and then walking the DOM of the clone to erase values from it as needed. It also updates ID's and FOR attributes so if desired one could use the for/id pairing of label/input instead of the wrapping method -- though for simplicity of styling and keeping the number of DOM elements low, I went with the wrapping labels for this case.

    ... and because I made it with labels and DIV for grouping sub-sets for styling (without saying what that styling is) most any layout is possible -- instead of the crappy fixed layout the table would saddle you with. That's WHY tables for layout on NON-TABULAR DATA is and has been utter/complete nonsense, and only existed as a HACK in the late 1990's from the pissing contest Nyetscape and Microshaft had over who could make their browser the flashiest.

    A contest Microsoft won by actually implementing a usable version of CSS 2 draft whilst Netscape sat their spinning their wheels in the mud. It's often easy to forget that when they were released, IE 5, 5.5 and 6.0 were in fact the most standards compliant browsers of their time!

    No tables for layout, similar visual styling, grouping sets, fully semi-fluid elastic responsive design that gracefully degrades scripting OR CSS off.

    I also put the show/hide styling in a media query and used generated content for the button texts, so that legacy browsers who can't handle :target will hide/ignore the empty buttons and show the instructions text all the time.

    THAT is how you build HTML semantically (again semantic just being a sick euphemism for "using HTML properly") using proper separation of presentation from content, with application of responsive style that is friendly to EVERYTHING, whilst using far, FAR less scripting to leverage that semantic markup for functionality enhancements.

    ... and since to trigger it all you have to do is add the "duplicate" class to your fieldset and include <script src="fsDuplicate.js"></script> right before your </body>, it's far FAR easier for a greenhorn to use than expecting them to shove some massive object at the scripting using those onevent="" attributes in the markup -- attributes we've been told to stop using and that don't even EXIST if you're working under the Content Security Policy!

    Does that help explain why I said your HTML was gibberish and your code was bloated? Replaces 4.65k of broken table nonsense with less than 1k of markup... and replaces 9k of JS with 4k. In other words, you had three to four times the code necessary!

    Which you ended up with likely because you weren't taught how to use HTML properly, much less leverage semantic HTML from the scripting via things like cloneNode and walking the DOM.

    In Soviet Russia, the DOM walks you...
    Last edited by deathshadow; 11-05-2016 at 03:40 PM.


 

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •