This might look like a dumb question but I am new to MVC particularly to extJs. I wish to work with the MVC approach. I followed this link http://www.extjsframework.com/mvc/simple-mvc-application. But it has only a single page as example. The example page uses app.js to load extjs views. Now here is my question. I have an application with multiple pages. Do i need to make separate app.js like scripts for each page of my app or could i use the same app.js accross all my pages. If i could, kindly mention how.
Thanks...
All of the answers here are correct, however the question seems to be a bit ambiguous so that's why they are all slightly different.
The typical RIA app is a single HTML(or php,jsp,asp) page with many different views all managed by the the JS framework, so changing pages is no longer required (and in most cases avoided for performance reasons).
Your server side code/scripts are then typically reduced to JSON data services that provide data to the RIA app running completely independently in the client browser.
As you can see you would not need to have test.php and index.php and would suffice to have one index.php with ExtJS application running out of that page.
If this answer is not useful because you already knew all of this and really meant to ask about multiple controllers and modularization of an ExtJS application then that's a separate discussion and has been addressed to an extent in other posts. (look for lazy loading controllers).
Hope this helps.
Every page. Every time a page unloads, it's like the JS slate gets cleared. The browser will actually cache the files but the code executes like it was the first time.
Usually it's same app.js for all different views.
The MVC concept of ExtJS 4 is about architecture. The documentation clarifies that pretty easily.
Every Ext JS 4 application starts with an instance of Application class. The Application contains global settings for your application (such as the app's name), as well as maintains references to all of the models, views and controllers used by the app. An Application also contains a launch function, which is run automatically when everything is loaded.B
As you can see in the docs, you will have one single app.js, that is gonna be like a bootstrap, responsible to instantiate the whole application.
You are gonna structure your files, however, following the MVC approach, or pattern, in order to have a nice and clean architecture.
Related
Problem
I know this is a bit of a conceptual question, but I am designing a
system and I am not sure if I want to use one script as a "Master
Controller", that talks to my PHP classes for the business logic, OR
if I wanted to create multiple smaller controllers that only focus on
certain tasks.
Example
For example, if I wanted to control ALL the functions of the
site(user management, times heets, reporting, and so forth), should I
combine all those "getter/setter" functions into one script, or should
I break it up into sections (one controller for user management, one
for time sheets and so forth). I am using AJAX to call these scripts
when needed.
My Request
My thinking is that I should use multiple smaller controllers, that
way when multiple users are accessing the site, they are not all
trying to execute that same script at the same time. I would expect
that if I used one big controller, that it could cause problems with
symptoms that would act like a DDOS. However, I am unsure if that
would actually happen and wanted to get some opinions/alternatives
suggestions.
BTW, this is not a MVC architecture per-say, more of a custom monster I am creating.
Any insight would be greatly appreciated.
For a complex system with multiple Ajax calls, you might want to look at the Flux and React systems developed by Facebook. These are open source and available on GitHub. Facebook developed Flux because they got into difficulties with a complex MVC system.
The Single Responibility Principle suggests to split you controller. It's a fundamental principle of good object oriented design.
i have a project i took over. it is an app that has been build over many years with PHP and mysql.
It currently has a sort of good folder structure but the code itself is very poor written.
There is php, sql statements and html code in almost every file.
There is javascript code generated using php echo for not reason and so on.
I will like to use for further development either CakePHP or CodeIgniter, even if that means that for the new features some code will be written that already exists (eg.: maybe utility functions) in the old code.
is it possible to integrate one of these frameworks into an existing app?
which one is easier?
do you have any links on how to do it?
thanks.
I have very little experience with CakePHP so my answer is going to be about CodeIgniter. I played with CakePHP for about a day and that was almost two years ago. In my opinion it will probably be easier to integrate with CodeIgniter although someone more experienced with CakePHP might prove me wrong.
Here is the approach I would take. I have never done this, but it seems like a logical way to approach the problem. I suppose this approach would also work with CakePHP.
First, start with a fresh CodeIgniter install using the latest version.
Next, create controllers and actions (controller methods) that mirror the current structure of the application. For example, if you had a page with the URL http://example.com/users/view you would create a Users controller with a view() method.
Next, create view files for each of the current files of the application and load them via the appropriate controller methods. The goal here is to get the application working using CodeIgniter's routing system although at this point you won't be utilizing any models, libraries, or helpers.
Once you have the application sitting on top of CodeIgniter, start refactoring it to fit into the MVC pattern. Pull out application logic (queries, form handling, etc...) from the view files and place them into the controllers. Keep all presentation logic and HTML in the views.
Next, refactor the controllers. This is where it gets tricky because controller code can be placed into models, libraries, or other controller methods. A good starting point would be to take all of the queries and put them into appropriate models. Compare your controllers and see if there is any code duplication. That is a good sign that you should remove it from the controller and place it elsewhere. Unfortunately I can't really tell you where because it differs in each situation.
Continue refactoring your application until you have it in a workable state that you are pleased with...
Hopefully this helps. I certainly missed some critical steps such as setting up and configuring CodeIgniter but if you're serious about doing this I would highly recommend reading through the CodeIgniter User Guide to get a good idea about how it works. You should also get familiar with MVC (model-view-controller) if you aren't already.
There's not really a one size fits all solution here but hopefully I've given you some ideas or at least a starting point to jump off of. If you have any questions or are a little confused drop a comment below and I'll get back to you.
In my opinion, it's easier just to write your controllers in CodeIgniter (I've never used CakePHP) and models, than you just copy paste with some adjustments the views.
I see many MVC implementations for websites have a single-entry point such as an index.php file and then parses the URL to determine which controller to run. This seems rather odd to me because it involves having to rewrite the URL using Apache rewrites and with enough pages that single file will become bloated.
Why not instead just to have the individual pages be the controllers? What I mean is if you have a page on your site that lists all the registered members then the members.php page users navigate to will be the controller for the members. This php file will query the members model for the list of members from the database and pass it in to the members view.
I might be missing something because I have only recently discovered MVC but this one issue has been bugging me. Wouldn't this kind of design be preferable because instead of having one bloated entry-file that all pages unintuitively call the models and views for a specific page are contained, encapsulated, and called from its respective page?
From my experience, having a single-entry point has a couple of notorious advantages:
It eases centralized tasks such as resource loading (connecting to the db or to a memcache server, logging execution times, session handling, etc). If you want to add or remove a centralized task, you just have to change a singe file, which is the index.php.
Parsing the URL in PHP makes the "virtual URL" decoupled from the physical file layout on your webserver. That means that you can easily change your URL system (for example, for SEO purposes, or for site internationalization) without having to actually change the location of your scripts in the server.
However, sometimes having a singe-entry point can be a waste of server resouces. That applies obviously to static content, but also when you have a set of requests that have a very specific purpose and just need a very little set of your resorces (maybe they don't need DB access for instance). Then you should consider having more than one entry point. I have done that for the site I am working on. It has an entry point for all the "standard" dynamic contents and another one for the calls to the public API, which need much less resources and have a completely different URL system.
And a final note: if the site is well-implemented, your index.php doesn't have to become necessarily bloated :)
it is all about being DRY, if you have many php files handling requests you will have duplicated code. That just makes for a maintenance nightmare.
Have a look at the 'main' index page for CakePHP, https://github.com/cakephp/cakephp/blob/master/app/webroot/index.php
no matter how big the app gets, i have never needed to modify that. so how can it get bloated?
When deeplinking directly into the controllers when using an MVC framework it eliminates the possibility of implementing controller plugins or filters, depending on the framework you are using. Having a single point of entry standardizes the bootstrapping of the application and modules and executing previously mentioned plugins before a controller is accessed.
Also Zend Framework uses its own URL rewriting in the form of Routing. In the applications that use Zend Framework I work on have an .htaccess file of maybe 6 lines of rewriterules and conditions.
A single entry point certainly has its advantages, but you can get pretty much the same benefit from a central required file at the top of every single page that handles database connections, sessions, etc. It's not bloated, it conforms to DRY principles (except for that one require line), it seperates logic and presentation and if you change file locations, a simple search and replace will fix it.
I've used both and I can't say one is drastically better or worse for my purposes.
Software engineers are influencing the single point of entry paradigm. "Why not instead just to have the individual pages be the controllers?"
Individual pages are already Controllers, in a sense.
In PHP, there is going to be some boilerplate code that loads for every HTTP request: autoloader require statement (PSR-4), error handler code, sessions, and if you are wise, wrapping the core of your code in a try/catch with Throwable as the top exception to catch. By centralizing code, you only need to make changes in one place!
True, the centralized PHP will use at least one require statement (to load the autoloader code), but even if you have many require statements they will all be in one file, the index.php (not spread out over a galaxy of files on under the document root).
If you are writing code with security in mind, again, you may have certain encoding checks/sanitizing/validating that happens with every request. Using values in $_SERVER or filter_input_array()? Then you might as well centralize that.
The bottom line is this. The more you do on every page, the more you have a good reason to centralize that code.
Note, that this way of thinking leads one down the path of looking at your website as a web application. From the web application perspective, a single point of entry is justifiable because a problem solved once should only need to be modified in one place.
I'm developing a web application and I'm using PHP and Javascript. Today, I'm starting to draw all the design class diagrams, but I don't know exactly how to mix both technologies.
I think that something like the following should be good:
But, really, I'm not sure if typing the .php extension in the class name is sufficiently clear, or what I need is to separate diagrams in two: one for Javascript classes and another one for PHP classes.
I'm using CodeIgniter (MVC pattern) and Javascript. Any suggestion will be really appreciated.
Thanks!
Usually, you don't want to do this. It's a problem of latency when viewing the web page in a browser. Each separate javascript file defeats caching and requires additional transfer time before a page can load. It's commonly advised to combine JS files wherever possible and practical to better take advantage of browser caching. So my first suggestion is to not arbitrarily split up your JS for architectural reasons...
Now, with that said, to answer you question in entirety, I think it depends on how you view JS. If you're looking at it form the perspective that it enhances your PHP application, then dividing it up along side your views is not bad (the above suggestion not withstanding).
However, I usually see JS as a separate application layer on top of the PHP application. The JS interacts with the PHP layer through defined APIs. So it's basically just a full blown GUI application that just so happens to use the API defined by the PHP application. So with that in mind, I usually build the JS application with its own architecture that's more dependent on itself then the PHP application. So in other words, just because a piece of the JS application interacts with PHP doesn't mean that the piece of code belongs with the PHP application.
Does that make sense?
Trying to put all your classes (even within one application - you have two: a PHP applicatoin and a JS application) on one UML diagram is pretty much a way to waste a lot of time and gain nothing.
Use UML to show dependecies within a package or a group of classes working together, but don't try to do it for a whole app.
I don't know the way you do things usually but in my projects, I tend to separate PHP and JS. First of all, its easier to develop and debug if you go that way, secondly, if you treat javascript as a second layer instead of being on the same level of programming as PHP you will get a working fallback in the case that your JS doesn't work, or the user of your web app have javascript disabled.
I tend to make everything work in PHP and later on I override some actions with javascript to get them working through ajax instead of the traditionnal way of working in old school Web.
--- Revision following first comment ---
Then, you might want to treat the PHP and the Javascript part as separates applications. The first system (PHP) generate the initial state. Upon user action the second system (JS) makes a query to the first one and wait for the answer, this way, you will setup some sort of API that will standardise your transactions.
I used to work with design information specialists and they often refer to Jesse James Garrett as a "Guru" in that field of expertise, you might want to check his site (there are premade stencils for omnigraffle, visio and few others).
Through his writing and example you might be able to find the right symbols and elements to represent your system.
Jesse James Garrett's website
I'm building an IMDB.com like website using PHP/jQuery and a MVC approach (no OOP).
I have an index.php base controller to 'rule them all' :), a controllers folder with all the controllers, a models folder and a view folder.
In some pages of the website I have tabbed navigation, when the visitor clicks on one of those tabs to get more information, jQuery gets that data using the $.post or $.get method and shows it on the tab container, obviously without refreshing the page.
The problem is that those pages loaded by ajax are also generated using controllers, models, and views, and the things are getting a bit complicated for someone like me ( = 'no experience'). To dynamically get the data I some times need to include a model twice, include an include in an include in an include, send information multiple times, connect with the database again, and all sort of things like that and I'm sure there is a better and prettier way to do this.
I'm searching for the best approach and common methods for this. I have no experience working with a big project like this. This is a personal project so I have full control and every answer is welcome.
Thanks!!!
You can check the X-Requested-With header that most js frameworks send to see if the request is coming via ajax. Then you can only output certain data and not the "entire page".
Not sure why you need multiple includes like you say, maybe you need to rework your logic.
Post some code and we can be of better help.
"To dynamically get the data I some times need to include a model twice, include an include in an include in an include, send information multiple times, connect with the database again, and all sort of things like that and I'm sure there is a better and prettier way to do this."
I think you need a better 'design' for you MVC application. Multiple includes - i am guessing in the different layers of the MVC framework might be indicators that your design needs more attention.
I'll try and be short:
Other frameworks i.e. handle requests via XMLHTTPRequest by AMONG others, disabling or enabling the VIEW or LAYOUT explicitly - check Zend Framework - (e.g. you need to send a JSON encoded string as a response). These requests are handled just as any other request.
I would suggest you have a look at other popular frameworks. Check the application design and layout, and pay attention on the Routing and Dispatching of Actions. I suggest you follow this path since as you say you lack experience.
good luck with your project.