BAH! I would say you should use the the AUI templating!
-- using an AJAX call to retrieve the compiled results of a JSP?! Blasphemy JACK!
var TPL_TEMPLATE_NAME = new A.Template(
'<div>',
'</div>'
);-- using an AJAX call to retrieve the compiled results of a JSP?! Blasphemy JACK!
Andrew Jardine:
BAH! I would say you should use the the AUI templating!var TPL_TEMPLATE_NAME = new A.Template( '<div>', '</div>' );
-- using an AJAX call to retrieve the compiled results of a JSP?! Blasphemy JACK!
lol (I think)
how would that work for OP David who was referencing need to construct a url to a jsp ?
Yeah, to quote the mighty Olaf "it depends".
The simple dialog example at Meera's site shows along the lines that I was thinking in my earlier blasphemous comment.
http://www.liferaysavvy.com/2014/06/liferay-62-aui-dialog-liferay-popup.html
And to add to your (Andrew) approach, I've seen an interesting technique of delivering text back and parsing it as json only if it is indeed json where otherwise assume it is text (good for say an error message where, for example, the expected json couldn't be retreived)
The simple dialog example at Meera's site shows along the lines that I was thinking in my earlier blasphemous
comment.http://www.liferaysavvy.com/2014/06/liferay-62-aui-dialog-liferay-popup.html
And to add to your (Andrew) approach, I've seen an interesting technique of delivering text back and parsing it as json only if it is indeed json where otherwise assume it is text (good for say an error message where, for example, the expected json couldn't be retreived)
The only time I would advocate in favour of referencing a JSP to populate the body would be for a case where it was not my plugin -- say a core plugin's JSP or something. But if I have control over the markup, then doing that kind of hybrid thing makes me feel like you're only half adopting one approach or another.
Myself, I try to use a standard response structure for my resource calls where in I have an outer structure and then a data attribute with the result of the response. For example --
Then I can use the success attribute to determine whether or not my call worked, the status code to determine handling logic, and the message (which I try to populate using a language key) to control the message I want to display to the user (if any). The data attribute then becomes my actual result which I either massage or pass as is (depending on the scenario) to the template.
Now, I am willing to admit a few things here. You certainly can't do as much with a TPL definition as you can in a JSP. You can loop to output a list, and you can do IF statements (there is, sadly, no concept of an else) and really, it's akin to velocity in a way where you basically have a map of key value pairs. But then purists will tell you that you shouldn't be processing logic in your template to begin with of course.
At the end of the day, there are several ways to skin this cat I guess. Using the <portlet:renderURL> as you referenced Jack would save the issue of the view path breaking on upgrade, but so would the TPL. I guess, my position is that if you are going to use AUI to create a rich UI, then I try to use as much of it as I can to create a clear separation between the two layers.
Mind you, I am also mental enough to enjoy building custom AUI modules -- so take any advice I give with a grain of salt!
Myself, I try to use a standard response structure for my resource calls where in I have an outer structure and then a data attribute with the result of the response. For example --
{
success: true,
status: 200,
message: "13 report records found"
data: {
}
}Then I can use the success attribute to determine whether or not my call worked, the status code to determine handling logic, and the message (which I try to populate using a language key) to control the message I want to display to the user (if any). The data attribute then becomes my actual result which I either massage or pass as is (depending on the scenario) to the template.
Now, I am willing to admit a few things here
. You certainly can't do as much with a TPL definition as you can in a JSP. You can loop to output a list, and you can do IF statements (there is, sadly, no concept of an else) and really, it's akin to velocity in a way where you basically have a map of key value pairs. But then purists will tell you that you shouldn't be processing logic in your template to begin with of course. At the end of the day, there are several ways to skin this cat I guess. Using the <portlet:renderURL> as you referenced Jack would save the issue of the view path breaking on upgrade, but so would the TPL. I guess, my position is that if you are going to use AUI to create a rich UI, then I try to use as much of it as I can to create a clear separation between the two layers.
Mind you, I am also mental enough to enjoy building custom AUI modules -- so take any advice I give with a grain of salt!