In a site where I have 2 similar forms in different pages, since some of the fields are the same, it seems logical I should have one class that validates the fields from both forms.
My question is, where should such a class reside? In /assets? In /includes?
This question goes for any other files (such as 3rd party scripts) as well.
What is the best organization practice for files that do not fall in the /controller and /model directories?
"Assets" generally refers to static assets like images and CSS files, so that's out. If you're not using an MVC framework or if the framework you're using that doesn't have a convention for this (try googling around) I'd recommend creating a directory like /lib, /lib/validators, or perhaps /common. In the end it's most important to pick something that makes sense to you (and other developers who might be working on the project). You can always move files around later if you realize a different structure might be better.
This is very complex topic to talk about, so take a look at symfony framework directory structure:
http://andreiabohner.files.wordpress.com/2007/03/cheatsheetsymfony001_enus.pdf
and try to mimic it in some way. It stores forms in /lib/form/ - you can use for example /form, if your directory structure isn't that complex. Assets are static elements like images or CSS files, as Jordan said. Includes are usually used to store config or so, it's not used in modern development at all.
I'm have a home-grown MVC where a lot of pages share common tasks and libraries, so 99% of my model's work is to call things like Form::validateForm() and return the results to the Controller rather than the model doing all the work.
This means that /foo/form can use the same Form class as /bar/form without needing to replicate any behavior.
It may not be "best practices" to have Classes handle the heavy lifting rather than models, but I do find it allows all those common tasks to be abstracted from the directory structure.
Related
I am thinking to create my own simple MVC framework in PHP. I thought it would be good idea to improve my skill in PHP.
I have a questions about admin section, how do you create it?
In kohana, controllers can be in sub-folders:
for example: /controller/admin/admin.php
What is other way? As long code can be shared to parent helpers/libs or parent models.
First thing you have to notice is that Kohana is a HMVC framework. It is a bit different beast, compared to the rest of bunch. In this case admin is not so much a module as it is a namespace (though kohana is still using the PEAR-like "namespacing") for controllers and other classes.
This way additionally lets separate out other parts of application .. lets say you have a lot of code dealing with tagging and tag clouds. Then you can create another namespace/module just for that. And use them as sub-controllers. That's one of HMVC perks.
One other way of separating admin section from general application would be to treat them as separate applications, but then you need another location for shared components (most likely from model layer). Then you have more then one /appliation/ folder on your server.
Or you can do combination of two.
I am assuming here that the reason you want to create yet another MVC framework is indeed to improve your PHP skills, and not to try to create a framework to use in a daily basis at your company, for example. I know that you didn't ask for such advice, but there are so many great MVC frameworks out there (and you probably know many of them already). I think it is a great approach to learn design patterns and increment your skills in PHP (or any other language), though.
As of your question, the most common approaches I have seen is to use different directories, like the "admin" subdirectory you mentioned, for then enforce name suffixes or prefixes for the controllers, like "UsersAdminController.php" e.g, adding "AdminController" at the end.
One thing that using a subdirectory may be better is that it enforces a better separation of concerns, and reduces the possibility of you ending with a lot of classes with simmilar in the same directory, which may cause confusion at some point.
I think creating your own framework is a great idea, if only as an exercise to better understand the structure behind a web app.
I'm doing it so myself, and I think your approach depends very much on how far you want to go.
I started with a multilanguage support subsystem and user database management classes and now I'm moving to content management and database query sanitization.
I keep my classes separated in files and grouped by subsystems in folders, like multilang or admin, I think it's the best approach.
i am writing a web site with a php on the server side. which i have never used before.
if i get it right it is procedural programming (which is another thing that i have never done)
my question is how to write code:
each procedure should be in a different file?
to separate it to various files?
maybe have one file that receive the request and then dispatches it?
in ojbect oriented things are a lot more clear...
please advise
You can do object oriented programming in PHP, and I prefer to structure it that way.
If you choose to stick with procedural style, 1 file per procedure is not the way to go, imagine if in OOP you did 1 file per method!
Grouping things is better, maybe you have a DB abstraction layer, in OOP you might make it a class, in 1 file. In procedural implementation, you'd have a bunch of procedures in 1 file. Probably named similarly.
There is no strict definition of where things need to be placed in PHP. It's entierly up to you. I suggest you check out the MVC pattern if you are looking to write complex systems.
Feel free to use an object oriented model in PHP, its my style of choice now.
Group related procedures together. One file per procedure is overkill.
There's good advice on this sort of thing in Code Complete. It is a very reputable programming book with good guidelines on how to organize your code.
Personally,i've never jumped in the OO wagon. Old habits die hard. But i experimented with cakePHP which introduced me to the MVC pattern (Model View Controller). Since then i usually follow this structure:
.htaccess << redirects all request URIs to index.php
index.php << the main processing file
_lib/ for configuration files
_lib/classes for all 3rd party classes (such as database abstraction, etc)
_views/
_controllers/
PHP can be object oriented.
But if you are not using it that way, then you just need logical divisions for your functions.
If you have just a few functions, use one include file with all the functions in it.
If your site has several areas, such as 'Membership', 'Library', and 'Resources' and each area uses a number of functions (like 5+), consider creating files for each area, such as: membershipFunctions.php, libraryFunctions.php, and resourcesFunctions.php.
We tend to adopt a structure where we define our objects specific to the site in 1 file. Another file contains all the generic functions (our general library). There's another file defining all the constants and basic structures.
Implementation of the objects and the core site code (database, authentication, etc) is in a common file. This file includes the objects, constants and library files and performs the foundation operations of the site.
Finally, the site's functional groups are placed in their own files for page generation. These files include the common module (file).
Objects are coded to manage themselves so there is little work going on in the functional page files.
We used to split out all the objects into their own files but found it easier to assemble them into 1 general object class definitions file.
I prefer the OO style for PHP 5, and specifically, enjoy the structure that Zend Framework promotes, using PEAR style directory trees, and allowing you to segment your code in a fashion that makes sense, from a OO point of view, and an architecture point of view.
I would delve into the realm of OOAD, but I am pretty sure there are alot of sources on it, one of the best being the Code complete book mentioned earlier in this questions responses.
Look at http://framework.zend.com for a layout of a zend project, particularly the quickstart, I think you might find that it presents you with a good structure to use, even if you dont want to use the Zend Framework itself.
I've asked this question on the zfforums as well, but I maybe I'll get a response here.
So the Zend Framework is a general purpose, flexible, loosly coupled, high quality framework. However, I find some of the MVC parts inconsistent and overly complex. Hopefully some of you can justify some of the zf design decisions and answer some questions:
General Questions/Comments
Why doesn't zend mvc follow the same naming conventions as other zend components? For example, mvc uses lower case, plural directory names and class names aren't prefixed with directory info so they can't be easily autoloaded.
I'd like the option to add a module root directory. That way, I wouldn't have to explicitly configure the dispatcher by adding controller/module directories. I'd be able to drop in a module and have it accessible immediately.
Why is there a distinction between view and action helpers? Currently, the helpers aren't designed to be shared throughout the code and there are inconsistent methods of loading and accessing the helpers. Other frameworks allow you to share the same helpers anywhere in your code. I don't see the need to specialize and violate DRY.
Zend View Questions
Why do views use "$this" to access resources? I don't see the need for the extra typing. Some other frameworks extract() an array of view variables and allow loading global functions or autoloading static helpers from within the view: myHelper::someMethod();
Why do view helpers only allow one function per class? That results in a lot of classes and associated maintenance. I'd prefer static classes with any number of methods as already mentioned.
I´m using the Zend Framework in a huge intranet site, since it´s early stages, 0.3 or 0.4 I think, and I followed the most of decisions regarding your questions. I´ll try to explain them a bit:
In most cases you don´t need to use modules. You can drop all your controllers in your application/default directory, name them IndexController or HelpController and you´re done, just access http://www.domain.com/ or http://www.domain.com/help.
If your project starts go grow you can add modules as you wish, prefixing them with the name of the module (directory name) Admin_IndexController or Forum_PostController, acessing them by http://www.domain.com/admin (you´re in admin module, index controller; not in default module/admin controller).
You can set your modules directory at applicatoin/modules, for example, and configure the FrontController to look at this directory for modules. Using addModuleDictory Whenever you create a new directory and put your view/controllers there, they´re auto-discovered by the dispatcher. Here is an example.
As I see they serve clearly distinct purposes. ViewHelpers are used to generate markup and render other actions directly in the view, abstracting menu creation, sidebar, etc. OTOH ActionHelpers interact with the dispatch process, allowing you to redirect to another action, as an example.
Views
In the beggining I too felt it a little awkward, but I got used to. I think the main reason is not to pollute the namespace, but I can be wrong with this. By the way I´m not very fond of the use of extract(), but it´s just my personal preference.
For the main reason that it´s not allowed to have more than one controller per file: autoloading. When you use $this->someViewHelper() the underlying engine looks for a class named *_SomeViewHelper_Helper in your plugin paths. Another reason is that static classes are very hard to unit test against. There´s even a proposal to rewrite the FrontController as an instance class, not a Singleton.
You´re right about the overly complex part that you say in your second paragraph and the developers and community knows about it. It just has to be this way to accomodate all requiriments and variations.
In the end I think that ZF is a very robust framework, giving us the freedom to do what we want.
I hope I could help you clearing your questions.
I don't know all the answers to these but they're interesting questions so I'll have a stab and hopefully someone can fill in the blanks.
General
Classes not in the default module are prefixed with the module name, e.g. Admin_IndexController and would reside in /admin/controllers. I think the reason for the separation, and inconsistent naming (vs. library classes) is that there would be little benefit having them in a nested folder structure. Controllers are part of your implementation so I think it makes sense, personally. Traversing the folders does get a little tiresome, however.
You could modify the dispatcher, or write a plugin to scan for directories and add them.
There is definitely overlap here - the URL helpers are a good example of this. Generally a view helper generates markup so I think there's a big enough distinction.
View
I don't know the exact reason but I'd guess it allows other helpers and view functionality to work together more easily. For example, if you've used the doctype helper to set the doctype, the form element helpers can generate XHTML or HTML as appropriate.
It definitely results in a lot of classes, but I'm not sure about maintenance. I've not run in to any problems. I can see the use in static classes, but remember that Zend_View won't stop you using them. If you have your static classes in your include path (and use Zend_Loader or similar), you can use them instead of or in addition to View Helpers.
Let's say I have a database table "widgets"
Should there be an index.php with a big switch statement for different actions, like "list_widgets", "edit_widget", "new_widget", "delete_widget"... and then each of those actions in a separate file?
Or, should there be list_widgets.php, edit_widget.php, delete_widget.php....
Or some other way?
EDIT (after reading the first answer). I'm really asking, what are the names of the files on my harddrive. If I were to create a website that just edited a single table of Widgets, what would be the names of the files on my harddrive for that project?
(My motive for avoiding frameworks right now is that this project is a learning excercise for php and mysql, so I don't want anything happening automagically yet)
If this is a learning exercise with PHP, then what exactly are your goals? Do you want to implement a full MVC architecture (just for the sake of the exercise)? Do you want to use a Front Controller that routes requests to specific controllers? Or do you want to build a simple one script site that is capable of only of editing your table of widgets?
If it is any of the former then I would recommend that you read the documentation and source code for one of the frameworks (I particularly like Zend Framework) and then implement your own version of MVC and/or Front Controller. Additionally, you can read this article by Rasmus Lerdorf where Rasmus talks about how to build a simple MVC application without using an existing framework.
If you simply want to accomplish the latter (edit your table of widgets), I would recommend that you keep things simple. So I would:
Create a file (WidgetsTable.php) with functions that interact directly with the table. For example insert(), update(), delete(), fetchAll(), createNew()
Create a file (index.php or widgets.php) that you will interact with directly (in some paradigms this would be the Page Controller). This file will contain functions like createAction(), listAction(), findAction(), showFormAction(). This will be the page to which calls are made and the functions in this page will interact with the functions (or class methods) that you created in the first file.
Create a folder called views or templates and create a corresponding view or template file for each action in widgets.php. For example you would create list.php, showForm.php, create.php.
This will ensure that you have the proper separation of concerns and it will make it easier to adjust the overall project structure later if you find you need to.
Good luck with your learning project! :-)
I'd create a Widget class and give it edit(), new(), and delete() methods. Then you could have a list() function somewhere that builds an array of Widget instances. I'd probably go ahead and create a WidgetList class (WidgetList.php), even if it's just a wrapper around an array initially.
Initially, I'd just have a Widget.php file for the class and an index.php to handle the various requests.
I always make sure the files containing my classes have the same name as the classes themselves (usually one per file). That makes it easier to figure out where things are and makes it easier to use the __autoload function.
Then I'd have a .htaccess file to create friendly urls that send the different types of requests to index.php. Something roughly like this:
Options ExecCGI FollowSymLinks Includes MultiViews
RewriteEngine On
RewriteRule /new index.php?action=new
RewriteRule /edit/([0-9]+) index.php?action=edit&widget_id=$1
How you do the urls depends on a little on how your widgets are actually going to work.
It would probably be easier to view the file structure if it was /widget/edit.php or /widget/new.php
This way you can redirect people to other modules by just knowing the module name and what action they want to do.
Also that will allow you to implement url rewriting a little easier so it would look like widget/edit/2 once you get an index.php and some rewrite rules in place.
I'm sure that this is probably a matter of taste, but I find that creating 3 files (list, add, edit) for 1 table is flexible enough while keeping it easy to understand, especially for developers new at php.
that way, whenever you need to do CRUD on another table, just create another 3 files for it.
...
includes/
views/
add_member.php
edit_member.php
list_member.php
add_widget.php
edit_widget.php
list_widget.php
...
with includes/ folder storing the config and function files and the views/ folder containing various fragment files to be included, such as header, navigation, footer, etc.
Have you ever looked at http://www.phpobjectgenerator.com/
It generates really nicely CRUD formatted objects for database tables.
I've got a somewhat primitive framework I've been using for most of my projects, but a general design issue came to mind that I haven't been able to work out yet. For a given application, should I separate the application-specific class structure from the framework's structure, or is building on top of the framework not such a bad thing?
For example, say I had a framework with a base Controller class and extended it for a given part of my application. Which arrangement makes the most sense, and why?
Class Structure A:
Intuitive, easy to find source files when debugging.
File naming/directory structure mirrors class heirarchy.
- Framework_Control "Framework\Control.php"
- Framework_Control_Index "Framework\Control\Index.php"
- Framework_Control_Home "Framework\Control\Home.php"
- Framework_Control_Contact "Framework\Control\Contact.php"
- Framework_Control_About "Framework\Control\About.php"
Class Structure B:
Keeps framework modular and easily to replace/update.
Adds some complexity to directory structure, directory/file naming no longer follows class heirarchy all the time.
- Framework_Control "Framework\Control.php"
- Application_Control_Index "Application\Control\Index.php"
- Application_Control_Home "Application\Control\Home.php"
- Application_Control_Contact "Application\Control\Contact.php"
- Application_Control_About "Application\Control\About.php"
I know overall it's going to come down to personal preference, but I want to make sure I weigh out all the pros and cons before I decide which way to go. It really comes down to class naming and directory structure as the actual hierarchy would remain the same in either case.
I would suggest that you view your source code in two different categories, external dependencies or code that is used across multiple sites and not native to any single one and native dependencies or the code that is native to the particular site that you're working on.
It sounds like Framework/Control.php is part of a larger external dependency and should be managed as such, while the Application/Control files are all native the particular website.
Using this differentiation in our code structure has made it much easier to reuse our in-house framework between multiple sites very easily.
As a final thought, you might consider looking at what the major frameworks out there are doing such as Zend Framework, Symfony and others. Even though the entire framework might be more than you want the structure of the frameworks can provide a lot of insights into common, good practices that are being used by PHP developers everywhere.
What it really comes down to is what are you going to do when you update Framework\Control.php in Application XYZ. Are you going to go back to Application ABC and make that same change? What if it's a critical bug?
For maintainability of all of your projects I'd go with your second option.