I have big WEB application (jsp). What is the best way to put images files? Where to put images files in multi modules web application?
I have many images so I would like to have easy, separate access to modify them. The best way will be some separate project which I can redeploy without stop my main application part. Is this solution acceptable?
Yes, it is completely acceptable. You can create an "assets" project, and have images/module1/, images/module2/ folders, etc.
Just, in your main application, you will need to configure the path to the assets application. It can even reside on a different host. For example http://assets.yoursite.com. And then in your main application you'll have:
<img src="${assetServer}/images/module1/logo.png" />
(the assetServer request attribute may be put there and configured in multiple ways, depending on the setup and your preferences. One example is - configure as context-param in web.xml, and put in the request by a filter)
Related
Let's say I have the following setup:
SolutionProjects containing Project1, Project2.
Project1 contains code, Project2 contains a folder called Images and in it is a file 'example.png'.
Now I want to use 'example.png' in Project1, e.g. <img src="example.png"/>
I can't navigate there via ../../ because it stops at the root of Project1 and doesn't let me go up by one into the solution folder.
I want to use relative paths if possible.
Can someone with more experience help me out?
If you have two web projects, they can be deployed in different applications within the same website, different web sites on the same server or even different websites on different servers.
You cannot navigate towards the other project using ../, because the file structure you have on disk in your solution does not necessarily match the file structure after deploying. Your web application is not going to serve another web application's files.
In other words, the file may not be where you expect it to, and you cannot go up beyond your wwwroot.
You'll have to prefix the actual site that the other project is going to use. During development this may be https://localhost:12345/, and it'd be wise to make this configurable.
So your image tag becomes something like <img src="#(Html.ImageServerUrl)/Images/Foo.png" />.
I have a different set of applications, each having their own war files and they could be deployed in different servers.
Assuming that all application sets may need to interact with each other I am trying to develop them as web services. It may happen that an application 'A' installed on server 'X' needs to launch an application 'B' but B's resources like HTML and js are not present on the server where A is installed.
How can we do this? I have come across a few sites where Viewable is used but then it needs the JSPs to be in the same instance. What if I want to achieve this when the calling application doesn't have HTMLs or JSPs with it.
I hope I have been able to put up my question properly. Thanks for any inputs.
As Pesskillet says, you can use a redirection to resource of server B.
If that resource is an HTML view, you don't need to worry about the loading of static files (CSS, JS, Images etc.) that are bound to the HTML view. Because the browser of the user will load it automatically as soon as it will get the HTML document.
I am building a Spring Web Application hosted on Elastic Beanstalk. I use S3 to store user uploaded images which works great. What I don't understand is how fetching images from S3 to the client work. I found three alternatives.
1.Get the image in a controller and send it to the client. Like this:
S3Object object = amazonS3Client.getObject("bucketname", "path/to/image");
2.Open up all images and reach it directly by an URL in the client. Something like this:
<img src="http://aws.amazon.com/bucket/path/to/image.jpg">
3.Use signed download URLs that only working for a certain time. Like this:
GeneratePresignedUrlRequest request = new GeneratePresignedUrlRequest("bucketname", "path/to/image");
String url = conn.generatePresignedUrl(request)
Im not sure which approach to go for. Routing it through the web server seems unnecessary, since it loads the server. Open the URLs to anyone might higher requests and costs since anyone can use the images. And the third way is new to me, haven't really seen anyone practising this which makes me insecure if this is really the way to go.
So, how is this usually done?
And how is this used in the development environment versus production environment. I guess its not changing? Or is it common to use spring profiles to change the location of static content while developing and only use S3 for production?
If your hosting Javascript, CSS on S3, is it then most common to go for approach 2 and open them up for everyone?
For me it depends upon the requirements you have for access control for images uploaded by a user.
If the images are non-sensitive i.e. it wouldn't really matter if someone else got hold of another user's images, then I would go for approach 2.
If on the other hand it would be a disaster if someone managed to get hold of another user's images, then I would go for approach 3 (or some other form of expiring token access to the images).
The last time I did this I went for approach 2 because the images were non-sensitive. To try and prevent people from discovering images, we did apply a hashing function to the name of the image, but again I wasn't massively concerned about this. In either case, a well defined bucket structure that can be easily worked out by the application when constructing the URL for an image is useful. So for you, perhaps consider something like:
s3:bucket_name/images/users/<hashed_and_salted_user_name>/<user_images>
As for you request regarding dev vs prod environments, then matching a bucket name to the Spring profile is the approach we used. So for example:
s3:bucket_name/prod/images/users/user/foo.jpg
s3:bucket_name/dev/images/users/user/foo.jpg
As you can probably guess we had Spring profiles named "prod" and "dev". The code for building image URLs took into account the name of the current Spring profile when creating the URL. Gives a nice separation between environments.
In terms of CSS and Javascript, then I tend to host obfuscated/minified versions in the production S3 buckets, and full versions in the dev/test buckets (mainly for performance rather that trying to hide code). In addition I'd use some sort versioning/naming structure in how you host CSS/Javascript in S3 so that you can determine what "version" of resources your app is using. So for example:
s3:bucket_name/css/app-1.css
s3:bucket_name/css/app-2.css
The version of the CSS/Javascript resources is updated each time you push a new version into production.
By going down this path you kinda look at S3 as the final resting place for a piece of Javascript/CSS when it is ready to go into the wide world of production. Once there, you know it will never change. If CSS/Javascript does change, then the user has to fetch a new resource from S3 as the version will be incremented. You can hook this into your build process so that your main app is always referencing the latest version of CSS/Javascript. I found this has two useful functions:
Makes it very easy to determine which version of a resource your application is running with
Makes it very easy to cache resources (either with browser or something like CloudFront) as you know they will never change
Hope that helps.
I am making an windows store application and one of the requirements is that it must not use data connection. The application includes a lot of photos (around 400, all compressed as much as possible, around 8 kb each).
What would be the best practice handling this situation? How should I "preload" them in to the application?
If your requirement for zero net connectivity is real, then you have two options.
ONE. You can ship your app, and request that the user get the images from some other location and then give them to your app, loading the image in a somewhat manual way.
I know this does not sound ideal, but I wanted to acknowledge it was an option.
TWO. You can ship your app with the images embedded inside the installation package. This means as soon as your app installs, the user has all the images, no net necessary.
Here's how:
Create a new folder in your project, call it "Images" or something.
Drag your images into that folder (using Visual Studio).
Refer to your images like this "ms-appx:///Images/MyImage.jpg"
Note: it's up to you how you keep track of all your images, you could iterate through the folder over and over again, but it's probably best you just hard code the list in some class.
It's really that easy.
Best of luck!
Can you just store them in your project solution and refer to them in your code using the ms-appx:/// format?
Also if you are using so many images, prefer jpg images or compress your images using
https://tinypng.com/
Hope that helps.
I'm very new to Version Control, and I was wondering if I could get some advice on how it can fit into website design.
At the moment I'm working on a typical, simple website that includes images:
A few .html files and a .css file
One folder full of photographs
Another folder with the corresponding thumbnails
Can I just put the whole lot in a repository? Or is there a better way I could apply Version Control to it? How should I deal with the images?
edit:
How well will it work with changes to the images? What if I decide to try and optimise my photographs or resize them. I wont be able to see what exactly changed about the images, should comments be enough to keep track of that?
One common practice is to decide what files you would need to publish the site, then include those files in your DVCS. If you eventually adopt a build server/continuous integration server, it will check out your code from your repository, run tests on it, compile it, then publish it to your testing/production server. To do that, you'll need to include all necessary files.
You should not include unnecessary files that may change often, but signify nothing. For the ASP.NET world, those include .suo, .user, resharper files. If you have an uploaded files folder, you could excluded that as well so files that you test upload don't get included. Basically, anything of that nature.
Clarification
Regarding the "uploaded files folder" thing. If you site supports user's uploading files and they are stored inside the site's directory, say in a folder called "Uploads", then you would want to exclude such a folder from the source control. This is just an example of the kind of thing you wouldn't want to include. While testing, you would test uploading files to your site, but you certainly wouldn't want those test uploads published to production, so keep them out of source control.
Unless you have a compelling reason not to, I don't see why you couldn't put the images into the repository.