Following are the two ways of calling an image in your webb application.
<img src="/myapp/img/world.gif" />
OR
<img src="http://www.example.com/myapp/img/world.gif" />
Which will be best to use or both have the same meaning. If both do not have the same meaning then why? and is there any performance constraints if I use the second method in my app to call all files (images, swf, flv etc..)
Generally speaking, the first method should be your preferred way of referencing any resources that are part of your application. It is called a relative URI reference and it allows you to transfer your application to another domain-name without changing all the links.
You may even consider using relative paths such as
<img src="img/world.gif" />
... assuming that the HTML above appears at some place like http://www.example.com/myapp/main.html
That way you are also not tied to the /myapp path prefix and could easily move your application to /superapp without changing a thing.
Most application frameworks and templating systems have a way of reporting the root URI of the current application. In such cases it may be most convenient to use something like
<img src="$(APPROOT)/img/world.gif" />
... depending on what specific replacement/expansion mechanism your particular envrionment has. Here it is assumed that $(APPROOT) will be replaced with the absolute base URI of the current application.
The former method is a relative URL that locates resources relative to the server’s root. The latter is an absolute URL that indicates not just the directory, but the host, subdomain, even protocol.
They each have their pros and cons. Using a relative path makes it easier to migrate to a new domain since the domain name is not part of the URL. Using an absolute path makes it easier to organize your files since you don’t have to use things like ../../images/ (which can makes things messy and difficult to read).
As for performance, the only issue is that the absolute URLs are a slightly longer (though not always), otherwise no.
There is no performance issues but many times you work and test in a development environment and if you use the second form it would imply to change something like this:
<img src="http://beta.example.com/myapp/img/world.gif" />
to
<img src="http://www.example.com/myapp/img/world.gif" />
So it's better to have always an absolute-relative URI for all the resources
Use your web application framework's HTML helper for generating URLs.
For example,
In Java Servlets: <c:url value='/img/word.gif' />
In CakePHP: <?php echo $html->url('/img/word.gif'); ?>
In Rails:`<%= link_to ... %>
The reason for using your framework's HTML helper is because moving your web application will not disrupt your URLs.
Related
In my project, there are examples were components uses Server Side directives to say include/exclude components. And few places, proper sightly/JSP code is used for same purpose. For example:
<c:if test="${authorMode}">
<cq:include path="headerpar" resourceType="foundation/components/iparsys"/>
</c:if>
<c:if test="${not authorMode}">
<!--#include virtual="/content/myapp/${lang}/global/customer/header.html"--
</c:if>
From basics I understand Server Side directives gets resolved at Apache itself whereas Sightly/Handlebar codes is processed at Publisher. Is there a benefit of coding using directives? If yes, then pretty much lot of code can be moved to server side scripting since it reduces another layer and Apache is far far faster compared to publisher? Why does Adobe promote their scripts and not promote writing with server side directives?
SSI includes are resolved on apache while cq:include within CQ. Using SSI's require from you a bit more knowledge so you know what you're doing
You can benefit from using SSI includes in many ways (mainly performance-wise as you suggested) if you use it properly.
Assume you have a header and footer that is the same for every page but contains heavy logic (navigation, crx tree traversing etc). In this case, if you properly configure your dispatcher caching the header will actually get rendered only once (for the first page) and if user requests another page that has the same header it will simply be fetched from dispatcher cache
Assuming you have a mainly brochureware page but some components that are dynamic you can also cache parts of the page and deny caching for others - again you have to properly configure your dispatcher
Assuming you have user specific content you could also cache parts of pages and dynamically render only parts of those (that's what Sling Dynamic Include is for -> https://github.com/Cognifide/Sling-Dynamic-Include)
So I would definitely use SSI includes for specific fragments of pages that are reused all across your site or meant to differ for different users, like some headers, footers or sth like "Welcome user 'ABC'". I would though not do that with regular content as it will just be cached within the pages html.
I am trying to load a template with xhr and then append it to the page in some div.
the problem is that the page loads the script but doesn't execute it.
the only solution I got is to add some flags in the page (say: "Splitter"), before the splitter, I put the js code, and after the splitter I add the html code, and when getting the template by ajax, I split it. here is an example:
the data I request by ajax is:
//js code:
work_types = <?php echo $work_types; ?>; //json data
<!-- Splitter -->
html code:
<div id="work_types_container"></div>
so the callback returns 'data' which I simply split and exeute like this:
data = data.split("<!-- Splitter -->");
dojo.query("#some_div").append(data[1]); //html part
eval(data[0]); //js part
Although this works for me, but it doesn't seem so professional!
is there another way in dojo to make it work?
If you're using Dojo, it might be worth to look at the dojox/layout/ContentPane module (reference guide). It's quite similar to the dijit/layout/ContentPane variant but with one special extension, that it allows executing the JavaScript on that page (using eval()).
So if you don't want to do all that work by yourself, you could do something like:
<div data-dojo-type="dojox/layout/ContentPane" data-dojo-props="href: myXhrUrl, executeScripts: true"></div>
If you're concerned about it being a DojoX module (DojoX will disappear in Dojo 2.0), the module is labeled as maintained, so it has a higher chance of being integrated in dijit in later versions.
As an anwer to your eval() safety question (in comments). Well, it's allowed of course, else they wouldn't have such a function called eval(). But indeed, it's less secure, the reason for this is that the client in fact trusts the server and executes everything the server sends to the client.
Normally, there are no problems unless the server sends malicious content (this could be due to an issue on your server or man in the middle attacks) which will be executed and thus, causing an XSS vulnerability.
In the ideal world the server only sends data and the client interpretes this data and renders it by himself. In this design, the client only trusts data from the server, so no malicious logic can be executed (so there will be no XSS vulnerability).
It's unlikely that it will happen and the ideal world solution is not even possible in many cases since the initial page request (loading your webpage) is in fact a similar scenario where the client executes whatever the server sends.
Web application security is not about being 100% safe (it's impossible), but it's to try to create as less as possible open doors that can be used by hackers. It's up to you what you consider safe and to verify if the "ideal world" solution is possible in this specific scenario (it might not be, or it might take too much time compared to the other solution).
My application has 2 purposes:
It needs to run stand-alone, where it needs routing for choosing a
study etc.
Or, it runs integrated in an other project, and only needs
one controller and one view.
Currently i have a routeProvider configured for the stand-alone application, injecting the pages in the ng-view tag in the HTML.
Now is my question: How can i inject an controller and view in the ng-view (For the integration). I cannot manipulate the HTML since it is static. I cant use a single routeProvider rule, because this can interfeir the application that integrates mine (Other plugins can use the #/.. for info or other things).
In your situation you can't use routeProvider when other stuff interferes.
Of Course you could prevent routeProvider to act on outside changes of the hashbang with workarounds but thats not nice.
routeProvider will listen to all changes of the url after the hashbang.
So what you should do is to manually bootstrap() your angular app with the controllers you need. If your app is small enough you could even use directives to achieve lazy loading of templates with the attribute templateUrl : "/myurl"
Usually to create a dynamic App use Routing. Simnple point.
The best way to use Angular if you want to unleash all its might don't integrate it.
I explain why:
+ Your state never gets lost due to page reloads
+ You have full control of the environment and don't have to worry about interfering scripts etc.
+ If your user should manually reload, you can redirect to home/login or even better use requireJS or HTML5 local storage to recover your scopes after a reload
Cheers, Heinrich
I don't know that I have the terminology completely correct, but it seems that there are some default behaviors for script resolution in Sling (which I'm using as part of Day CQ). For example, .infinity.json returns a representation of the node and its children. Also, if I have a piece of content that I normally would access with a .html extension, I've been able to use a .xml or .json extension to get a representation of that data. However, if I use a .txt extension, I get nothing back, even though as far as I can tell, I do have scripts that should match the request (eg GET.jsp). Are these behaviors documented somewhere?
GET.jsp will match a request ending with .html, as Sling considers html as the default representation. To activate a JSP script for the .txt rendering, you need to name it txt.jsp
See http://sling.apache.org/site/servlets.html for details.
I have an Opera 11 extension, which has a background process and an injected script. These communicate very frequently with a remote server (not the webpage the user's viewing), using the background script's cross-site XMLHttpRequest capabilities.
I would like the URL of the server to be a preference, so that it can be modified by the user without editing the package. The config.xml file would good, for it accepts <preference name="serverUri" value="..." />. However, I would like the script to be able to update itself directly from the server (not through Opera's site), which can be achieved using <update-description href="http://myserver.com/client/update" />.
So what I would like to do is have the href attribute of the update-description element to be dependent on the value of the preference serverUri. I would imagine some syntax like this:
<update-description href="{$serverUri}" />
But I could not find any references to this kind of functionality. Is there some way to solve this?
It's not possible to use variables in the config.xml file as you've written and I don't think there are plans to add this.
I'm sure you know that preferences can be set not just with the preference element in config.xml but also using widget.setPreferenceForKey(value, key), but I don't think that solves your problem in this case.
The only workaround I can think of is if you have all your logic in an external script on your server and in your extension's local files (background script or injected script), just have a very simple couple of lines that reference your external script. Something like:
var script = document.createElement('script');
script.src = 'http://www.example.com/script.js';
document.body.appendChild(script);
You could then make the script's URL editable by the user and store it in widget.preferences.
EDIT by hallvors: This solution has serious drawbacks, see my comment below.
As far as I know this is not currently possible. It seems like a bit of an unusual use case, which could potentially be risky to implement, so it would be interesting to hear more about why you want to do this.