I am working on a Turbo Gears 2 application. The application directs a user through a set of questions. I like the templating system of TG2 (which of course is the idea) so I want to integrate the static web pages with TG2 also. This will allow me to abstract away the headers, sidebars, navbars and footers.
Please note that I am not talking about placing my 'static' files in the public directory of the application. I created a Controller called WebController and I am serving files through that. Of course the instance name of the controller is web so all my pages are accessible at the URL http://mysite/web/page1.html (for example)
Now the question - is it possible to have all pages at the root level be redirected to /web. That way I can eliminate the /web in URLs for HTML pages.
Thanks for reading.
Ok I realize that my question was somewhat vague. After doing some research on my own, I found out that TurboGears does not use routes by default but uses CherryPy dispatching scheme. http://nxsy.org/unscientific-and-biased-comparison-of-django-pylons-and-turbogears was very helpful in understanding some of the high level architecture of TG.
I rely a lot on stackoverflow to solve my problems as I make progress in my application - so, here is hoping someone else can benefit by reading that discussion.
Related
Instead of using server side MVC like Ruby, Python, PHP to build very complex websites, why should not we split our website into multiple modules, and build each with client side MVC like backboneJS, EmberJS. In this case, we will use PHP / Ruby for creating webservices alone, which will serve data only.
Each module now act as small web app. If we link each other, they will perfectly look like a complex web app.
I visit many websites (like github, groupon, stackoverflow etc...) and they can be built or adopted to this approach. But i am not seeing this kind of approach. Does this approach has any problem on this kind of websites?
Was to long for a comment
I guess the tricky part is indeed the point you mentioned
f we link each other, they will perfectly look like a complex web app.
Because each MVC framework uses a different approach to tackle usual problems you have in modern web-apps, like routing, data binding, application state and rendering DOM elements, so I think you would end up having multiple frameworks doing tasks that overlap substantially, thus forcing you to deactivate or disable some of the built-in functionality of one or the other framework making your frankenstein-app :) very difficult to maintain.
A good example is jQuery-mobile & ember.js, both have a routing system, jQuery uses the DOM to hold state ember.js holds it's state completely in javascript which is much faster. I had a similar problem with a project using jQuery-mobile & ember.js and this forced me to decide for one of the routing systems, I took ember's and deactivated jQuery's wich then let with just a bunch of custom mobile-looking components on the side of jQuery-mobile. Finally I removed jQuery-mobile using ember.js only and CSS for the mobile-looking app.
If not because of a concrete requirement, IMHO your best bet is to have just one very good, flexible and opinionated framework (personally I prefer ember.js) and create the modules you mentioned with your only choice.
Hope it helps.
As of now we can say that most of the applications are forced to put in more effort in its UI/UX and hence the dependancy on server side is becoming very less.
I have personally used backbone for my latest work and this has been great. The speed of the entire application can be noticed from the beginning. Ive been using PHP for the past 3 years and i can definitely vouch that backbone and other MV* frameworks are better.
Combined with CSS frameworks such as bootstrap, backbone can be an extremely organised and elegant applications.
All said, getting your head around models,views,routers,collections can be a headache. This is something which has vast possibilities and its only getting started.
Ive compiled a tutorial based on lots of tutorials present and has published at http://goo.gl/nJumC.
So many video tutorials are also available.
Only per-requisite is that one should have good knowledge of javascript and jquery methods and functions. Beginner knowledge in these will only make your task of learning backbone difficult.
Oh yes. I got my answer.
From google groups:
I think one of the reasons is javascriptless user-agents — i.e. search
engine crawlers and users with NoScript turned on.
I hope, these are real problems why websites still using Server Side MVCs.
When websites don't know target audience, they can't predict how well it will run on client side. So they should rely server to build much of their content.
And think, if stackoverflow was designed using client side MVC's to build much thier content, no one can't reach stackoverflow posts using google search.
From wikipedia under "Search engine optimization" section:
Because of the lack of JavaScript execution on crawlers of all popular
Web search engines, SEO has historically presented a problem for
public facing websites wishing to adopt the SPA model.
I think that is the shift we are heading now; I am not really sure about you but I noticed far more Client Side MVC Web sites. Anyways, you can also take a look at this ....
http://backbonejs.org/#examples
in my view, except the learning curve, it is pretty neat to develop using Client MVC and Web APIs using JSON/REST
I've often developed websites in asp.net webforms with an administration area which is always a folder in the root of the application, where the site also lives. Which will always be compiled into one dll, meaning every small change requires full re-build of a solution - it just doesn't work well.
This is quite a lengthy question so my summary is at the bottom, but I've tried to give as much information as possible to help.
So at the moment things are set up something like this (you should get the idea):
¬ Application Root
- /MyAdminPanel
- dashboard.aspx
- /website-css
- site.css
- index.aspx
However I've recentley starting developing our sites with ASP.NET MVC and using multiple projects in a solution, like:
¬ Solution
- ClientName.Core
- ClientName.Models
- ClientName.CMS.Services
- ClientName.CMS.Web
- ClientName.Services
- ClientName.Web
the .Web projects being the CMS and front facing websites.
Is there a better way for me to structure my IIS applications bearing in mind that 99% of the time there will be an administration area for the website?
There are concerns regarding resources that are uploaded through the administration panel that need to be accessed via the front facing website, so essentially out of the child application and into the root.
This is possibly by doing Server.MapPath(string path) as that will go to the root application, however depending on how things were set up, it could potentially not be guaranteed that the root application is where the file needs to go (for instance if both the front and admin facing sites were both in separate virtual applications).
I'm thinking about the situation here if using HostingEnvironment.MapPath() where the path would actually resolved to the /MyAdminPanel child application, which would obviously not be correct.
Summary
In essence, to cut a very long story short, an ideal situation would be to have a VS solution as mentioned above, with a similarly structured website (though I am more that happy for this to change to something better), where I can MapPath resources to the front facing website and not worry how the website is hosted.
One thing that is important though is that I can build and maintain the projects separately, as some administration will have different functionality from one client to another
If you can come up with a much better structure for all of this, I am more than happy to listen! :)
Thanks for taking the time to check this out.
The solution is elegantly simple -- you really only need to worry about mapping 4 paths here -- just write some utility methods that can:
map a path from the public site http root
map a path from the public site filesystem root
map a path from the admin site http root
map a path from the admin site filesystem root
You'll probably want to make these configuration driven, or at least overridable as this will change in production quickly in scenarios that don't really allow for "rebuild and redeliver software to client" in the timeline.
I am currently working on a web app with a small web page on the root level and several (more complex) web pages in areas.
All area-based web pages have static content that is independant of each other, so each of them has it's own content folder.
Unfortunately the resulting url's for the static content contains the string "Areas", for example
http://myappurl/Areas/MyArea1/Images/myFile.png
Since Areas are a technical implementation detail and nothing that the user should know (or care about), they do not belong in the url.
How can I fix that?
I don't want to create another root-level directory for each area (would be confusing and error-prone), but I don't really understand how I could modify routing to allow this otherwise.
Help would be appreciated :)
By default, ASP.NET does not handle requests to .png files.
Scott Hanselman has an article that explains how to change this functionality. Link: Back to Basics: Dynamic Image Generation, ASP.NET Controllers, Routing, IHttpHandlers, and runAllManagedModulesForAllRequests.
If you follow the instructions there, then you will be able to gain control of how requests to all png files are routed. So, you get to define routes the same way for the file nested within the area as you do for any other View/JSON/XML. The trick is then to set the appropriate content type and render the image as a filestream.
This post has been 'somewhat' addressed (see links at bottom of post) but not to it's full extent.
I am working on building a mobile site in Rails 2.3 (I know, I'm going to migrate to Rails 3 soon). Either way, as I continue developing this mobile site (and I am using Mobile Fu - works great), I'd like to understand best practices around configuring and managing the mobile site:
Where should I redirect to the mobile domain (in application controller)? What is the best logic for doing this?
Should I build the .mobile.erb files in the same folder as the .html.erb files? Or in a separate mobile folder?
What kind of routes/controller/etc logic do I need for my mobile site (if I decide to not embed the mobile rendering inside my current application structure, but instead have a separate controller and mobile view folder)?
I appreciate it.
Other links:
Web and Mobile views best practices same controller or namespace?
http://www.arctickiwi.com/blog/mobile-enable-your-ruby-on-rails-site-for-small-screens
Rather than answer your question directly, I am going to suggest that best practices have moved on somewhat.
Concepts like Mobile First, Adaptive Design, Responsive Design, and Progressive Enhancement are replacing the split site approach as best-practice.
These concepts revolve around building out your site for mobile first (so you can work out what the most important things are) and then extending the design for screens that are larger.
It removes the need to determine if it is a 'mobile' accessing the site and instead relies on various techniques (adapt.js or CSS media queries) to target different layouts to the variou screen sizes. It also means you do not have to maintain multiple views and routing - you have one view and change the CSS.
When you move to Rails 3.1 (with the pipeline) this allows the creation of CSS (and JS) manifests, and you can (potentially) have one manifest for each screen size.
There are issues with the above approach (just as there are with split sites), but if you Google the key terms above you'll find tons of advice. Best of luck either way!
Edit: Here are some links I found useful.
http://www.lukew.com/ff/entry.asp?933
http://www.netmagazine.com/features/mobile-first
http://www.alistapart.com/articles/responsive-web-design/
http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/
http://www.alistapart.com/articles/taking-advantage-of-html5-and-css3-with-modernizr/
http://www.sitepoint.com/regressive-enhancement-with-modernizr-and-yepnope/
There are some that think that this is bad though:
http://nefariousdesigns.co.uk/archive/2011/05/sniff-my-browser-the-modernizr-inadequacy/
I'm pretty new to ASP.NET MVC and I just want ask of this scenario is possible and, if so, could anybody provide any resource links on how to implement it.
Say I have a site that can be accessed from www.mysite.com, can I also have the same site load up through www.mysite2com, www.mysite3.com and so on? effectively providing the ability to run multiple sites from a single code base?
The idea is to have the site content and style sheet change depending on site visited but keep the structure the same.
thank you very much for any help you can provide :)
Kris
Yes, this is possible
http://web.archive.org/web/20100119084358/http://just3ws.wordpress.com/2010/01/03/skinning-your-asp-net-mvc-application-based-on-your-sub-domain
This example uses subdomains of the same domain but nothing stops you from using the same logic and have different images/CSS/paths etc generated based on full HOST/domain name