I've a question about best practices in javascript.
I've a dropdown menu with some statuts. If the statut is : external, I want to display a form. I don't know the best way to do this. Do i need to hide a DIV from the DOM and display him when i need it or do i need to generate my form dynamically in jquery and make a call ajax to populate some data.
It really depends on your application. If you already have a lot of elements in the DOM, and the likelyhood of actually needing to show this form is low, you may want to add it later (using ajax) because in most cases you don't need it anyway. However, if your DOM load is light, and in most cases the form will be shown, you make want to have it ready and hidden so that is can be quickly shown.
There is also a middle ground where you can "lazy load" it (using javascript on page load), and keep it in a json object until it is ready to be used. This will keep your DOM responsive, and give the added benefit of a quicker load of the form.
it depends on the probability of user clicking on that element and number of elements already present in the DOM. I suggest to create form runtime whenever user performs action instead of hiding it. There are some browser plugins which shows all hidden elements in a page.
Unless your page is unusually large already or there are a lot of different forms like this that could be used from the same page, putting the HTML into the page and just starting out with it hidden gives you the advantage that all your markup is in one place (in the HTML file that represents your page) and can more easily be centrally maintained that way.
When you start putting markup into your javascript, you split up the maintenance of the markup between both the HTML of the page and the HTML that is embedded into your page.
If, on the other hand, you had a lot of these forms that were all slightly different that could all be used from the same page, then it gets messy to pre-specify all possible combinations of the form in the original HTML and you would probably be better off dynamically generating it via javascript or perhaps generating it from a template with slight modifications.
Related
I am working on an old legacy application which used document.forms[index] approach to access elements in the form and to submit the form. My task is to add a new top panel with few textboxes and buttons. I am using a form for this. This top panel is to be included in all the pages in the application. Now, all the pages stop working since form[index] needs to be updated in all the pages. I know using the form name is the best approach. I have around 1000 places to change. What is the best approach to avoid this problem? I still want to use form for my top panel since I am using spring forms to get the data. Any valuable advice will be appreciated. Thanks.
If you looked up the definition of "unmaintainable", that would be a good example.
One trick might be to leave one set of forms, hidden, with the legacy stuff in them, then make another set, lower in the HTML, that the user sees. Then use some JavaScript to map the data back into the original forms in order to continue to work with the expectations of the legacy code. This keeps everything in the same index-order.
I'm creating a webform using a marketing automation platform. I want to add a field that functions with jquery to do an autocomplete. Unfortunately, the forms are generated through a WYSIWYG editor in the software, and then generated and put into the page when it renders. The only code for the form that appears in the HTML for the page is a simple variable placeholder - %%FORM::DEFINITION%% - which is then replaced with the form code when you visit the URL. The software support team tells me that making the change I want to make is impossible, which I see as a challenge.
The only thing I need to be able to do is add an id="autocomplete-dynamic" attribute to the input on the form. I had two ideas how I could achieve this.
The first, and most preferable option, would be some script that runs at the bottom of the page that simply inserts the attribute into the input tag after the page renders out. This would only be a client-side change, but since all this does is make the text field capable of looking up values out of another table, it should be fine. If someone had a script blocker in place, they would not be prevented from typing into the text field normally, it's just that the auto-lookup wouldn't work. We're trying to make it easier to select an item from a list of thousands of possibilities, but if someone had to type in their own entry without the autocomplete, it would not be a disaster. This seems like a clean solution, but I am not sure if it can be done.
The other possibility is to get the form code out of the software and embed it in a separate HTML document, and make the change there. You can extract the raw HTML for the form for use on another page, but pasting this code right back into the landing page causes errors. So, the thought then was that if I have taken the code generated by the software and put it in an HTML page on a separate web server, I could modify it as needed, and then turn around and use an iframe to stick it right back in the landing page. The software shouldn't complain because the form is being used on an external site like it's supposed to be... I have just hidden that external site back inside the platform-hosted page.
Option 1 would still be much easier to implement, I think, provided it is actually possible.
Thanks in advance.
Your first solution seems completely appropriate.
$(function() {
$('#myForm input').attr('id', 'autocomplete-dynamic');
});
This can be added anywhere inside a script tag because it's wrapped in a shorthand document.ready function, which waits to run until the DOM is ready.
I am with affiliate programs that give you little forms to put on your website, but often times they're entirely composed of javascript (so, no HTML tags , ID's or classes are inside of them).
These probably pull in forms using AJAX. JS or JQuery cannot display page elements by themselves, for that they need HTML. What you can do is use the Chrome Developer Tools to find the IDs or classes in the form they load in, and then after the AJAX call edit the form from there.
If there's a form then it has to ultimately draw elements into the DOM for the page to render. There's always a way to get at those nodes if you really need to, but if they don't include IDs or names then you'll have to walk the tree and look for specific relationships based on what you see in the finished page. It will definitely be a PITA, but it's doable.
I'm working on a web app where in I need to add some values inputted by the user.
When the user clicks on the Add button he sees a form and these values then show up on the page. Now to implement this I can do two things
Use a modal window
Make a form inside the page itself(in a div) and toggle its visibility by the Add button.
If I go with the former solution is it necessary to use Ajax or I can add elements on the main page directly itself? Are there any jQuery plugins to accomplish the same?
As Diodeus mentioned, you don't need Ajax.
In answer to your other question about the plugins, have a look at jQuery UI Dialog for the dialog. Generating the form is pretty trivial. There's no need for a plugin there
You don't need to use Ajax to accomplish this. The difference in the two methods is simply whether you use an inline block of code that is hidden and displayed later, or whether you use an absolutely-positioned block of code doing exactly the same thing.
In most cases there is a single form that envelops the entire page. The rest is a matter of a CSS and positioning.
I am trying to figure out the best way to acompish "unobtrusive" forms for a user (within a web app).
The purpose: keep user on the site by not asking to fill unnecessary form in. Ask for the details as only when such are needed.
The requrements are:
User should provide additional details only when it is required (email to receive notifications, login required for account page, save credit card details when checking out).
User should not leave the current page providing the additional details.
The implementation would be fairly easy if all requests would be AJAX ones. It would be easy to analyse the response (401 or so) and show the appropriate lightbox-form.
I do not see how it can be done "the right way" with plain anchors and form submits as in both cases the user actually leaves the page (by following the link or submitting a form) and there is no way to analyse the response on the client side.
Converting all links and forms to AJAX ones would be just silly.
The closest analog to what I want to achieve is the default Basic Authentication dialog in most of the browser. But obviously that just doesn't fit my requirements.
Any creative suggestions how to do that for non-AJAX requests?
Regards,
Dmytrii.
In a page sense, where "page" refers to what the user sees and not what the URL is, I only can think of following ways to update independent parts in a page with JavaScript (and thus Ajax) switched off:
Frames
Iframes
Using held-open connections there are two more ways to update a page, however these do not work reliably in all cases:
Animated GIF
CSS DIV tags with absolute positioning.
Note that this needs that your Server can keep open a session for each person looking at the page, which can be thousands. If this does not work the only possible workaround is with FRAMEs and automatic refresh, which is somewhat clumsy.
As I think that you do not want to use Frames and you do not want to render animated GIFs, I explain the CSS DIV way:
When you load the page you do not finish loading it. Instead the connection is kept open by the web server and the script handling the connection waits for additional information to arrive. When there is additional data, this is sent to the browser by encapsulating it into additional DIV tags which can overwrite other parts of the page.
Using "style" in the DIV tag and CSS position:absolute these can overwrite other information on the page like a new layer. However you need either position:absolute or must add this data to the end of the page.
How does this work with forms?
Forms usually have a known size so you can put them into IFRAMEs. These IFRAMEs get submitted to the webserver. The script there notifies the other script that new data must be output, so the waiting script renders the response and displays it in the page while the script which took the submit redisplays the form with fresh values only.
How does this work with 404 and anchors?
I don't really know because this must be tested, but here is a hint how I would try to implement this:
We have 2 issues here.
First the URL must not point to other pages but back to a server script again, so the href is under control. This script then notifies the waiting script to update the page accordingly, for example by retrieving the page and sending it to your browser. The script can check for 404 as well.
Second you must hinder the browser to switch the page when clicking on the anchor. This probably involves some clever tricks using CSS, target and server side status codes (like "gone" or redirect to the current page, whatever) to keep the browser from switching the page. I am not completely sure if that works, but if you remember download pages, these show URLs which do not switch the page but have an effect (downloading the file). That's where to start to try to hack browsers not leaving the current page without using JavaScript.
One idea not followed here is not keeping the connection of the page open but the CSS file and send new css information to the browser which then "fills in empty stubs" using the CSS way. But I doubt that this works very well, most browsers probably will parse the CSS only after loading finished, but perhaps I am wrong.
Also note that keeping a connection open never finishes the page loading, so you will see the busy-logo spinning all the time, which is unavoidable with this technique.
Having said this all I doubt you get around JavaScript.
What I wrote here is very difficult to do and therefor usually is not used because it scales badly. And it is a lot more difficult than using JavaScript alone (that's why I explained it).
With proper AJAX it is much more easy to reach your goal. Also note that you do not need to change your page source much, all you need is to add a script which augments the page content such, that for example forms suddenly use AJAX instead of a direct POST with re-rendering the page. Things which cannot be detected easily then need some hints in the tags such that the tag scanner knows how to handle the tag. The good thing then is, that with JavaScript switched off your page still works - however it then "leaves the page".
Normal HTML just was not designed to create application-like web pages like we want to see today. This all was added using JavaScript.
About popup forms
The Basic-Auth-Handler reloads the page after the user enters something into this dialog, only if cancel is hit the current page is displayed.
But there are two ways to present additional query-popups in a page using JavaScript:
The first one is the javascript "prompt", like in following example:
http://de.selfhtml.org/javascript/objekte/anzeige/window_prompt_vor.htm
(Click on the "Hier").
The second one is "JavaScript forms" which are like popups within an HTML-page.
However I consider popups to be far too intrusive and bad design.
Ajax and JavaScript is the easiest way
Unfortunately using JavaScript is never easy, but if you think JavaScript is improper or too difficult, there is no other technique which is easier, that's why JavaScript is used everywhere.
For example your page onload-Script can cycle through all Anchor-Tags and modify them such, that clicking on them invokes a function. This function then must do something clever.
Same is true for Forms. Fields which can be modified (like the user's eMail address) then have two views, on is visible, the other one hidden. The hidden one is a form. Clicking on the eMail address then switches the view (disables the first div and enables the second), such that suddenly instead of the eMail address a text form field is there containing the eMail address. If you click on the "OK" button the button changes the look into a spinner until the data is submitted, then the view switches back to the normal one.
That's the usual way to do it using JavaScript and Ajax. And this involves a lot of programming until it works well.
Sorry for not shortening this post and missing code snippets, I am currently lacking time ;)
Hidden iframe.
Set target attribute of the form to the name of the iframe. use the onload event of the iframe to determine what is the response.
Or, if you really dont like any javascript, don't hide the iframe and instead present it in a creative manner.
CSS to hide an element
#myiframe { position:absolute; left: -999em; display: none; visibility: hidden; }
But normally, display: none is enough. This is just an overkill.