I'm building a mobile app that is a port from a web-app and I'm trying to create the skeleton.
I have an admin center with a lot of different views that share one thing in common, they show all registers, create, update and delete. For example, I have one section for users where the first page shows all users, then there is a button to create and one for update that sends to different views.
The project skeleton would be something like this:
/users
users.html // show all users
users_create.html // creates user
users_update.html // update specific user
users_detail.html // show specific user
/posts
posts.html
posts_create.html
posts_update.html
posts_detail.html
/communities
communities.html
communities_create.html
communities_update.html
communities_detail.html
.... much more the same for other sections
My question is, what would be the best approach to build this with ionic? to have all this folders or just one common folder and resolve everything (number of fields, name of fields, etc) by passing a param to the route?
I ask you sorry if I didn't explain it very well but I hope you catch the idea of what I'm trying to say.
Thanks!
From the awesome book MEAN Web Development by Amos Haviv you can learn that there are basically two folder structures you can opt for:
Horizontal folder structure
A horizontal project structure is based on the division of folders and files by their functional role rather than by the feature they implement, which means that all the application files are placed inside a main application folder that contains an MVC folder structure. As you can see, the horizontal folder structure is very useful for small projects where the number of features is limited, and so files can be conveniently placed inside folders that represent their general roles.
Vertical folder structure
A vertical project structure is based on the division of folders and files by the feature they implement, which means each feature has its own autonomous folder that contains an MVC folder structure.
So, in your case, what I would actually do is go with the Vertical folder structure (since you said the app is (is going to be) big, where you would (in your case) have a users folder where you would then have folders controllers, views, model (in case you're using it) and all the appropriate files inside it. You can view the folder structure in action if you take a look at the project mean.js from the same author as the book.
Related
I am managing around 12 TYPO3 backends with almost similar content. Is it possible to copy and paste a created site between independent backends? Right now I'm creating by hand 12 sites with the same content. There has to be an easier way.
Well, there is not much I could try. Within TYPO3 I don't see any option to export/import sites from other backends.
First of all you should merge those 12 sites into one backend with multiple root sites and trees. Then you can easily handle different domains and/or languages via the site configurations for those roots.
Of course you can then make use of shared sys_folder pages that contain the content elements, that should be available for multiple sites. To make them available for a specific site, you can use references then.
You can export a page tree and import it into another instance.
On the other hand you can duplicate an instance by copying the complete database and original files.
That includes necessarily the fileadmin/ and uploads/ folders.
typo3conf/ should be duplicated by deployment but might differ in the files typo3conf/LocalConfiguration.php and typo3conf/AdditionalConfiguration.php (e.g. each instance should have other databases).
You can use the core extension impexp to import/export content parts. There is even a context menu entry
Be aware of some drawbacks:
if assets are exported, those are exported & imported you can hit the limit of your memory_limit
take extra care about which uids should be used, e.g. forcing uids can lead to drawbacks
Of course there are other options as well like:
create a custom extension which exports/imports the content on the fly using either something like a custom endpoint or fetching directly the DB if possible
use 1 installation as discussed already
if e.g. using ext:news use something like rss feeds for a poor man import/export with ext:news_importicsxml
In which group should store all the images used in the project. Resources group is to store the icon files. Should i create other sources group folder to store rest of all the images used in the project or somewhere else?
Thanks for help.
Groups in Xcode (the yellow folders) can be organized any way you like. If you want separate groups for icons, other images, or whatever else, you're free to create them. (You can even have groups map to different directories in your source filesystem.)
By default, everything in such groups will go into the same place in your built app bundle. It's convenient to keep it that way, since it makes APIs like +[UIImage imageNamed:] simple to use -- just pass the name of your image file and you're done.
I'm looking for a good way to manage many image files in my app.
When the number of images to maintain gets large, it seems vital to have a directory structure to hold them.(to organize images and to support duplicate image names)
Since normal way of storing images in documents directory(by adding images to xcode's resource folder) doesn't seem to support directory structure,
I probably need to use something called bundle.
Here are questions.
It's not clear to me what's the difference between "documents
directory" and "bundle". Are they
just names to specify directory path
inside an iphone application? Since
documents directory doesn't support
directory structure, I guess it's not
a regular file path in iOS? (I'm
looking for a definition or overview
description on those two terms enough
to help answering the following
questions)
How do I create a tree structure directory to store resources?
How do I add files to the created directory?
What is the step (probably in xcode) to add new files to the
directory as project grows? note:
question 3 deals with initial set up,
4 deals with update.
What happens to files under documents directory and bundle when
user updates the app? Since many
applications store user data
somewhere, there must be a way of
updating an app without wiping out the
saved user data. ie. How does
"documents directory" and "bundle"
behave in update situation?
So called "resource bundle" refers to the "bundle" used in above
questions?
Thank you.
Your app is a "bundle". It's represented by an NSBundle object. On iOS, this is the only bundle you are allowed to use; you can't create another bundle and import it into your app.
However, you can add a subdirectory to your app's bundle. In Xcode 4, select your project in the navigator and click on the Build Phases tab. Add a new build phase (bottom right), Copy Files. Move it up just below Copy Bundle Resources, and rename it something meaningful ("copy interface images", or something). You'll notice you've got a Subpath field there - that's your directory in your bundle. Drag the files you want in that subdirectory on to this build phase, and then you can access them through the normal methods in NSBundle, UIImage, NSData and so on.
Wish it was easier? Me too.
Sweet..I bought myself a 1TB portable harddrives this week. Don't you just love how much data you could store on one of these disks? The fact that I could store my bluray rips on to my portable harddisk and that my lg lcd tv can do HD rips right from the drive - that's amazing practicality right there! However, life it seems, is never so simple. I have 100s of movies unorganized in one huge folder, which is exactly what I needed to annoy myself while browsing the same on my tv to play a single movie. That got me thinking...
What if I had an automated way to organize movies into folders such that my folder-browsing-on-a-lcd-tv-or-a-comp would make my life a little easy?
I started thinking about this... I browsed a little in this context and I realized that if only I could "tag my movies somehow and create folders on-the-fly based on tags using hardlinks", I would have addressed my problem. I googled a bit to find software that works in the above fashion, only to find none.
A few more days of serious thought (as you know by now.. I think a lot.. and I guess this question is starting to sound like a blog rant/post of sorts...), in the interest of humanity, I thought I should come up with a generic way to address this: What if someone wanted to organize photos... organize music.. organize software?!
Turned my grey cells off for a while and here is an approach I came up with to solving my what-if scenario.
Tag / Group tag individual files (rely on a slick GUI to do it fast and do it good) - Adobe Flex/Eclipse RCP to do this?
Create hardlinks to each of the tagged files.
The first point is self-explanatory. The second (coz I am talking windows here), refers to making use of mklink.exe.
Consider a scenario where I have 2 movie files: I have a movie file "Transformers.avi" tagged as "english, action, bluray, sci-fi, imdb-top-50, must-watch-with-kids" and another movie file "The Specialist.avi" tagged as "english, bluray, thriller, adult". Here are a few of the possible locations I want to see my Transformers to be found:
[root directory]->all-tags->english
[root directory]->all-tags->bluray
[root directory]->all-tags->english->all-tags->bluray
[root directory]->all-tags->bluray->all-tags->action
[root direcotry]->all-tags->english->all-tags->action->bluray->all-tags->imdb-top-50
Given that windows has a limit of 1024 hardlinks to a single file, I probably would be allowed 7 unique tags per file. Each sub-folder will have an "all-tags" folder. Having it named "all-tags" makes it more accessible when order by name.
I believe this approach when automated to let you configure tags you want and where the hardlinks are created for you, helps you organize stuff effectively.
I don't know if there are better things out there. I would like your inputs on this approach and other possible ideas. I would like to gather inputs here and release something to sourceforge for everyone to use in a couple of weeks. I am sure, I can count on your positive response as always.
I believe hardlinks are not a good approach. Reason? A standalone player won't play them, and I wouldn't like a program who's made for tagging to tell me to stop making so many tags because of a Windows limitation on hardlinks (remembering each tag will increment the number of links exponentially).
Plus, "help" is not a good tag.
And I've had an idea once that I'm still planning to make some day to sort my own files - put the files in a big storage each below a GUID foldername (filename untouched) and store metadata in a sqlite database to be used by a smart file browser.
I was considering doing something similar to this with music for detecting duplicate songs and auto-organize funcationality.
For your application, I wouldn't recommend using any shell programs through Java. Exception handling becomes difficult, and your application becomes bound by the shell interface and implementation (i.e. windows versions or installations affect your application behavior).
I would use a database with a few tables: Files, Tags, and an association table.
The Files table would list the physical location of each file, the filename, and a unique identifier. This way, you can maintain information about each file without having to modify it for every tag association.
The Tags table would list each tag, and any metadata you want to store for each tag.
A third table, maybe 'FileTags' would store the assocation between tags and files. When adding tags to the stack, you would add a statement to the WHERE clause, and the list of files with all of the tags would be returned. This structure would also allow open your codebase up to other designs, such as include/exclude (autocomplete with X buttons), or possibly search.
If implemented in Java, your app would be platform independent, and would allow a very large number of tags and files. You can then use the system default application for opening the media file, and the user can make the selection in their native OS.
Reiser4?
...
(I mean nevermind Hans, but the tech...)
[disclaimer: Not a hacker. I know nothing of programming/coding, never mind filesystems & databases. I can barely code decent HTML even, if at all. Hey y'all! :D]
[footnote: does plain HTML5 work here? Too lazy to close my tags hehe :p]
Do you try to keep it simple and have a root folder and then 1 folder for images, javascript, flash, etc? What do you normally call your folders? Do you give your files naming conventions?
not a standard way.. but from my experience, I come up with this structure:
root/
-> images/
-> <subfolder>
-> upload
-> js/
-> css/
-> data/
-> docs/
-> download/
-> mme/
-> subpages/
-> temp/
-> siteadmin/
root: all 1st level file located there
images: all images. if images for subfolder, then another level there with the same name. upload is for uploaded images.
js: javascript
css: css
data: some raw data if needed
docs: word doc or pdf for download
download: something that for ppl to downlaod...
mme: other multimedia files. e.g. flash, movie.. soudn clips.etc.
subpages: 2 or subsequent level pages. organized in different folders
temp: any testing page store there. private, not public.
siteadmin: if you have an admin site.
I keep it simple, but then my web site doesn't need things that cause complexity. In general, each web page has a name that corresponds to a folder on disk and that folder contains all of the things needed to display that page. The hierarchy of the web site matches the hierarchy on disk.
It depends on the project but I generally go with js/, img/, and fl/. Sometimes I divide root into code/ and content/, but I think that may be overkill. As far as naming convention, I usually have my images perpended with the name of the page they are generally embedded on. If they are on every page, I go with something like global_ or all_. I hope that helps...
If there are many images then a folder for them is useful, however I tend to have 1 JS file, 1 or 2 CSS.
The most useful thing I think is to mod_rewrite all the pages, like stackoverflow does.
It really depends on how many pages your site has. Early on, it may seem like a good idea to simply drop all the pages in the root. Later on, when you have 120 unrelated files sitting there, you may start kicking yourself.
I tend to put together a simple 1-deep hierarchy, broken down by site area. /forums, /photos, /account, etc. I've learned from experience that your page count will tend to grow a lot higher than you anticipated. And I've learned from experience that it just plain sucks to move pages out of the root and into a sensible structure once they have external links. Best do it right from the start.
root
+-+ include
+-- cache
+-- script
+-- css
+-- images
This directory is of course not externally acessible.
Why all under include? Because none of these media files are served directly. They all go through a script that:
Compacts all the CSS files into one file;
Compacts all the Javascript into one minified file;
Writes those versions to the cache directory;
Timestamps css, js and image files and sets the expires header to far in the future;
Keeps cached copies of the compacted js and css files in the cache directory; and
All references to those files goes through an auto version function that uses the last modified time to change the URL to control when the client gets a new copy (eg /css/screen.1234567890.css), similar to what SO does with its query string on such files.
The above can speed up a site significantly.
The rest of the directory structure will mirror the menu structure of the site. If there is an "Orders" top level menu items with a submenu then you can bet you'll find an accounts directory under the root directory.
All this makes the site very, very predictable if someone else needs to come and maintain it. It's extremely important that someone else is able to find their way around.