I would like to include static content as part of my normal rails views e.g. marketing content which can be text or images or both.
I would want marketing content to be separate from my rails code so that it can be separately updated.
I do not want to use content management systems.
Oh and I cannot not use DB, its an api driven app.
Is there a proper rails way of achieving this?
Update:
sorry for not being clear. I can probably explain it better with an example: I need to place some images/text on my login screen that are not part of my apps source code. That live some where on the server that can be updated async without going through my apps revision control system so they cannot be in the public folder of my app
You can put your static marketing content in the public folder of your rails app. Your question is a little unclear and so I'm assuming you are creating a rails app to do api stuff and then have static marketing content/website.
Related
I'm wrapping up my Ember application and I want to figure out the best practice for handling the public site (/, /about, /faq, etc). Ideally the Ember JS and the majority of the app itself wouldn't be loaded.
There are a couple options, but I'd like to know the best practice.
Option 1 - Part of the app
Just make the public pages templates within ember-cli.
Pros:
Same asset pipeline
Single delivery of your entire site
Cons:
How do you have two base templates? One for the public site and one for the app itself. Ideally I'd be able to have different nav bars for each part. Everything inherits from the application.hbs template but I don't want to put conditionals in there to handle the two nav bars. I also don't want to overwrite every other page in my app to put it under a different template (/app/*).
The entire app would be loaded the first time the user goes to the page (only gets slower as the app gets bigger).
Option 2 - Part of the public folder
Create static HTML in the /public folder.
Pros:
Same asset pipeline
Single delivery of your entire site
Not loading the entire app for public pages
Cons:
You have the write the entire HTML for every page. This doesn't allow for quick development.
No template system. As the public site grows it's best to have a template so you can easily change the nav bar on all pages.
Not sure how to handle / since ember-cli wants to handle that url, but I'd want it to be apart of the public site.
Adds a lot of junk to your public folder since you'd need to add about/index.html for good urls.
Option 3 - Separate from the ember-cli project/app
Create a nanoc site or some other statically generated site and deliver it for your public pages.
Pros:
Have properly layouts for public site
Separation of assets
Not loading the entire app for public pages
Cons:
Need to figure out how to properly deploy separate apps on the same domain (putting ember-cli under /a/ is easy, but if I deploy to heroku how do I serve up multiple heroku apps on the same domain?).
How should /sign-up and /sign-in be handled? Public site with public site chrome, or web app with a signed out state (not ideal).
I would go with first opinion. About your questions about two base templates > you can hack it in router to show exactly what you want.
Here's the link about similar issue: https://stackoverflow.com/a/14231712/4560056
Separate.
Use your .htacess file or whatever the equivalent configuration mechanism is for your server setup to control when your app should have responsibility for serving content and when it should not.
I am new to canJs. Looking for a good application structure for building a canjs app. I would like to separate the Model, controller and view/template logics to separate folders. The todo app available in canjs site is a simple one which has everything written on a single file. Any help is appreciated.
Thanks in advance
Justin Meyer always says "The secret to building large apps is to NEVER build large apps. Break up your applications into small pieces. Then assemble those testable, bite-sized pieces into your big application."
Let's assume that I have 2 models in CRUD app, so we can break the app into small apps lets say accounts app, transactions app, each app is broken into small testable pieces so the adviced structure:
in this example accounts and transaction are traditional controller that listen to can.route to update the state of the app; list, edit ...etc are views that are extended from control too but they listen just for their events (Single responsability principal) the communication between the different controllers and views is made by can.Map and can.compute (Observer pattern) to make them decoupled, take a look here and here this can be helpful too.
Previous answer is quite good but you can do it automatically by using yeoman.
You can also use yoeman to create your canjs application structure automatically.
All you need to do is in your terminal type this commands:
npm install -g yo
yo canjs
and write the directory and app name it will be asked during the app creation.
If you want to add AMD support then type Y when you have been asked for requirejs.
For more information visit yeoman website
I need to be able to serve different versions of my whole site per client. Certainly beta vs production but it would be nice to serve one or two prior production versions. Client customization is encouraged and I don't wish to force all clients to follow the (anticipated) pace of development.
Which version to serve is stored in the db.
From what Ive read so far a custom view engine may be the most straightforward way to accomplish this but before heading down this road I would welcome any advice and comment.
Thanks for insight!
Eric
EDIT: It isn't just the views that are different; controllers, master pages, images, CSS...
If the rules regarding which version is displayed to which user, I'm guessing they need to authenticate first. If that's the case you'll have opportunity to set a cookie on the user.
I would probably set a cookie on authentication that determines which version to show the user and then use a URL Rewriter like IIRF to direct requests with that cookie set to the beta version of the site.
Has the added benefit of users being able to opt back to the production site if they have issues with the beta.
I went down the view engine route How do I implement a custom RazorViewEngine to find views in non-standard locations?
Basically it's pretty stright forward, we have the same controllers models, etc. All the code is shared. The rendering of the views though is based on a "brand". So the view engine is clever enough to say if I'm brand A then the view will live in {standard view location}/brand/viewname.
It's hierachical though so if the view is in the branded folder it uses that one, else it falls back to the default location. It's basically an extension of the standard model used by MVC to find the location of the view source.
I got sick of rewriting login forms and user account management pages with the usual use-cases of registering a new account, changing password, changing e-mail, w/ associated e-mails. (This is for clients that won't accept an OAuth/OpenID solution). So I am creating a sample site with Sinatra and Datamapper that contains nothing but those features in their most distilled form.
What I'd like to do is package that site into a gem that someone could drop into an existing app and customize. I think it could get tricky because the app defines its own database and web server. So they would have to be redesigned as mix-ins for a Sinatra::App and Datamapper::Model.
Has anyone else tried this?
I created the Ruby gem "accounts" to provide this functionality for web-apps using Sinatra. It can be cloned or forked at https://github.com/lsiden/accounts.
I'm considering building a new web app with totally with static "html, js, css" file and
make asynchronous call (AJAX) to gain access to DB, some calculations and handle sessions.
So the static files will have basic DOM structures and css applied form only at the beginning
and static js code will asynchronously communicate with server to show page contents
dynamically.
What would be good and bad points of making a web app like this?
and do you recommend or not recommend this way of developing a web app?
I have built a a decent sized web site with this pattern. I feel that this is the current method of developing sites as there are no page post-backs. A fully AJAX site is more 'Web 2.0', if you will.
Debugging can be harder with this setup, but if you're careful (which isn't that hard to do with a brand new site), it shouldn't cause you too much headache. I would recommend you go this route.