I find the section on application structure in the official documentation quite confusing for me. It first says
The only server assets are JavaScript and files in the private
subdirectory.
but then immediately
Meteor gathers all your JavaScript files, excluding anything under the
client, public, and private subdirectories...
and later
Meteor gathers all JavaScript files in your tree, with the exception
of the server, public, and private subdirectories, for the client...
and
Files outside the client, server and tests subdirectories are loaded
on both the client and the server!
These seem contradicting for me. For example what if I put some JavaScript files in private, will they be gathered by Meteor? By 1 and 3, yes and to the server only; by 2, no; by 4, yes and to both server and client.
One possible explanation is that the set "JavaScript files" is not a subset of the set "files", which is not logically sound. I know this answer has provided a clear table for the structure and I may ultimately resort to that. But I still need someone to clearify the ambiguity of this part in the official documentation. Thank you.
First I ought to split up the files into 3 types of classes
Files that are parsed by Meteor as part of the project (not considered static)
Files that are considered as part of Meteor but are static
Other files like those necessary for tests
The only server assets are JavaScript and files in the private subdirectory.
These files are considered 'static' and js files in private are not run. What it means is that files in private and server are not visible to the client. (Part of 2 in the criteria above)
Files outside the client, server and tests subdirectories are loaded on both the client and the server!
It ought to say private and public too, private and public files aren't loaded on the browser. (These are mentioned this way, but are in reference to 1) hence the confusing language
Summary
tests -
Only used for tests, not parsed by Meteor
private Storing static files that are not parsed by meteor that the browser cannot access, can be accessed by the server only via Assets
public Storing static files that the browser can access, mapped to the the / path
server Files only run on the server and are parsed as part of Meteor,
client Files only run on the web browser and are part of Meteor
packages Stores packages that meteor will parse in a special way, can not contain anything apart from Meteor packages. Can contain code that is considered as parts of the private, public, client or server folders.
. (Folders and files beginning with .) - Ignored
..~ - Folders ending with the tilde - Ignored
Anything Else Parsed as part of Meteor, and runs both on the client side and the server side.
Anything that is run by the client or server and parsed by Meteor is usually concatenated and minified in production.
Static files accessible by the client - notes These will be separated from the app and run in a virtual static folder in production (e.g Images, Fonts, Videos, non js files)
This is not a table like the other question, which explains how to structure an app, but more how Meteor interprets the files in the folders above.
Related
Per the Meteor docs, I'm trying to determine which special folder to place non-app assets (ex. Photoshop design PSDs) in, so that they still get checked into source control but don't get wrapped into the eventual client or server payloads.
It feels 'wrong' to use tests/ for this purpose but the docs suggest it has the desired behavior. Can private/ be used similarly, or will its contents always get added to the server bundle regardless of whether your app code registers any Assets? (Or is there a better place altogether to put such files?)
Consider a project structure like this:
/YourMeteorProject
/YourPSDFiles
file1.psd
file2.psd
...
/YourMeteorApp
/.meteor
/client
/server
...
You can launch your meteor app from within /YourMeteorApp. Files that are not part of your application, such as your PSD files, are kept outside of the application.
I have an ASP.NET web application written in C# 4.0. The application references a class library that comes with its own configuration file. At runtime, the class library uses similar to the following code to load this specific configuration:
var exeConfigPath = this.GetType().Assembly.Location;
var config = ConfigurationManager.OpenExeConfiguration(exeConfigPath);
This is done because the library has to load its bundled configuration rather than the application configuration. The application configuration should not be concerned of the library's settings and should not be able to alter them.
Now, there are a few other things that need to be done for this concept to work. I have to set the library's configuration file build operation as Content in the properties window and the Copy to be Copy Always or Copy If Newer. So far so good - the file gets automatically both into the class library's bin directory, and the web applications's bin directory, and is correctly renamed from App.config to CustomLibrary.dll.config (as supposed, the library's dll is CustomLibrary.dll).
Now I am facing two issues.
1) When I publish the web application to a filesystem location (mapped in IIS), the CustomLibrary.dll.config appears back as App.config in the bin folder of the published app. OK - I will rename it in the class library project to match the expected convention - and problem solved.
2) Even when published, the IIS compiles the application again and stores it in the ASP.NET Temporary Files. There is a fancy directory structure with a folder dedicated for each assembly referenced. The folder corresponding to the CustomLibrary.dll does not contain the config file in it. Since this.GetType().Assembly.Location will return the path to the temp folder, the application fails to load the configuration and crashes as it should.
I need to preserve the pattern of having the configuration in the class library, and be able to make it work in the web application. When manually copying the .config to the temp folder, the app works, but see, I really hate manual copying to randomly-named folders.
Is there a way to either prevent IIS from using the temp folders, or to make it copy along the config files? I believe the problem I am facing is configuration-related rather than conceptual since the application works as expected when the config file is in place. I'd prefer not to mess with using hard-coded physical paths to the config file either.
Edit:
To make it clearer, I will point out what and why I want to achieve. The idea is that the library and the web project will be developed as separate products - there will be no user or application specific information in the configuration of the library, so it will not change for different use scenarios. It is also rather specific to the class library functionality rather than the end application. It makes sense for me to keep the library's configuration information bundled within it (similar to Java, where a spring context xml file, or a properties file, get bundled with the jar of the library). I'd like to avoid having to copy the configuration in each app/web config of the consumer application. There will be cases where the consumer application is developed by third parties, and I do not want to rely on them doing their configuration right for my stuff to work. Again, the only issue here is not having the config file copied to the right place.
If those are static, internal settings that nobody should see or change, wouldn't you be better off having a file with the configuration included within the class library as an embedded resource? Either that or just a static class with the settings.
That way you'd be certain that nobody alters it, which in your scenario seems to be a plus.
I have come along a way to work arround the described issue, still not a very pleasant one to my requirements.
The solution is to take advantage of the application configuration (web.config in web apps, or app.config) which is always available. I have added as settings the absolute paths to the config file for each library. So I ended up with:
<!--
THIS IS IN THE WEB.CONFIG FILE
-->
<appSettings>
<add key ="ClassLibrary_ConfigPath"
value ="{My Publish Output Folder}\ClassLibrary.dll.config"/>
</appSettings>
and the class library now uses the following code to load its configuration:
Configuration config = null;
try
{
var exeConfigPath = this.GetType().Assembly.Location;
config = ConfigurationManager.OpenExeConfiguration(exeConfigPath);
}
catch (Exception e)
{
if (!IsConfigurationNotFoundError(e))
{
// IsConfigurationNotFoundError logic skipped for brevity
var exeConfigPath =
ConfigurationManager.AppSettings["ClassLibrary_ConfigPath"];
if (exeConfigPath != null)
{
config = ConfigurationManager.OpenExeConfiguration(exeConfigPath);
}
}
else
{
throw;
}
}
While this works, I will wait for a better solution if possible. Still, I do not have to copy the entire ClassLibrary.dll.config into the web.config file, but now I must manage filesystem locations and be aware of app-setting names. What I really want is the consumer app of the ClassLibrary.dll not to deal with its configuration in any way. If it were a desktop app, I have this covered, as Visual Studio copies the ClassLibary.dll.config appropriately. I hope there is a way to make it work smoothly for web apps.
The short answer is: you can't. You have to merge both configuration sections and place all settings in the main configuration file of your application. In case of the web application it would be the web.config. Read this
Copying a static website, i.e., HTML, CSS, JS is very simple.
Copying a dynamic website, i.e., is difficult due to the server-side scripts.
I'm concerned about cloning any meteor app as most of the server-side scripts are eliminated and the only thing which needs to be copied is the database, the schema can be easily obtained from the meteor live app and data can be easily scraped from the existing meteor app.
If a successful meteor app can be easily cloned, no one would prefer to develop an app on meteor.
Is there a way to stop cloning an existing meteor app?
Well, technically a meteor app can be cloned it depends on your directory/file structure & whether you're using it in development mode. If you're using one file and this sort of structure to seperate your code:
if(Meteor.isClient) {
}
if(Meteor.isServer) {
}
Because this file would be sent down to the client so someone can fetch it.
So it might be better to move to this structure
/client - Place stuff in Meteor.isClient in a new js file
/server - Place your server side code in a new js file
/public - Place other public folder stuff
So no one will see the server side scripts, so they can't clone the backend of your app.
Production mode/Dev mode
In addition if you run your Meteor app in 'production mode' the Javascript is packed, handlebars & handlebars templates are precompiled.
In my opinion, it might be actually harder to copy a Meteor app to the previous types of web apps because HTML is rendered on the client side, fetching the html files will actually get back empty html files, if you even prettify the large JS file still leaves back precompiled handlebars templates. In addition files are merged into one!
So thats when it comes to cloning it to another meteor app. Even if getting the client script is available (as with any other stack) there are even more hurdles with Meteor when it comes to replicating the server script:
DDP
Attempting to clone it to a PHP/Server side script stack might be even harder because POST/GET aren't even used, DDP is used instead.
Schema
Width regards to the schema, you can control what the client sees via Meteor.publish, so they won't actually see the whole schema
We are hosting huge app for our cutomers. There are diffrent configuration and contents (images, user files). But the core code, directories structure, databse scheme is this same for every client.
I'm looking for a way to create one core code repository, so all clientes will use it. We do updates often, so this will make our live easyer.
The idea is to create the repo and In clients directories create just symbolic links to that repo direcories: bin, App_Resources, Css, SystemImages etc.
Is this a good idea? Will ASP.NET MVC app handle this correctly, or I've to add some code for it handle the 'virtual direcotories'?
I would suggest that you take a look Single-tenant and Multi-tenant applications even if you say that your code base is the same for every one.
Here is a nice Multi-Tenancy ASP.NET example
I would also suggest that you check http://appHarbour.com as you can easily push changes from your master repository to appHarbour using Git or Mercurial.
Regarding your exact question, I also keep static files in a custom scheme under Amazon S3, so each client can upload there own files, plus the ones I have and all is based on a single location that does not put more resources just to delivery static files.
You can see my live web application using this technique checking the View Source.
I'm working with modules and each of it will be compiled (deployed) in a common folder in a webproject. In the main class I defined an array of module paths which I need for loading all these defined modules.
How can I make that more dynamically, for instance, I want to say, load all modules in a certain folder an its subfolders without to know each module by name.
You can't do anything in a Flex/AS3 related browser based app to get information about folders on the server.
You're going to have to write a server side service to get the information. Any technology should work, such as .NET, ColdFusion, PHP, Java, or whatever. Then just call the service, and it should send you back the information you need. In ColdFusion, you'd use the cfdirectory tag.