What would you consider a better practice?
Would you do (in javascript):
var aaa = <s:property value="myValue"/>;
or rather (in a jsp file):
<s:hidden name="myValue" id="myValue" />
with (in javascript):
var bbb = document.getElementById("myValue").value;
Well that depends I think. You can't use struts2 tags in JS files unless you save them as .jsp. In case you do this or you have a JS code in your page, I personally doesn't have a problem with the first option, since the tags will be processed back at server. I use this often when there is a simple assignment.
I don't like the second option cause it makes the code a little ugly and might cause some maintenance problems.
To sum it up it's a better practice to separate your JS and server side codes. If you find yourself mixing things up you might want to look at your design somewhere that could change.
Again that depends on how you prefer to do it.
You can achieve the desired results with both way.only thing matters is individual taste and preferences.
i would not like to mix up the things and will go with the second way using a hidden field.for me it serve 2 purposes.
separating my struts2 tag from the JavaScript.
More over i can write a simple clean JavaScript code with standard JavaScript method rather mixing up the things
There are many ways, including what you've shown.
You may also:
Pass JavaScript files through the JSP processor
Use a different templating language for dynamic JS (like FreeMarker)
Emit a JSON object evaluated before your JS files are included (e.g., the contents of a hidden div are evaluated purely for JS side-effects)
Make an Ajax call for the same JSON object on page load before your functionality fires
Probably a few more. I don't prefer hidden fields unless they're in a form that isn't submitted (like a hidden, separate form) unless it's very clear which form values matter and which don't.
Related
I have a page which has many buttons that perform an action with javascript. No problem here, just a html page and multiple .js file, one .js file for every action. Just to separate stuff a bit and make everything a bit more manageable. I will write a script to combine them all at deployment.
A lot of my javascript actions need html elements to function. For example to change a color the color.js needs a div with form elements so that user can change the color and press the button to save changes. The color.js binds functions to the onClick of the buttons and such. No problem here.
A problem comes up when there are many javascript actions using many html elements. All these html elements need to put into one html page. This makes managing things complicated. For example when i change the color field id i need to go to color.js and do the change. In addition i have to find the html element in my huge html page and also do the change.
Is it possible to put the html elements needed by my javascript actions into the .js file and somehow include it in my html page?
Of course i can escape all html elements and put it in a javascript variable and document.write it. But escaping is not a nice thing to do and changing html afterwards is quite painful.
I'm also not looking for a ajax function, cause with many different actions this will cause network problems.
Cheers for any thoughts on the subject!
You can use templates to generate dynamic HTML via JavaScript. Most of Templates Engines have the same implementation:
A template structure (DOM) or HTML string
A method to render the template
The data that fills the template (Array, Object)
Settings to configure the template engine
I have used some template engines, one of them is Hogan.js which has a friendly sugared-syntax, very easy to use, but lower performance. It implements the Mustache syntax.
Other template engine is in Underscore.js library, which provides no sugared-syntax but a native javascript syntax, giving more power, and best performance.
The last one that I have used is kendo-ui templates.Kendo UI templates have a heavy emphasis on performance over feature glut. It will trade convenient "syntax sugar" for improved performance.
If you want to try more engines, here you can get a lot of them:
Template-Engine-Chooser
By other hand, if you want just to load static HTML (e.g. an static view), you can use jQuery.load(url) to load data from the server and place the returned HTML into the matched element. .load() is a shorthand method of jQuery.ajax()
Recomendation: whichever option you choose, I recommend using cache, either to save the view or to save the compiled template, thus the performance is improved by avoiding request of the same resource.
I have an asp.net website, but I need to pass stuff to javascript to do stuff there. At the moment, I am doing things like this:
<script type="text/javascript">
var userHasMicrositePhoto = '<%=hasMicrositePhoto%>';
</script>
But I've been told that putting lots of script tags in like this is bad, and also its annoying to have to keep writing Properties in my code behind.
What is a better way to do this?
This is pretty much the ideal way to go IMO. If you have a lot of stuff like this, try putting it all in one <script>block. You could also use an array to reduce the code overhead, or have asp.net output a JSON encoded array with all the needed properties in it.
Depending on your architecture, you could consider fetching those properties through a separate Ajax request which would make the page body a bit cleaner, but it would be an extra request that can't be cached, so I would use this only in very extreme cases.
The same applies to embedding a separate <script src=....> it looks nicer in the generated markup, but needs another request to the server.
The only alternatives would be
write a page that generates AJAX and have your JavaScript access
that with XHR
write a page that generates JavaScript and have your
HTML access that with a single script tag
I don't think either of those solutions are obviously superior to what you're doing now, except they could be used by other pages more easily, if that helps.
I would use JSON when you're passing information to be used by javascript.
This may require you to reconsider how you're developing your website or application. I usually use it when the server is passing information via ajax but ajax isn't the only solution.
http://code.google.com/p/aspjson/
http://www.json.org/
I may not quite understand your question though so forgive me if I am totally off.
I am currently writing a program that uses AJAX to load a form for editing objects on a website. I have found a similar question at Loading script tags via AJAX, but it doesn't really satisfy the needs of the program.
The ajax returned is a pre-built set of elements in a form, and when certain areas are called, say, a TinyMCE textarea (which it is), it returns a set of script tags built into the text.
So my question is, is it possible to run through the script tags that have been put in the div and run them?
Plus, I want to avoid using jQuery as it could be running on any number of platforms.
Yes, you can add the incoming html and scripts to the dom, then search the dom for any script tags. You would then eval the scripts and could ignore any jQuery script tags if you wish.
However:
This sort of solution tends to be quite brittle.
It would be much better and more stable for you to modify the Ajax payload into separate html and javascript scripts. That way your Ajax handler would be able to handle them directly without trying to separate them.
Added
Re: how to send back the html and javascript parts: you can either make separate Ajax calls, or return an JSON object that includes both parts. Eg:
{"js": "<the js part of the response>",
"html": "<the html part of the respons>"}
Use a json library on your host system to take care of the issue of escaping any quotes or other json special characters in either the js or html values.
Returning both the html and js at once saves an Ajax call (which can be significant) and will usually simplify your code quite a bit vs two calls.
I use this technique in production and it works well.
Do you mean you return a js script from the ajax and want to run it??If so, you can use the eval function.
We have lots of javascript functions, which are usually handled via the onclick function. Currently they are present in every file where-ever it is needed. Would it make sense to consolidate all javascript functions into a single file and use this where-ever it is needed? What is the general practice here
<s:link view="/User.xhtml"
onclick="if (confirm('#{messages['label.user.warning']}')) {
var f = $('user');
f.method = 'POST';
f.action = f.submit();
} return false;">
Yes! Absolutely factor this out into an external javascript. Imagine if you needed to change something in this code. How many places do you have to change now? Don't duplicate code. It must makes your page bigger, which obviously affects how much is getting downloaded.
It's up to you to determine where the reusability lies in your own code. But it's easy enough (and a good idea) to create a library of often-used functions. Create a file like mylib.js, for instance, with things like...
function saveUser(f)
{
//...
f.method = 'POST';
f.action = f.submit();
}
add this to your pages:
<script type="text/javascript" src="mylib.js"></script>
add code your events like this:
<s:link view="/User.xhtml" onclick="return saveUser($('user'));">
Notice that the library code avoids any dependencies on the layout or naming of elements on the pages that use it. You may also want to leave little comments that will remind your future self what the purpose and assumptions of these library functions are.
Would it make sense to consolidate all javascript functions into a single file and use this where-ever it is needed?
Ummm...yeah
It would be better to do something like this:
function saveUser() {
// logic goes here
}
and use the markup
<s:link view="..." onclick="saveUser();">
Using code inline like that is very bad. Don't do it. Or the prorgamming gods will grow restless.
It is always a good idea to put JavaScript code in JavaScript files. Like you don't mix content and presentation (XHTML and CSS), you don't have to mix content and interactivity (XHTML and JavaScript).
Putting JavaScript code in a separate file has several advantages:
No need to duplicate code (so better reuse),
Possibility to minify the source code, thing which is quite impossible to do if you put together XHTML and JavaScript,
Ability to use non-intrusive JavaScript, helping to create more accessible websites (there is probably nothing wrong from the accessibility point to use onclick and other events, but it becomes very easy to forget that the website must work without JavaScript, thus developing a non-accessible website).
Better client-side performance: larger pages make things slower; when you put JavaScript outside, the pages are smaller, and the .js file is cached by the browser instead of being loaded on every request.
Javascript can be accessed via a script tag, which can point to an external script or define it for use in this document only.
<script type="text/javascript" src="mycustom.js"></script>
<!-- OR -->
<script type="text/javascript">
function saveUser(username) {
//code
}
</script>
No offense, but if you didn't know that you are either very new at this or you skipped a lot of steps in learning javascript. I recommend going through the w3schools.com tutorial on javascript and anything else you'll be using.
When I first started with Javascript, I usually just put whatever I needed into functions and called them when I needed them. That was then.
Now, as I am building more and more complex web applications with Javascript; taking advantage of its more responsive user interaction, I am realizing that I need to make my code more readable - not only by me, but anyone who replaces me. Besides that, I would like the reduce the moments of 'what the heck, why did I do this' when I read my own code months later (yes, I am being honest here, I do have what the heck was I thinking moments myself, although I try to avoid such cases)
A couple weeks ago, I got into Joose, and so far, it has been good, but I am wondering what the rest do to make their chunk their codes into meaningful segments and readable by the next programmer.
Besides making it readable, what are your steps in making your HTML separated from your code logic? Say you need to create dynamic table rows with data. Do you include that in your Javascript code, appending the td element to the string or do you do anything else. I am looking for real world solutions and ideas, not some theoretical ideas posed by some expert.
So, in case you didnt't understand the above, do you use OOP practices. If you don't what do you use?
For really JS-heavy applications, you should try to mimic Java.
Have as little JS in your HTML as possible (preferably - just the call to the bootstrap function)
Break the code into logical units, keep them all in separate files
Use a script to concatenate/minify the files into a single bundle which you will serve as part of your app
Use JS namespaces to avoid cluttering up the global namespace:
var myapp = {};
myapp.FirstClass = function() { ... };
myapp.FirstClass.prototype.method = function() { ... };
myapp.SecondClass = function() { ... };
Using all these techniques together will yield a very manageable project, even if you are not using any frameworks.
I use unobtrusive javascript, so, outside of the script tags I don't keep any javascript in the html.
The two are completely separated.
A javascript function will start when the DOM tree is completed, which will go through the html and add the javascript events, and whatever else needs to be changed.
In order to organize, I tend to have some javascript files that are named similar to the html pages that they use, and then for common functions I tend to group them by what they do, and pick a name that explains that.
So, for example, if I have UI functions then I may call them: myapp_ui_functions.js
I try to put the name of the application in the filename, unless there is some javascript that is common to several projects, such as strings.js.
I have (usually) one file that contains a bunch of functions and that's it. That is included in every page that uses Javascript. In the pages themselves, I'll make the calls to the functions like:
$(function() {
$("#delete").click(delete_user);
$("#new").click(new_user);
});
where delete_user() and new_user() are defined in the external file.
I too use unobtrusive Javascript, which for me means jQuery (there are other libraries that are unobtrusive).
You don't want a separate file for each page. That just means more unnecessary external HTTP requests. With one file—assuming you've cached it effectively—it'll be downloaded once and that's it (until it changes).
If I have a large amount of Javascript or the site is effectively split into multiple areas then I may split the Javascript but that's not often the case.
Also, in terms of my source code, I may have multiple JS files but I'll often end up combining them into one download for the client (to reduce HTTP requests).
More at Multiple javascript/css files: best practices? and Supercharging Javascript in PHP.
I've been rewriting a lot of my reusable code as jQuery plugins. I moved to jQuery from Prototype when I started doing ASP.NET MVC. Overtime I've migrated a lot my reusable code, or at least the ideas, from Prototype-based OO to jQuery-style plugins. Most of these are stored in their own JS files (mainly intranet apps so page load speed is pretty high anyway despite the extra requests). I suppose I could add a build step that coalesces these if I needed to.
I've also settled on a MasterPage approach that uses a ContentPlaceHolder for scripts that is right before the closing body tag. The standard jQuery/jQuery UI loads, and any other common JS goes right before the script placeholder in the MasterPage. I have tiny bit of JS at the top of the MasterPage that defines an array that holds any functions that partial views need to run on page load. These functions are run from the base document.ready() function in the MasterPage.
All of my JS is completely separate from my mark up. Some JS may exist in partial views -- these are encapsulated when the partial may be included more than once to make it specific to that instance of the view -- but generally not. Typically only included in the placeholders so that it's loaded at the bottom of the page.
Also, if you want to go OO heavy, check out mochikit: http://www.mochikit.com/
I find that developing your javascript using OO methodology is the way to go if you want it to be clean, readable and even somewhat secure. I posted the following question
Cleanest format for writing javascript objects
And got some fantastic responses on how to write my javascript code well. If you follow these basic principles you can use almost any library, such as yui, jquery and prototype, with ease.