I have a page when user can add 0 to N TinyMCE editors that need to have some div soup around it.
I have the html code in a gsp _template because it is more then a few lines and I didn't want to stuff it in javascript. Basicaly everytime user clicks "add editor", an ajax call is made to the server with new id as the only parameter, controller renders the template with elements properly named using the new id, and it is appended by javascript to the page.
I think its a pretty elegant solution, but what bothers me are the ajax calls that are fired for every new editor that is to be added to the page which has always the same code apart from different element id's.
Will this have any performance impact? Is the template cached after first call?
Thanks
The GSP should be compiled (pre-compiled on grails war) and then there is some caching to help speed up GSP rendering. The performance issues are no different than considering any amount of traffic. The server doesn't care (or know) that the request is Ajax. It is just responding to a request. IF you remove ajax from your equation and just look at it that way, would you still be asking the performance question?
That said, if all you need is an ID attached to the elements in the template, I might look into something like a javascript template solution (jquery.template() for example). That would negate the call to the server entirely.
Related
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.
I have a view that contains a javascript function that i need to init/call when the page loads. The method is static but it needs to be called with some parameteres (a list of Id's) - this list is dynamic and varies by some querystring parameters (i can not generate the list clientside from the querystring).
So i need to generate this list server-side.
My options are, as far as i see it:
1) Make an ajax call on the client, requesting the ids from the server.
2) Inject/inserting the ids directly on the view (it is a property on the viewmodel).
No matter how i turn it, option 2 seems the most sane. I already got the data ready on the viewmodel and thus it's ready when the view is populated - i see no reason to make an extra request to the server, just to get the data.
I know many would think it's a bad idea to inject something dynamic into an otherwise static javascript. For that i could simply just inject a new javascript, holding only the Ids and a call to the static javascript method, which is what i really want to do.
My problem is this though: When i write my asp.net <%= %> includes, VS IDE stops highligting, making me think i might be on the wrong track? Surely i'm not the only one needing to output something in a javascript block in asp.net mvc?
Route 2 (The ViewModel) is definately the way to go and
<script type="text/javascript>
<%= Model.JavascriptToInsert %>
</script>
should work (despite lack of VS highlighting)
It will NOT work in a seperate JS file though. It must be in your view itself.
Kindness,
Dan
I'm am building a web app with app engine (java) and GWT, although I think my problem is moreso a general javascript question.
In my application, I want to include a side-menu which is generated from data in my database. This obviously needs to be done dynamically from a servlet.
Currently, I am sending a blank menu container, then making an ajax call to get the information i need to populate the menu. I would rather just send the menu information along in the original request, so I do not need to waste time making a second request. I used this initial approach because it seemed simpler: I just wrote a gwt rpc service that grabbed the data i needed.
My question is, can I instruct a javascript library like gwt to look for its information in the current web page? Do I have to hide this information in my original HTML response, maybe in a hidden div or something?
If the data that you'd like to embed is restricted to menu items, why not directly generate lightweight HTML out of simple <ol> and <li> elements? You can still keep HTML out of your Java code by using a template engine. The menu markup could just be styled with CSS or if you need something fancier than mere <ol> and <li> elements, you can massage the DOM with JavaScript once the page loads (read: progressive enhancement).
If you're looking for a more generic solution, beyond the menu case, then you could embed a JSON block in your page, to be consumed when the page loads for the dynamic generation of your menu.
Or, you could look into using a microformat that is suitable for menu data.
You can include a script block in the original response defining the data and then use an onload event (or similar) to create the menu based on that data; that's very similar to what you're doing now, but without the extra trip to the server. I'm assuming there that the data to construct the menu is transformed in some way by JavaScript on the client; otherwise, just include the menu markup directly.
GWT has something called JSNI (Javascript Native Interface) that can interface with other non-GWT Javascript. So, you could in your HTML page container have a containing the generated menu items as a Javascript object. Then, in your GWT code, you have a JSNI call to fetch this data and put it in the right place in your UI/DOM with GWT methods.
I asked a similar question a few weeks ago about how to store data safely inside HTML tags. It also contains a few links to other questions. Here
There are in general 2 options:
Store the data in some xml tags somewhere in the html code and later get the information from there by traversing through the DOM. (you can hide them with css)
Store the data as JSON data in a script tag. (There en- and decoders for nearly every language)
var data = { "foo" : "bar", "my_array":[] };
I have a page where I need to create a large amount of HTML that's not already present in the page.
Using jQuery I've been building the page with JS piece by piece, adding divs here and there, etc, until I get my layout.
Right now I'm thinking rather than do all that in JS, I can create the layout in a separate HTML file and then load it with ajax. My initial aversion to that idea is because of ajax, it requires an additional server request, and might end up slow(er?).
Anyone have any advice on whether or not this is a good idea, and if it is, if there are tutorials, set ways and patterns to doing this sort of thing.
Thanks.
There may be a speed impact from making another round-trip to the server. However, I think that the readability/maintainability you gain from having all of your HTML in a separate template, rather than mixed in with your JS is the big win here. You won't have to deal with quote issues, entity encoding, all of that. And the code that you do have will be easier to debug.
I'm not aware of any specific tutorials on this, but with most of the AJAX libraries out there, it's easy to make an XHR request and pipe the response into a DIV. For example, see Prototype's Ajax.Updater(container, url[, options]) function. ( http://www.prototypejs.org/api/ajax/updater )
The issue you'll get is not slower, but your URLs will be a little messed up.
If you navigate from page to page your URL won't update easily. You CAN do it but it can be a lot of work.
I've used post's callback function to display the data from the post with good effect and it's fast.
Good luck with it!
edit: I was talking about jQuery's post function.
2nd edit: If you're going to vote me down guys, at least say why...
currently I am using yet 1.1 specs, so I am trying to make simple what is too complex for me :p, managing backing beans with conflicting navigation rules, external params breaking rules and so on... for example when I need a backing bean used by other "views" simply I call it using FacesContext inside other backing beans, but often it's too wired up to JSF navigation/initialization rules to be really usable, and of course more simple is more useful become the FacesContext.
So with only a bit of cross browser Javascript (simply a form copy and a read-write on a "proxy" form), I create a sort of proxy form inside the main user page (totally disassociated from JSF navigation rules, but using JSF taglibs). Ajax gives me flexibility on the user interaction, but data is always managed by JSF.
Pratically I demand all "fictious" user actions to an hidden "iframe" which build up all needed forms according JSF rules, then a javascript simply clone its form output and put it into the user view level (CSS for showing/hiding real command buttons and making pretty), the user plays around and when he click submit, a script copies all "proxied" form values into the real JSF form inside the "iframe" that invokes the real submit of the form, what it returns is obviously dependent by your choice.
Now JSF is really a pleasure :-p
My real interest is to know what are your alternative strategy for using pure Ajax and JSF 1.1 without adopting middle layer like ajax4jsf and others, all good choices but too much "plugins" than specs.
My suggestion is that you take a look at the Javascript frameworks out there, for example Prototype or JQuery. They have functionality that allows you to serialize form data and send it to the server using Ajax. Then you can get the answer back, and display it on the web page. Take a look at Prototype's Form.serialize and Ajax.Updater. I think it's a more cleaner way of doing things than using "proxy" iframes and forms.
Say you have a form and you want to send it to the server and replace the form with an HTML snippet from the server. This is one way of doing it using Prototype:
new Ajax.Updater('divThatWrapsTheFormTag', 'someUrl', {
parameters: Form.serialize('formId')
});