Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have zero web programming experience but has been in IT industry for a while, mainly as a CRM technical consultant. I'm familiar with VBScript and Javascript, not in a Web context but as general scripting tools. I'm good at designing business processes, database models and using DB queries. I have some basic understanding of GAE and Python by doing the tutorials by Google. I used to write some tools with C# and VB6 a long time ago.
So I've decided to build my first website on Google AppEngine, and I'm lost in so many choices and new skills to learn.
What I'm planning to build is a simple website where users can post short messages and vote upon them. Which requires a simple but dynamic front page, login/cookie handling, Reddit like post voting/aging and some data storage.
Maybe the first question is which framework should I use? I heard Flask is good for beginner to learn web programming and webapp2 is easy to start since it's integrated to GAE by default. I've looked at Django as well, it looks very powerful, but I couldn't decide.
Since my idea is largely based on a concise but dynamic front page, I guess something AJAX is a must. But I have no clue on where to start. All those Ajax, Jquery, ProtoRPC are so confusing. Which technologies should I use and where can I find good tutorials?
I am also looking for suggestions on potential challenges and anything I should learn to achieve my goal. Thanks!
Since your project is inspired by reddit, the web development course with Steve Huffman (the technical founder of reddit) will be extremely helpful for you.
https://www.udacity.com/course/cs253 - it's free if you just watch the courseware. He even explains their aging algorithms in the end.
This course covers the back-end side of building a python applicaiton with the default webapp2 framework on appengine. He doesn't cover the front-end besides the basics (HTML forms and tables, stuff like this).
Now, Jquery is a Javascript library which is used by about all of the dynamic websites. It is a convenient way to work with the DOM on the fly. Everything you can do with jQuery, you can do with plain javascript, it's just that jQuery is infinitely easier to work with.
This library is used on the front-end, and it doesn't matter what backend you choose. It is extremely simple and powerful and you can learn the basics at the free codeschool course try.jquery.com.
Basically, if you want something to happen on the page dynamically (the arrow becomes red once the user clicked on it), you use jQuery.
AJAX is asynchronous communication with the server, it can be done by plain javascript but jQuery provides a very convenient wrapper for doing it. Usecase: the user clicked on the arrow, you painted it in red with jQuery, you incremented the votes counter (again with jQuery), and now you need to send the upvote to the server without reloading the page. For this you perform jQuery.ajax() call, and pass the user data as a param.
So to wrap it up: you need to write javascript to make a dynamic page and jQuery is the most common library that helps you with this. You need AJAX to get and post data to the server without page refreshes, this is implemented in jQuery. You can use jQuery with any back-end framework that you choose. Start with the simple jQuery tutorial, then read about $.ajax call and it will be clear for you.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I realise this might be a little vague but I honestly don't know where else to ask. I have some history with PHP and I am trying to teach myself ASP.NET MVC3.
While I can find a LOT of source material on syntax and tutorials on various parts. I've started it off and I've got quite a bit going but I'm finding it a bit difficult to figure out exactly how to design the whole thing with regards to where to put things and I'm not entirely certain who I can ask or where I can find these things out?
The project I'm working on, in an attempt to teach myself is a form of online rpg game site. I've got user registration and log in, I wrote a custom membership provider to fit that to my existing database structure. But the trouble I'm having knowing where to do database lookups and how to store data etc. For example, let's say you log in, you have a certain amount of gold. On the right side of the status bar on the _layout page it will always display this value. Where do you look this up? How do you remember it? In the controller? Which controller? Etc etc.
Can anyone maybe recommend either a good set of advanced tutorials or some kind of forum where this can be discussed?
Thanks!
I learned everything i know from:
Getting Started with ASP.NET MVC 3
ScottGu's Blog -> awesome blog entries on mvc 3
Must see the Music Store Tutorial App
Check out a great book by Steve Sanderson - Ive used the previous two editions to get me upto speed with MVC.
Pro ASP.NET MVC 3
If your looking to use Entity Framework then I can also recommend;
Programming Entity Framework
The MSDN and ASP.NET sites have a LOT to offer on MVC3. I would also suggest buying the two MVC3 books by Phil Haack and Steve Sanderson.
http://www.asp.net/mvc/tutorials/getting-started-with-aspnet-mvc3
http://www.asp.net/mvc/tutorials/overview/creating-a-mvc-3-application-with-razor-and-unobtrusive-javascript
http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
http://msdn.microsoft.com/en-us/library/gg416514%28v=vs.98%29.aspx
http://weblogs.asp.net/jgalloway/archive/2011/03/17/asp-net-mvc-3-roundup-of-tutorials-videos-labs-and-other-assorted-training-materials.aspx
Those are all good links and tutorials. In addition, you are going to want to have a separate database for your data vs. your Authentication and Authorization. This will allow decoupling and better security. You should be storing data in a database, and then the model will hold access to that database through a DAL (Data Access Layer) usually with the controller holding an instantiated repository of the DAL. In this sense the controller can build objects from the model (and thereby from the database) and then send them to the view through strongly typed objects for you to use in a User Interface.
Nerd Dinner is a pretty good sample of the whole picture, you can download the sample code and play with it.
http://nerddinner.codeplex.com/
The problem I find is a lot of examples don't use best practices for MVC in favour of simplicity and ease of reading in tutorials. So I'll outline some of the things I've found out the hard way and that work for me.
Personally from what I've found is your controller should be responsible for handling information via ViewModels to act as Data Transfer Objects (DTOs) between your business logic and your views, and that's all they should have in them. I choose to never have business logic in the controller and instead opt for a series of service classes designed to deal with their own group of responsibilities (IoC takes care of most concerns the Services may have).
This is done to keep the business logic DRY and to make it easier should you decide to try making a mobile version of your site later, or maybe expose a public WebService/API to your data.
The views should each use ViewModels specifically meant for each view, and these views should ONLY consist of primitive types or other view models. Never use a data entity from your ORM directly, though I'll be honest I have been known to break my own rule on this when it comes to views that only display information, but I usually pay for it later. Validation rules imposed on your data model are not necessarily applicable to a form and data loaded on your entity may not be relevant to your view either. ORM's that support Lazy Loading complex data entities can cause havoc with some VERY useful 3rd party libraries you can use in MVC like MiniProfiler and Glimpse, not to mention other issues when it comes to rendering these objects in forms for posting back later. So try to stick to flat ViewModels if possible.
I typically name my ViewModels according to their use. so my Register page may use a model called AccountsRegisterViewModel. However when I postback I usually use a different model called AccountsRegisterFormModel. This is because many times there is information I need to pass to render in the view but I really don't care about it (nor will it be present in most cases) on the action that accepts my postback. Also, MVC requires you to disambiguate your actions that use the same name via different parameters so using different view models helps there. For example CreateAccount() to show the account creation page and CreateAccount() that accepts your submission from the form. Though you can explicitly change where each form posts, the main focus with MVC is convention over configuration so I try not to change where forms post back to.
For your specific example of showing relevant information (Gold balance) you're likely going to want to create a Child Action with it's own view that would be responsible for doing it's own data access, or if you want to try your hand at ajax, have the balance be something handled in a smiple partial view that makes a call to a public action that returns JSON.
Those are the practices I've found have worked for me so far.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 10 months ago.
Improve this question
So I actually saw a full ajax site somewhere (I forget where) and thought it would be something new and fun to try. I used an old site I had built and put it on a new server. With a little bit of jquery and ajax, I was able to make the entire site work on one page load.
My question is, what are some pros and (more likely) cons to this method?
Please note - the site works through a semi clever linking function. Everything works perfectly fine if the user doesn't have javascript enabled, the newly requested page loads like it would on any other website.
More detail -- Say the user loads the homepage of the site, then logs in. When they log in, the login box fades and reappears with user info. Other content on the page loads as necessary upon logging in. If they click a link, lets say "Articles", one column on the homepage slides up and slides back down with the articles. If they click home the articles slide up and the homepage content slides back down. Things like posting comments, viewing profiles, voting on things, etc. are all done through ajax.
Is this a bad method of web design? If so, why?
I am open to all answers/opinions.
IMO, this isn't "bad" or "good". That depends completely on whether or not the website fulfills the requirements. Oftentimes, developers working on AJAX-only sites tend to miss the whole negative SEO impact issue. However, if the site is developed to support progressive enhancement (or graceful degradation depending on your point of view), which it sounds like you have, then you're good. Only things to prepare for are times when the AJAX call can't complete as expected (make sure you're dealing with timeouts, broken links, etc) so the user doesn't get stuck staring at a loading icon. (The kind of stuff you'd have to deal with in any application, really.)
There are plenty of single-page websites out there using heavy JS and AJAX for the UI and they are great. Specifically, I know of portfolio sites for web designers and web app development teams that use this approach. Oftentimes, the app feels a bit like a flash app, but without the need for a special plugin.
"Is this a bad method of web design? If so, why?"
Certainly not. In fact, making web-pages behave more like desktop applications, whilst remaining functional to ALL users, is the holy-grail of web-design.
I say, as long as you consider ALL your users, i.e. mobile/text-only/low bandwidth/small screensizes then you will be fine. Too many developers just do it for their huge 19" screens and 10Mbps, that users to get left behind through almost no fault of their own.
It depends on the user
This relates closely to UX, IMHO, though of course it's on-topic for programming solutions.
All-AJAX is often called "managing state" 12 years after this Question was asked.
From my experience in:
Creating a platform for API plugins
Creating two of my own CMS web apps for different purposes
Managing many different WordPress.org sites for different purposes
Managing my own cloud servers for both PHP-AJAX and Node.js doing these calls
...it depends on what is most efficient for users.
Consider these scenarios:
Will users be clicking around this website all day long or for at least an hour adjusting many different options and <form> inputs?
Or will many users visit briefly to perform just a handful of quick tasks?
State-managed / all-AJAX is by far best for scenario 1, with Facebook and Gmail as prime examples.
Whole-page loads are more efficient for scenario 2, like blogs, especially with pages linked directly from search results. That might apply to webstores like Amazon, maybe, where users search Google to find one or two products, then leave.
Philosophically, I've heard that the difference is about the number of users and traffic, but I don't quite agree. It's more about how much clicking and <form> sending the primary target user will be doing.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
My friend and I are building a website together, and he is insistent that page refreshes are a thing of the past and that we should build the whole website in AJAX. His only reason why page refreshes are 'annoying' is that they are too slow.
However, the page is running fine without AJAX currently and when I click from page to page, it seems instantaneous to me. It doesn't seem that it would benefit from additional speed, but he just says I'm being stubborn.
I do want to use AJAX for certain features and pages within the site. I feel like I understand the pros and cons. He references that gmail is made in AJAX, but the url changes as I go into different mailboxes, so I don't think it is 100% AJAX.
I reference wikipedia, which is actually much more similar to our site, as an example of a highly succesful website which doesn't seem to NEED AJAX. But he says that's just one example, and that I am fixated on on wikipedia.
Some personal rant:
1. When I tell him that AJAX is great, but that most of the internet will still require page refreshes and page links, he thinks I'm crazy.
2. When I tell him that using AJAX when not needed will make the back-button useless, he tells me that I'm obsessed with the back button.
3. I think AJAX is something that can be added later to make functionality smoother on certain features, but that it is OK to build the core of the website without it for now.
What is your opinion on the matter? When is ajax really needed in a website?
Thanks
No, Ajax is not necessary for a website to be great. But it can improve usability if used correctly and not overused.
A site built entirely with Ajax and non-functional with JavaScript disabled is a nightmare. No navigation back/forward. No bookmarking. Not to mention its effects for SEO, that is the site will be invisible to search engines.
The golden rule: build the site in classic fashion then add little elements of Ajax to improve usability now and then.
For certain advanced functions it might be okay to be only available as Ajax, but try to make sure the most of the site is at least accessible in read mode when JavaScript is disabled. StackOverflow is a great example of that approach.
My rule of thumb is - what are you building: a website or a web application?
if its a website, content should just NOT be loaded via ajax. It breaks many assumptions that the end users have about the website. Other problems:
1. SEO
2. back button breaks
3. more work to do on your side to make the website UI consistent
4. placing relevant ads will be more complicated
An excellent example is wikipedia.
If its a webapp, then ajax can really help:
1. you can design better user interaction
2. the user will actually expect the app to behave like a rich app, and not like a website.
3. you can dramatically increase the responsiveness of the app using ajax.
I hope that helps.
Of course, AJAX is not necessary to build a great website. It can, however, improve the user experience in certain situations. It is necessary to carefully study and understand your requirements, the structure of your site, and the navigation your users will undertake.
One important thing to consider, however, is bookmarks. Using AJAX extensively makes it extremely difficult to be able to simply bookmark a certain spot or "state" of your website.
Sorry to not post on topic, but I agree with the answers other posted (AJAX in great if not used too much.) It also DEPENDS on the website, if it's more like a web app where you don't need SEO and bookmarks (like gmail) you can go with full ajax (try GWT), if it's content rich- go with just a little AJAX.
But what I wanted to underline is the relation with your friend: you have to be careful when you start a big website with somebody else. If your fight is too big for such a detail you'll have much more problems later.
Get a website that supports a lot of connections, see how they do things and you might understand where and when ajax is used. Start looking at StackOverflow for instance.
This entire site is serving 16 million
pages a month and we are doing it off
of 2 servers, which are almost
completely unloaded. The Microsoft
stack is a pretty good stack.
Joel Spolsky, StackOverflow.com
Form validation using Ajax is the way to go.
I hate clicking "Submit" only to have the page return in a few seconds saying my password is not strong enough or that user ID is already in use. It should be instantaneous while I'm filling in the fields!
As far as StackOverflow, I think it's great how when I click on "Show additional comments", I see the spinner and then they immediately appear. When I change the sort on the answers by "newest" say, I hate how the page refreshes.
I don't think you need Ajax for a site to be great. That said, more sites that are great make use of Ajax. Good RIAs are awesome.
I dont see a lot of ajax on Digg, ArsTechnica, LifeHacker, and the such. Those are all (subjectively) pretty good sites.
No, you don't need it. It just needs to perform well for what your intended audience needs.
Yeah I think you do need it, having to submit pages is so pre-millenium.
More seriously, if you are presenting data, I really think it improves the user experience if asynchronous calls to server are used and the returned data displayed without the need for a complete page refresh.
I remember the first time I saw it used (years back) I was extremely impressed, awed even.
Anyone got example of dynamic, data driven websites that look great and don't use ajax ?
AJAX is not an absolute NEED for a website application. It does not necessary mean that your page will be faster. A lot more things determine page speed, such as:
client side minifying (css and js)
image compression and sprites
server location
and much, much more
Of course, applying AJAX in some strategic point of your website will be where you will most benefit from it. Use it where there is likely to be a lot of activity from your users. I personally always make my website without any http requests handling at first, and then implement the rest by adding AJAX where there is the much concern.
I think your friend is being a bit too concerned about AJAX. Like everything in life, it always tastes better with moderation.
One potential downside of AJAX, when misused, is that content can't be bookmarked.
Try and follow the rule of thumb, that the user should be able to link to content by copying the URL from the address bar. There are several ways to achieve this, with traditional page loads being one.
AJAX is not a must for any website. But if your website has voting, save as favorite, or add to cart, etc ajax will definitely add value.
Closed. This question is opinion-based. It is not currently accepting answers.
Closed 7 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Some people consider WordPress a blogging platform, some think of it as a CMS, some refer to WordPress as a development framework. Whichever it is, the question still remains. Is WordPress MVC compliant?
I've read the forums and somebody asked about MVC about three years ago. There were some positive answers, and some negative ones. While nobody knows exactly what MVC is and everybody thinks of it in their own way, there's still a general concept that's present in all the discussions.
I have little experience with MVC frameworks and there doesn't seem to be anything about the framework itself. Most of the MVC is done by the programmer, am I right? Now, going back to WordPress, could we consider the core rewrite engine (WP_Rewrite) the controller? Queries & plugin logic as the model? And themes as the view? Or am I getting it all wrong?
Thanks ;)
Wordpress itself is not architected in MVC, but one can build very MVC oriented themes and plugins within the framework. There are several tools which can help:
WordPress MVC solutions:
Churro: # wordpress.org/extend/plugins/churro
Tina-MVC: # wordpress.org/extend/plugins/tina-mvc
Plugin Factory: # wordpress.org/extend/plugins/plugin-factory
MVCPress: http://mozey.wordpress.com/2007/01/22/mvcpress-screenshots/#comment-3634 (abandoned, but interesting ideas)
MVC threads on WordPress.org Ideas and Trac:
http://wordpress.org/extend/ideas/topic/mvc-plugin-framework
http://wordpress.org/extend/ideas/topic/complete-reestructuring
http://wordpress.org/extend/ideas/topic/rewrite-wordpress-using-mvc
http://wordpress.org/extend/ideas/topic/wordpress-theme-revamp (more on XSL than MVC)
http://core.trac.wordpress.org/ticket/12354 (on MVC in widgets)
Wordpress is kinda-sorta MVC. If anything it is a pull-type MVC layout, where the View 'pulls' data from the model. It does this in a very proceedural way, instead of using lots of different objects, but this actually makes the front end templates easier to write in a lot of ways.
This also gives the views some degree of controller logic (thus the kinda-sorta MVC).
Lets run this down:
Wordpress gets a URL. The wordpress core acts as a controller and determines what initial queries to run of the database, and by extension, what view should be loaded (category view, single post or page view, etc). It then packages that INTIAL query response and sends it to the view file.
That view file CAN be a strict display only file OR it can request additional information/queries beyond the built in one. This is the pull-type of the MVC, where the view pulls data from the model instead of the controller 'pushing' data from the model into the view.
Thus, when the view sees code to load a sidebar or widget area, it asks for that information. However, what widgets should be there is determined by the controller, which looks at the model for what widgets are in the sidebar, and then selects those that are set to show on the current page, and returns those to the view.
That each part of that isn't an object doesn't make this any less MVC. You can alter WP core without (necessarily) altering anything about a theme. Similarly, as long as you use built in functions like 'get_pages()' then the model and the database tables could change as long as those functions still returned the right data. So, the model is independent of the view, and the controller is independent as well (except when the view adds controller logic to do more than the core normally does).
While you COULD have a model object holding a number of methods and stuff like WPModel::get_pages('blah blah'), and contain everything that way, there is still fundamental separation of concerns.
View: template files
Controller: WP core
Model: the various functions that handle specific data handling.
As long as the names, arguments, etc, stay the same (or just have new ones added) then separation of concerns is maintained and one can be altered without disturbing the others.
It isn't a super-clean version of MVC, (especially when hooks get involved), but at a basic level it starts there.
And being proceedural about it isn't a bad thing IMO. A request from a website is pretty inherently proceedural: it is a process with a clear beginning and end, and just needs a procedure to process the request, get data, package it, then die. You can set up those steps with objects and object methods and OOP layouts (which would make some things easier) or you can just write alot of function calls and separate them out that way. Class members like private variables are lost that way but depending on the needs of the application... you might not care.
There is no one-grand-way to do development, and WP sits at like 20% of websites so it is doing something right. Probably something to do with not making people have to learn/memorize complex class hierarchies to get the database to answer the question 'what pages are child of page x?' and deal with that data. Could you make it that easy with OOP? yes, but if Joomla is any example of how hard it is to implement a complex custom website with OOP, then WP is FAR easier and quicker, and time is money.
As already mentioned in the comments, MVC is an architectural design pattern, not a specific framework, and no, Wordpress doesn't follow the MVC pattern.
There is a separation of views (templates) from the programming logic, but only in the frontend, not in the admin panel and a general separation of views and application logic is not inevitably MVC. An implementation of the MVC pattern usually assumes some kind of object oriented programming paradigm behind it and Wordpress is mainly implemented in a procedural way, with plain SQL queries in the PHP functions, therefore not having an actual model either.
One of the topics that periodically crops up in discussions as it relates to WordPress is the idea of WordPress and MVC.
But the thing is that MVC is not the silver bullet of web development that we try to make it out to be. Yes, it’s an awesome design pattern, and I personally think that it fits the web application model like a glove, but not every framework or platform implements that design pattern.
Case in point: WordPress is not MVC.
And that’s okay. I think we need to leave the desire of trying to shoehorn it into our projects aside especially when the pattern WordPress provides is not only sufficient, but works well when leveraged correctly.
“But I Love MVC!”
So do I! In fact, I spent the last year working on a project that more-or-less mimicked the MVC architecture.
A high-level example of MVC.
A high-level example of MVC.
For example:
Views were implemented using templates
Controllers were implemented by a combination of using function names like create, read, update, destroy, delete, and so on (even though these functions were hooked into the WordPress API
Models were functions also were called to validate and verify data prior to serializing the data. Again, this required that certain functions be hooked into WordPress to achieve the desired result.
Finally, a set of rewrite rules gave the application a clean set of predictable URLs in the format of /people/update/1 or /people/all.
What Pattern Does WordPress Implement?
WordPress implements the event-driven architecture (of which there are several variations such as the Observer Pattern).
In short, you can conceptually think of this as the following:
Things happen when WordPress is processing information.
You can register your own function to fire when these things happen.
Not too complicated, is it?
A high-level example of event-driven patterns
A high-level example of event-driven patterns
When you begin to think in terms of the paradigm in which it works rather than trying to make it work the way that you want it to work, it’s liberating. It helps to solve problems much more easily.
The bottom line is this: WordPress implements the event-driven design pattern, so even if you end up trying to implement MVC, you’re still going to have to utilize the hook system.
If you’re not careful, you can end up trying to craft the perfect architecture without actually getting your work done, and thus end up finding yourself so high up in the atmosphere of software that you’ve effectively become an architecture astronaut.
So You’re Saying Avoid Design Patterns?
Not at all! Design Patterns serve a purpose because, above all else, they basically give us solutions to previously and commonly solved problems. Use them!
But the point I’m trying to make is that we don’t need to try to force things to fit pattern just because we like the pattern. That’s not their purpose. Instead, leverage the primary pattern that your platform of choice implements – in our case, it’s an event-driven pattern – and then implement patterns where they fit (such as dependency injection or something like that).
Otherwise, it’s like trying to put your foot in a glove.
Courtesy (and totally copied :P) from : http://tommcfarlin.com/wordpress-and-mvc/
Just to update this with more recent information for people hitting this from search engines - the wp-mvc plugin http://wordpress.org/extend/plugins/wp-mvc/ goes a long way to creating a mvc framework for plugin development. You can find out more here: http://wpmvc.org/documentation/70/tutorial/
Just to add to the list of options, (I'm admittedly biased as the author,) swpMVC is a fully featured, lightweight MVC framework, inspired by Rails, Sinatra, Express, and FuelPHP. It's thoroughly documented, and while I have used and enjoyed wp-mvc, I wanted something where the models were able to populate views themselves, including form controls for interacting with said models.
I put this together largely to reduce the amount of controller code required to put together an app on top of WordPress, and the result is a very fast and effective framework that runs inside WordPress. The models are based on PHP Activerecord and 8 models are included for existing WordPress data types, including Post, PostMeta, User, UserMeta, Term, and a few more. Modeling data is very easy thanks to the activerecord library, and I've enjoyed working with this framework immensely thus far.
Also ships with underscore PHP and PHP Quick Profiler (as seen in FuelPHP.)
RokkoMVC is a micro MVC framework built especially for WordPress. The project is meant to simplify AJAX functionality in WordPress applications, as well as bringing in all the other benefits of using models, views, and controllers to your theme.
I had a bash recently at creating a plugin that makes use of a simple view-controller system, and quite liked the results, so I separated the template stuff out to its own repo. It offers object-based controllers, passing variables locally to PHP templates, template fragments (templates within templates) and components (template fragments with their own sub-controller). All in two tiny classes!
Of course, I wrote this code thinking that no other WP developer had considered the problem before ;-).
It's far from mvc, there is no kinda-sorta thing like some people say, it's either MVC or not... The fact that you write logic on the view level doesn't qualify it as a mvc framework. The reason people use it - it's easy to learn, you don't need to be hardcore php programmer, they're lazy.