I'm curious how you would create an rails 3 app that makes it easy to white label it. For example if you had a site that did reviews of food and a site that did reviews movies what is the best way to customize the routes so /foods works on one site and /movies works on the other. Obviously some sort of config but what about if it isn't set, it should probably fallback to /reviews.
On a smaller scale I can kind of wrap my head around this problem but I'm curious how this scales up to say 100 sites. Where you can't really store all their configs in the same git repo and what do you do about custom ways of creating a reviewable model. Since foods and movies aren't going to have the same params and if you let users enter them in there has to be some sort of customization for that.
Additionally i'm guessing each site probably should be self contained in some way to prevent a problem with one site bringing down the rest of them.
I think I'm only scratching the surface here and I haven't been able to find any articles talking about this kind of stuff.
Related
I am very new to Vuejs. I have designed a little online store and now want to implement the admin side where he client can add, edit stock items etc.
My question is simply that I need advice on the following:
Should I do this in the same app just using an admin route in router. If yes then should I create a second store (is this good practice)
should I do this in a separate app (possibly just an express app on the backend)
Well it depends your business model and project roadmap. But can I can mention few things you can consider making your decision. I totally agree with other answer as well.
In my experience having your admin app as an separate app, reaped more benefits(NOTE: In My Experience, your might differ).
Benefits
Less overhead on your routing side. Meaning you don't need to build special permission system on your router to only show what the user is aloud to see(Normal users now allowed to see admin related pages).
Adds a bit of reassurance to know that normal user might not stumble on admin pages which they not allowed to see.
If you want to make a change on your admin side only or vice versa, you only have to build/push production for one app. So eliminating potential stuff breaking on the other app you dont want to build/push.
Drawback
If both apps uses same components you either have to duplicate work done on them or have a component library which shares components between project(I created a component lib in my case, which help a lot later on when we needed to create additional apps)
If an user uses both apps, he have to switch between websites(In my this was trivial because users are most either just using the admin or just using the online shop app)
Cost of hosting an additional website.
As with many things, I don't think there is any right or wrong answer, and will mostly depend on your project and objectives. For me, the determining factor when deciding whether to extend a UI or separate it into its own project will mostly depend on the following factors:
How much overlap is there between the UI designs? If you need to re-use significant amounts of code/styling then keeping it as a single project makes sense.
What's the scope of the additions? If the addition is very minor (a single page or two) then keeping it as a single project makes more sense, even if the overlap is minimal. However, if the scope is extensive with lots of different components and routes, separating the projects might be the better choice.
What's your cost/benefit of time to develop the interface, vs time you (or others) will spend using it.
In the end, if it's a full-fledged back-end you're creating it's often best to take the CMS approach and give it a dedicated backend styling, whereas if it's just a few user preferences you need to toggle, then that might be overkill.
So, kind of a generic question here. Best practices, maybe? I happen to be using Rails, and I built up a site for a buddy. http://ecorebox.com/ - see that banner we have there? It shows how many resources we've helped to save? That can get broken down for each of our clients too.
So, it's come to my attention, that our clients would like that 'banner' on their site to show how they've helped to impact the environment. What would be the best way to accomplish that? I was looking to yelp for inspiration:
process an image, and update the image every few days / weeks?
build a div, and let them put this in their site where they like?
an iframe? is that what it's called? a snippet (essentially) of .js code that creates the div I just mentioned.
Anyone know how yelp does it? What are these things actually called, so I can search the internet more effectively? Dynamic Banners?
There are dozens of different techniques you could use to create a banner with that functionality.
A lot depends on how much of it you want to be image-based, and how much of the information will come from your local data.
I would recommend you start with a rails "helper" method that returns simple data based on what you are measuring (e.g. "*" or "***" or "*****" depending on rows in your models). That should be pretty simple if you just build a rails method that returns this string, put that method in a helper, and call the helper from your view.
Then, when that is working, it should be easy to make it more icon-based. You could replace the "*" with images of stars, etc. Using the Rails "raw()" method wrapped around your output and change the "*" to "" tags.
If you combine that with some clever CSS styling, it will end up "looking like" an image, but will really be composed of data from your rails project plus nice styling.
Have fun
I recommend you to simply buy the banner. There are tons of websites that offer that.
However, I would recommend you a website I worked with in the past: http://www.servicecombo.com/professional-banner-design/
They are really professionals and their service is great. The price is not so bad either.
We all know that showing inexistent stuff to Google bots is not allowed and will hurt the search positioning but what about the other way around; showing stuff to visitors that are not displayed for Google bots?
I need to do this because I have photo pages each with the short title and the photo along with textarea containing the embed HTML code. googlebot is taking the embed code and putting it at the page description on its search results which is very ugly.
Please advise.
When you start playing with tricks like that, you need to consider several things.
... showing stuff to visitors that are not displayed for Google bots.
That approach is a bit tricky.
You can certainly check User-agents to see if a visitor is Googlebot, but Google can add any number of new spiders with different User-agents, which will index your images in the end. You will have to constantly monitor that.
Testing of each code release your website will have to check "images and Googlebot" scenario. That will extend testing phase and testing cost.
That can also affect future development - all changes will have to be done with "images and Googlebot" scenario in mind which can introduce additional constraints to your system.
Personally I would choose a bit different approach:
First of all review if you can use any methods recommended by Google. Google provides a few nice pages describing that problem e.g. Blocking Google or Block or remove pages using a robots.txt file.
If that is not enough, maybe restructuring of you HTML would help. Consider using JavaScript to build some customer facing interfaces.
And whatever you do, try to keep it as simple as possible, otherwise very complex solutions can turn around and bite you.
It is very difficult to give you very good advise without knowledge of your system, constraints and strategy. But I hope my answer will help you out to choose good architecture / solution for your system.
Boy, you want more.
Google does not because of a respect therefore judge you cheat, he needs a review, as long as your purpose to the user experience, the common cheating tactics, Google does not think you cheating.
just block these pages with robots.txt and you`ll be fine, it is not cheating - that's why they came with solution like that in the first place
I know they are, but my co-worker doesn't believe me. He keeps telling me that Google crawls the inside content and caches it just fine. According to Google, it does crawl them, but doesn't guarantee doing it properly.
Any thoughts why frames are bad for public web sites?
There are various usability and accessibility issues with frames:
link can open in the frame it is enclosed in (e.g. a side pane);
can break the forward/backward navigation;
difficult to bookmark;
are not easily searchable (likely to see the content in Google, etc.);
break on browsers like Lynx, that are console/terminal based;
difficult to size properly (e.g. consuming height on widescreen monitors for banner frames);
can break with screen readers and magnifiers (for blind users and visual impaired users);
See http://www.angelfire.com/super/badwebs/ for an example of what not to do.
Frames are more difficult to bookmark and, therefore, more difficult to share with others.
http://www.yourhtmlsource.com/frames/goodorbad.html
IFrames (like HTML tables) are not bad. However, people were abusing them quite a lot, thus giving them the bad name.
IFrames do represent a good concept - single visual representation of documents coming from different sources, while keeping the DOM trees properly separated and isolated.
The problem arises when a script in one of the DOM trees needs to access the elements in another tree. Or when people want to reference the document location, which happens to be the URL of the root document, and fail to realize they need to location of the secondary document.
But the biggest problem with frames is that there are sites that want to encapsulated other sites in frame and trick the user to think they are interacting with the framed site, while in fact interacting with the outer one. This is the primary reason why most websites will employ some form of frame-busting scripts for their login pages.
Update: It's Friday and we need some fun, so here's the (obligatory) link to Jeff's post on frames-busting-busters-busting... :-)
At the beginning ...
The idea behind framesets is great. It's alive and kicking today; check StackOverflow's left side panel, or the header. They are fixed divs, which is basically the same thing as having frames, although a lot more flexible.
The very concept of keeping some part while changing another is simply necessary by the logic of webpages. We need something to stay where it was (typically navigation) while we go through a lot of details in the main area. Framesets served this purpose very well, they were easy to use and fully supported by all browsers, meaning 3 at that time (Netscape, IE, Opera).
Then we scorched the sky
The real, practical problems with frames had nothing to do with their basic concept. Instead, it was us being only human. I followed this whole debate very closely so believe me when I say these were the real charges against frame technology:
Designers hated them. Yes, that was the deadliest punch. Everything looked square and straight. They hated it. They wanted arcs and image backgrounds and rounded borders. Now they have it in CSS3 - guess what, they're drawing squares. #whatever
Programmers had trouble with them. It was inconvenient to follow the logic of frames, and you had to do some extra work. I mean, some. Today it's a lot harder to create AJAX solutions for the same problem, but no one complains. #whatever
Websites could include one another. This was painful for some site owners because they worked hard on something and another fella used it as own content. Later, they invented same origin policy, but it was way after starting to hate frames. Content stealing is still an issue today, absolutely unrelated to whether we have frames or not. #whatever
Back button worked differently. Yes, it was a bit annoying. But it was not the frame concept's fault, again: it was browsers who did this to us. Could have been solved easily, but nah, browsers kept going back one by one, not providing the site a way to implement its own "step back" method, and alas, this is still happening today. #whatever
So instead of coming up with a solution, the world's web developers decided to hate frames. They ditched it, and now we live in a world where there are lots of better solutions - but with a lot more effort. This was not the only feature going thru the hate-ditch-reinvent-love cycle; see vertical centering and flexbox, aka the table tag debate - and it will happen many more times because it's always easier to point fingers at something than to learn why it's great.
I don't hate frames; don't miss them either, they belong to a somewhat outdated world of web. But they were a good solution for something, and there's a chance we'll see something similar in the future just as CSS grids came back to implement what table layouts did before. The same community who hates the old solution will happily embrace the new and tell you why it's not the same at all.
I think this story has a single takeaway:
Implementations come and go.Concepts stay and evolve.
Depending on what you want to do, most things done with frames can be done with CSS. CSS stylesheets are compatible with all MODERN browsers, meaning your website will look the same if using firefox, chrome, or IE 7(with some tweaks). Also backward-compatibility is not a concern as users can view the content even with CSS off (where as a website using frames and without a frameless version of the site will be useless to a user with an old browser), it just won't be as stylized. It's also quite easy to learn, and once you get the hang of it you'll wonder why you haven't learned it in the first place.
I know this is an old thread but..
Been using Frames almost all my life and I think they are great. I still have a few websites using frames and I cannot understand why they are being droppped. Read all of the comments above and disagree with most of them. Problem is most people never bothered to overcome the issues.
Link can open in the frame it is enclosed in (e.g. a side pane);
Yes it can, but if you do it properly it does not matter. Frames can in fact be very useful for this precise reason, as clicking on a link will only refresh the frame the link it pointing to, not the entire webpage. In the days of dialup modems at very slow speeds this used to be extremely useful to save on bandwidth and make webpages appear superfast. Dont forget, there are still people around the world today (albeit not many) that have very limited internet connectivity at very slow speeds. (people on sailboats in the middle of oceans, those die hards that dial into the internet using HF radio. Oh and those that live in war zones that revert back to poor mobile phone signals, or possibly even need to dial into the internet in another contry using their infrared connections on mobile phones via a modem)
can break the forward/backward navigation.
Yes it can, but if you do it properly it wont.
difficult to bookmark
again very easy to overcome, requires very little additional work, but can be easily overcome
are not easily searchable (likely to see the content in Google, etc.);
break on browsers like Lynx, that are console/terminal based;
Already covered by somebody else earlier. Personally I have never even heard of Lynx (apart from the deodarant). In fact it used to be quite useful that pages werent searchable when you did not want to get spammed by bots searching for email addresses... Unfortunately Google or somebody figured out how to do it.
Difficult to size properly (e.g. consuming height on widescreen monitors for banner frames);
Clearly whoever wrote this has hardly any experience of using frames. This was exactly why I used frames because I could make it work on any screensize in what some would refer to as Fluid views on modern web design
can break with screen readers and magnifiers (for blind users and visual impaired users);
I suppose it can if screen reading software and maginfiers are cheap and rubbish and dont know what they are doing, probably them that complained about it, but there are others that manage this easily.
The only argument that I think makes sense, is that people were abusing them. Now I would not know how that was done, as I am not in that game, but I suppose it would be easy to use frames to show a copy of lets say a financial payment page inside another another frame which is completely hidden to make it look like the user is on the correct page. Therefore conning users out of their beer tokens. But I believe more modern webbrowsers have been updated to overcome these issues and not allow re-direction where encryption certificates are used.
I can therefore understand why they would want to restrict the use of frames, but dont understand why they need to completely remove what is a pretty good bit of tech. (Bit like saying we are going to stop people from using 0 when they do math as it causes can sometimes cause problems when you add many 0's together.)
I still have some websites that use frames and wonder when I am going to have to re-code them one day.
PS. also note that google calendar and youtube allow one to imbed pages into websites and both of these use iframes.
My boss wants to change our dynamic web site into static one, in order to make it more interactive between users.
However, I strongly believe big revamping may cause ranking turbulence, and we really can not afford to it. The reason is we changed the structure of our web site couple of months ago. Specifically speaking, we eliminated lot of pages and congregated the content into one page. i.e. putting images, tutorials etc. of a product into the pages under relevant products. Then following suggestions from experts, we redirected all of eliminated url via 301 to the corresponding product page. Unfortunately we experienced over one month decline of our page ranking in Google. That why I am so anxiety of our performance in search engines.
I figured a wild solution though. But I am not sure if it is doable! So please give your idea!
I want to maintain two sites at the same time for a period, one is dynamic, and the another is static. One will be presented under www.<><><>.com while the other is http://<><><>.com. and the latter should be static.
If everything goes well, maybe one or two months later, I can pull the static site: http://<><><>.com down.
Am I dreaming?
Thanks for your time for the lengthy reading and suggestion.
This is the wrong place to ask the question, but it's a horrible idea.
Maintaining the old site at a similar URL will confuse users and only delay the problem rather than solve it. A demo phase (YouTube, GMail, Google Ads, etc did this with their interfaces) where users are given the choice to switch to a new interface (cookies!) can ease radical transitions, but eventually you'll just want to make a clear cut.
If you fear bad consequences for your page rank, make sure the new site is better and redirect all indexed old links to the appropriate new sites where possible (at least for a transitional period).