I have a Sinatra app where I'm serving Sprockets assets from /assets. Works well enough, but since I'm a bit of a perfectionist, and to keep things as tidy as possible, I would like to have the assets served from their respective subdirectories.
I.e. I would like #{root}/app/assets/stylesheets/application.css.scss to be served as /assets/stylesheets/application.css, instead of just /assets/application.css as it is now.
Is this possible? Middleman does something similar to this, but I'm not sure how much it's actually leaning on Sprockets.
Middleman is a static site generator, and therefore the assets are precompiled and served as if they were in a public directory, which means that you could have a subdir of stylesheets and it would become part of the url used to access the assets in the subdir.
Sprockets compiles assets as they are accessed and then caches them (as far as I can see), and uses a Rack application to serve the assets from their logical path. From the Sprockets README:
The logical path is the path of the asset source file relative to its
containing directory in the load path. For example, if your load path
contains the directory app/assets/javascripts:
Asset source file | Logical path
app/assets/javascripts/application.js | application.js
app/assets/javascripts/models/project.js | models/project.js
I didn't see an obvious setting to change in the docs, and unless you're willing to look through the source and hack a bit, then I'd say the answer is no. Maybe you could try shortening the load path and see if it includes the subdirs?
Related
I have created some asset bundles from my Unity assets using the directions given in the Unity documentation section on AssetBundle Workflow. After running the "Build AssetBundles" command, each asset bundle results in four files: myasset, myasset.meta, myasset.manifest, myasset.manifest.meta.
Now I am ready to deploy these bundles to a web server and implement downloading/caching in my Unity project. I have found numerous examples such as this that show the download URL to be a single file with a .unity3d extension. This is leading me to conclude that I am missing a step - I assume that all four of my files will be required by the app and that I have to do something to combine them into a .unity3d file first.
What file(s) do I need to deploy? Are there any additional steps that I need to take before my file(s) are ready to upload? Thanks in advance for any advice!
Just myasset will suffice.
Sometimes people optionally add .unity3d as a filename extension to their Asset Bundles. It is just a community convention, and is completely optional. Source (copied below)
Vincent-Zhang
Unity Technologies
Just a reminder, we don't have an official file extension ".unity3d" for asset bundle, it's not mandatory. You can use whatever file extension as you want, or without file extension.
But usually people use ".unity3d" as the file extension just because we used it in the official sample code at first time...
Unity creates the .meta files for all assets- you don't have to worry about those. In short, your myasset file is enough. I do not add file extensions to mine. Do note that if you use the strategy shown in the example that you shared that the client will re-download the bundle from the server every time. You need to additionally provide a version number if you want to take advantage of caching. You can see this in some of the method overloads here, the ones that have a Hash128 or uint "version" parameter. Caching is great because you can use the bundle that is already saved on the device next time instead of downloading from the server when no changes have occurred. The version/hash number you provide essentially gets mapped to the file name. Whenever a matching version is found, the file on disk is used. Update the version number to something else when the content changes to force the client to download anew.
You may want to reference the .manifest file for the CRC value listed there. You may have noticed a crc parameter in the link I shared as well. This can be used to ensure data integrity during transmission of the bundle data. You can make sure the downloaded content's CRC matches that of the bundle when you created it.
After working on zincs tutorial I want to serve an entire repo filled with .js, .html and .css files I created a firstpathsegment so that I upload all files to the sam place but then how to create a place to serve and store the files ? and how to upload them ?
If you read on in the tutorial, you'll find how to do that in the part 'Static file server'
(ZnServer startDefaultOn: 1701)
delegate: (ZnStaticFileServerDelegate new
directory: (FileDirectory on: '/var/www');
prefixFromString: 'static-files';
yourself).
If you compare that to the ZnMonticelloServerDelegate implementation, you'll see how to write files. If you want to be able to create subdirectories, take a look at FileSystem-Core-Public. In a public-facing site, you'll need to do something about authentication and access control. We mostly put an apache or nginx in front (and let that take care of the static files).
I am trying to distribute a netbeans project however the jar it creates and the contents of the dist folder are dependant on some image files which i included into the project - however these images are not in the dist folder and I cannot workout how to make things work so I can export the project in a distributable format including all the things it needs.
Can somebody please tell me how I can export a project which runs within Netbeans without using the project's /dist folder which includes everything it needs?
Cheers
Andy
One way to achieve this is to add a folder (f.i."resources") in your project's src dir. Then copy the images to that dir. Now the images should get included when you build the project (if I remember correctly). Accessing the files can be accomplished with "getResourceAsStream"...
If whatever resources you are interested in are in the classpath, packaged in the jar, war, or the distribution, you can retrieve them by getting resources.
The convention is indeed to have a directory named 'src/resources' that serves as the root for this. Depending on the amount and scope of the resources you are using you may also want to add a sub-directory hierarchy to keep the organization and state of the resources manageable.
Also, not that a resource can be any file, an image, sound, text, xml, binary, etc. no limitation.
Finally, the call will look like this if you are using an object method:
getClass().getResourceAsStream("resources/myResource") - or - getClass().getResource("resources/myResource")
depends on if you want a stream or just the URI at that point in the code. Typically one would use the URI for delegating the processing of the resource elsewhere and the stream form when you are processing it in-line.
For a class method, you will need to do something more like:
new Object().getClass()...
The think to keep in mind here, is eventually this is resolving to the class loader and it is from that class path that the resource will be fetched.
You can add images the same way:
final Image image0 = Toolkit.getDefaultToolkit().getImage(getClass().getResource("images/1.png"));
I have some JavaScript files, a main HTML file, a main CSS file, and some CSS files that get imported into the main one.
I understand that I can put static files in two places: a) the 'war' folder; or b) the 'public' folder.
Where is the best place to put my static files? Are the two locations treated differently? Is there a 'best practice' on this issue?
The difference between the 2 locations is that files in the public folders are copied by the gwt compiler to the 'your module' folder in the 'war' folder. This is means if you deploy the 'war' (for example via the google plugin to the google appengine) the files from the 'public' folder are not at the toplevel.
For example, if you have an index.html in the 'public' folder with gwt module named 'mymodule' and you deploy it to www.example.com it looks as follows, you need to access it via:
www.example.com/mymodule/index.html
If you have the index.html in the 'war' folder, you get:
www.example.com/index.html
Summarizing. Your landing page should be in the 'war' folder. Resource files used by the landing page can also be stored here (css, images). Any other resource file that is referred to in any gwt module file (or code, like images) should be stored in the 'public' folder related to the gwt module.
The new way of working in GWT is to use the war folder.
But, if you project is a reusable widget library which is used in a GWT application then you should put the resources in the public folder. The compiler will make sure that the files are automatically included in the generated package.
As I see it, it depends on your requirements, but let's start at a speaking example first ...
I find the documentation (should be GWT 2.6.0) about this to be incorrect or at least incomplete/confusing. As I see it (I am not a guru so please correct me if my investigations are wrong!) I am looking at the following example proj structure
myproj/
src/my/gwtproj/
client/
img/
foo1.png
AppClientBundle.java
foo2.png
public/
img/
foo3.png
foo4.png
war/
img/foo5.png
foo6.png
.classpath
.project
Imagine we may (or may not) need to reference such resources in some AppClientBundle interface (or other application reference context):
interfaces AppClientBundle extends ClientBundle {
#Source("img/foo1.png")
ImageResource fooImg();
}
Then it seems to depend on your Requirements, e.g.:
R.a) these resources (like images) are refered to in the application code, e.g. in our AppClientBundle interface via #Source annotations
R.b) these resources are to be grouped by folders, e.g. foo2.png vs. img/foo1.png
R.c) these resources should be available outside some specific application URL context path, e.g. if used as widget library, e.g. http://host1/gwtapp1/foo4.png vs. http://host1/gwtapp2/foo4.png
R.d) these resources need to be application-independently (e.g. externally) URL-referenced, e.g. http://host1/gwtapp1/foo4.png vs. http://host1/foo6.png
Here's what one can do (Possibilities) and it's implications regarding R.* above:
P.1) (generally recommended as I see it) put nicely folder-structured resources under my.gwtproj.client (here e.g. foo1.png)
this way #Source("img/foo1.png")... works fine
in the docs above they speek about some public folder (in my case my.gwtproj.public), but creating it as a package in Eclipse does not me allow this (since public is a reserved Java key word, but creating it via the Navigator view works)
however, this way the #Source above does not work (likely because it's an issue with the relative AppClientBundle file system location)
nevertheless if the resource should be publicly available under the application context one may have to do it via this public folder
P.2) put "ungrouped" resources directly under myproj/war, e.g. projdir/war/foo6.png
this way it can be used/found within annotations, e.g. #Source
and it can be referenced outside the application itself via e.g. http://host1/foo6.png
P.3) put folder-structured resources under myproj/war, e.g. projdir/war/img/foo5.png
in contrast to P.2) #Source("img/foo5.png") would not work anymore
I don't have permission to change the document root the /public/ directory so how should I set up my Zend Framework application to run from the current root directory? Using the Zend Framework 1.8 command line tool, I don't know if there is a way to tell it to create a directory structure this way.
If you can access only the upper level of web (i.e. - public), you should set index there and the whole application folder too. Create a .htaccess with
Deny from all
And put it into your /application.
Your configuration will be:
/application
/library
index.php
The simplest way without changing a lot of configuration, is to put everything in the public folder you mention into your public_html folder, then place all the other contents, like the application, and library folders into the directory up from public_html.
You can also throw everything into your public_html folder, although that is not recommended. Each class has options to provide a different path. For example on the Front_Controller, you can set the Controllers directory to wherever you want. There are options to specify different paths, but if you follow convention it is done for you.
Just use the quickstart guide and adjust according to it. Zend_Tool is still experimental anyway. Let me know if this helps.
So here's what I ended up doing:
Download the Quickstart sample code.
Move everything in public up to the main directory, along side application, library directories.
Alter include paths to library and application in index.php to point to the correct locations
I think that was all I had to do. ZF new how to the rest.
I don't think this is ideal however, as already mentioned, application directory becomes accessible from the web, but for now, it's getting the job done.