question about MVC

[Ninjakreborn]

I have one question about MVC

When you have an MVC system (framework, or something similar)
At some point you are going to have 3 folders
View Model Controller
Is view the place all your view file's go, if so you need to point the domain name directly into that folder, right.  Is this the idea.
Because If I did the view/model/controller, then I would have to point the domain name itself into the view folder.

So a lot of hosts you don't have access to where the domain points except for the root directory (public_html I mean)
So how would you deal with this
Or do you have an index.php page in the root, and have it automatically redirect any incoming traffic straight into the views folder.
Even then the first instant redirect would be bad for search engines?

[Jenk]

No.

Controller - Controls the activity of the application, by deciding what actions (models) to invoke.

Model - The "nitty gritty" of the application. Data sourcing, calculations, etc.

View - The output layout.

[Ninjakreborn]

Ok, so I need to have some way to point the domain into the views.

A view can't be viewed unless someone is in that folder looking at it, that is my confusion.
In codeignitor when looking through it, the domain name points to the root directory as normal, and you just specific it's location in the config file, I am trying to find out how code ignitor takes account for that when doing the views/models/controllers.

[redbullmarky]

i'm not 100% sure where you're coming from here, but taking a stab, you maybe missing how it works a bit.
In CodeIgniter and Cake, only certain files are/can be directly accessed. Everything else is tucked away and included as required by the framework itself. The files that can be directly accessed are generally:

1, the main index.php, which handles the request, "boots" the framework according to the request and spits out the result. M's, V's and C's aren't directly accessed at any point via the URL - many of the URL's you see though have some form of mod_rewriting going on.
2, CSS files
3, Javascript files
4, Images

so your Model/View/Controllers directories (at least when referring to Cake or CI, anyway) can be safely tucked away elsewhere, preferably out of the web root altogether.

[Ninjakreborn]

Ok, that makes sense now.

THanks for the explanation.

[Nameless12]

You are all getting confused with mvc I think. The kind of talk I am seeing looks like that about frameworks but MVC is not a framework pattern it is more of a 3 step process that frameworks have made their own implementation. The stuff you are all saying about directory structure and mod_rewrite may be good and may be a good approach to solving many problems but that is not mvc that is mvc with a dozen other design patterns thrown in. You need to take it one step at a time I think and trying to copy frameworks the way it sounds like is not the solution because you just wont be able to put all the patterns into context straight away.

I know you are new to oop, very new. But you should learn it and learn how to make a template engine or something just because it compeletly separates the controller from the view if you use a templating engine.

Consider the followng

$r = $db->query('select * from data');
$t = new template();
$t->assign('my_database_data', $r->fetchAll(PDO::FETCH_OBJ));
$t->display('template.tpl');

in the above code you can think of the database object as a model and the script controlling it is a controller because it is controlling it. The template engine is sending the data to a template and the template will be separate from the controller, hence the "view".

Just learn one pattern at a time the frameworks you are all talking about and trying to copy are using many patterns, mvc is just one of many.

[Ninjakreborn]

All good advice, except one opinion I have.  I hate templating engines, the main reason I like code ignitor over cake php, it doesn't force a templating engine on you.

I am starting to learn OOP, and thinking of using MVC, but using a templating engine hasn't even attracted my attention, I hate templating engines, adn the philosophy behind them.  (Personal Opinion However), I just don't see me ever using one.

[redbullmarky]

CI and Cake both handle templating in the same way...Neither by default use what you would call an 'engine' (in the sense of using stuff like {VAR} and {NAME} etc - both use PHP natively as their template syntax.

Nameless12, that's some good advice dude. I probably do get carried away a little when trying to get a particular point across. On the other hand though, Frameworks and MVC make a fantastic couple, and a framework can easily be designed AROUND the MVC pattern. As far as I'm concerned, MVC is more than just a pattern - it's an entire structure. Patterns to me are the more trivial things that complete specific tasks that would in turn become PART of an MVC setup.

mod_rewrite just kinda helps things along in terms of getting everything going through a single point of entry to keep things all nice and compact. So i'm not actually stating that all of this is essential/a requirement of MVC, but it sure helps alot in the grand scheme of things, IMO of course.

cheers

[Nameless12]

Templating engines come in all different types of flavors. I have a feeling you are referring to template engines such as Smarty?? I hate them to.

Mine gives me a few advantages they are mostly to do with scope and the ability to type $this->debug() on any page to see what data I have access to. Also the files are loaded through a central point allowing me to prefix the template_directory.

Also it allows me to easily add

ob_start()
require $template_dir . $template_file;
return ob_get_clean()

The above code is far from how my source code looks but the point is it handles buffering for me easily. The idea of the template engine can have many different implementations all I use it for is the actual file loading, debugging and manipulating scope in order to keep things tidy.

I hate templating engines that have their own language such as smarty as it is not needed.

It is also personal preference to some degree, a simple include $dir . 'template.tpl' will work just fine but I think the idea of having an object to handle the loading and debugging is good for code reuse and is more robust when working on larger applications.

And just to clear something up no framework will ever force you to use a template engine as there is no way to remove the include\require so there is no way to force it on you. The only time I think It can sort of be pushed on you is when developing in languages such as python that dont allow you to do things like  -->  <b><?=$text?></b>  <--- without a template engine.

[Nameless12]

[quote author=redbullmarky link=topic=123685.msg511918#msg511918 date=1169597346]
CI and Cake both handle templating in the same way...Neither by default use what you would call an 'engine' (in the sense of using stuff like {VAR} and {NAME} etc - both use PHP natively as their template syntax.

Nameless12, that's some good advice dude. I probably do get carried away a little when trying to get a particular point across. On the other hand though, Frameworks and MVC make a fantastic couple, and a framework can easily be designed AROUND the MVC pattern. As far as I'm concerned, MVC is more than just a pattern - it's an entire structure. Patterns to me are the more trivial things that complete specific tasks that would in turn become PART of an MVC setup.

mod_rewrite just kinda helps things along in terms of getting everything going through a single point of entry to keep things all nice and compact. So i'm not actually stating that all of this is essential/a requirement of MVC, but it sure helps alot in the grand scheme of things, IMO of course.

cheers

[/quote]

I disagree.

It is hard for me to sum up why I disagree in a short way I guess the closest I can come is I feel mvc is an important cog in the machinery that is application development but it is not the machine, it is just one of many cogs that help the machine keep functoning.

seriously ask your self what have you used more? mvc or the factory pattern? I use this as an example as most of my code in my current project has very few views as most of it is libraries\framework. Until a webpage uses more views than its libraries\models and such than mvc will never be more than just a pattern.

I do agree it is an important design pattern but most design patterns are important, I Just feel that it is just a design pattern like any other and that people here that are confused about what it actually is should learn what each of the patterns is and learn them one at a time instead of saying all the most useful patterns are called "mvc" doing that will just create confusion and make it hard for them to put stuff into context.

I do understand where you are coming from but to me its just a design pattern.

[Ninjakreborn]

Hmm, very interesting points.

I have yet to see a templating engine I like, I thought about building my own, but I can't think of anything but the same type of syntax I see for smarty.  I used it once, said I hated templating engines, never second thought one again.  Is yours personal or can I see it in action, like see the file's for it, or something as an example, so I might be able to create my own.  I don't like seing file's named .tpl, and .tpl.php that part annoyed me, and the stuff I see in some of hte applications.  They have a .tpl file with all this thrown in code, that (to me), look stupid, bulky, and hard to read.  Me being a PHP programmer, looked at the php code they called a templating engine and had to spend 30 minutes before I understood any of it.  So far I hate them, do you  mind sharing what you have with me.

[448191]

[quote author=Nameless12 link=topic=123685.msg511935#msg511935 date=1169599095]
As far as I'm concerned, MVC is more than just a pattern - it's an entire structure. Patterns to me are the more trivial things that complete specific tasks that would in turn become PART of an MVC setup.
[/quote]

MVC is a 'Architectural' pattern. It doesn't directly deal with entities like classes and objects, yet it is still a design pattern: the description of a problem and a solution (or more of them), in the context of a system.

True that 'patterns spawn patterns', and patterns encompass other patterns however.

Another example of a architectural pattern is the 'Three-tier' model.

[Nameless12]

[quote author=businessman332211 link=topic=123685.msg512014#msg512014 date=1169613311]
Hmm, very interesting points.

I have yet to see a templating engine I like, I thought about building my own, but I can't think of anything but the same type of syntax I see for smarty.  I used it once, said I hated templating engines, never second thought one again.  Is yours personal or can I see it in action, like see the file's for it, or something as an example, so I might be able to create my own.  I don't like seing file's named .tpl, and .tpl.php that part annoyed me, and the stuff I see in some of hte applications.  They have a .tpl file with all this thrown in code, that (to me), look stupid, bulky, and hard to read.  Me being a PHP programmer, looked at the php code they called a templating engine and had to spend 30 minutes before I understood any of it.  So far I hate them, do you  mind sharing what you have with me.
[/quote]

Make your own. It does no need a template sytnax. What you dont realize is you can do

<?if():?>

<?elseif():?>

<?else:?>

<?endif;?>

along with

<?foreach($data as $key => $value):?>
<b><?=$value?></b>
<?endforeach;?>

because php can be used in this way there is no need for special syntax if you read my last post again that will sum up what i think a template engine should be used for the only time special syntax should be used is in languages that dont come with built in tags like php has

Try making your own but to make one worth using you are going to have to use oop here is a simple example

[code]
class Template
{
  private $_dir;
  private $_data = array();

  public function __construct($dir = null)
  {
      if ($dir)
          $this->_dir = $dir;
      else
          $this->_dir = 'some/dir';
  }

  public function assign($name, $value)
  {
      return $this->_data[$name] = $value;
  }

  public function display($template)
  {
      require $this->_dir . '/' . $template;
  }

  public function debug()
  {
        echo '<pre>';
          print_r($this->_data);
        echo '</pre>';
    } 

    public function __get($name)
    {
        if (isset($this->_data[$name])
            return $this->_data[$name];
    }
}
[/code]

the above is a very rushed and untested example, my own version is probably 200 lines. There is also one other advantage to making your own. It is easy to make Template_Abstract then extend it Template extends Template_Abstract this gives you a nice clean slate to add functionality.


EDIT::
about what you said about hating naming them *.tpl that is just a nameing convention. You do not need to call them tpl files you can call them *.mytemplatefile if your server is configured to allow *.mytemplatefiles to execute php code

[Ninjakreborn]

So basically template file's, are file's in a folder that model an entire site.

For instance you have index.tpl.php that is the template for the homepage.

You can reuse that one template (and have it just output different content, different meta tags), and everything else.  So that one template can server for ALL the pages, is that what a template is for?

[Daniel0]

Nameless12: There is a problem with doing templates like you do. Not all servers has short tags enabled, which will break the code if moved to a such server.

[steelmanronald06]

I was just about to post that about shorttags. He would have to do something like:

<?php if(): ?>
<?php elseif(): ?>
<?php endif() ?>

And so on from there.

[Daniel0]

Also [tt]<?=$some_var?>[/tt] won't work on some servers. You would need [tt]<?php echo $some_var; ?>[/tt] (I think the semi-colon is optional in this case, but I just prefer to have it like that).

[redbullmarky]

though i think it's something worth knowing, whether you enforce it is a different matter...

personally i love the short tags (though just for templates, not my actual scripts). i've been with a tonne of hosts. most have had it turned on. the rest have allowed an easy addition of a htaccess file to allow it. those that dont allow this kind of flexibility aren't really worth the trouble, to be honest, as there will always be something you'll need to change at some point - be it short tags, mod_rewrite rules to sort out URLS, cookie's for sessions, register_globals, etc.

PHP6 is keeping it, so that's thumbs up enough for me - especially considering the benefits.

[Nameless12]

I am aware of <?= ?> and <?php echo ?> provides an alternative.. it is really trivial and is just a matter of developing for the server you are stuck with. It is something where I do not think it is worth worrying about as I prefer to host my own servers and most hosting companies have short tags turned on. by <?=?> I didnt mean the short tags the way It may have come off, I just meant that you can do stuff like

<?php if ()?>
<?php endif;?>
<?php echo 'a'?>

But that said I will always continue to develop for a short tag environment but keep in mind 100% of my libraries use <?php tags, I am aware it is best practice but as long as short tags are there I will use them and I do not see this as a problem

In answer to business man its not template.tpl.php, it is template.tpl with no php. The idea is not to have one template for your entire site but to make the site composed of multiple templates. for example I have a logged_in.tpl and logged_out.tpl for my login script. The main advantage is debugging and tidy code, you can do the same thing with an include but it will be lacking debugging and will be messy

[steelmanronald06]

However, you should get into habit of using normal tags and try to break away from short tags. Especially since I hear that they are getting rid of it in PHP 6 (could be wrong on this one)

[Nameless12]

I do use normal tags for all my code except views at the moment I have been building a framework that has very few views and the views are not final. They are just there as a make shift environment for testing. When it comes to making applications with this framework I consider the choice to use short or normal tags as a design choice for that project, the way i am doing templating I like

choosing servers is as much a design choice as anything else, I made the design choice long ago I would code for php5, not php4. my code will break on 95% of servers for this reason, but it was a design choice. The sort of thing applies here.

I find this subject of short tag vs normal tag to be somewhat stupid because most hosts dont support php5. I heard something like 5% of the php servers have php5.. going by this someone might choose not to program for php5.. but choosing your server is as much a design design decision as any other

[Nameless12]

http://www.corephp.co.uk/archives/19-Prepare-for-PHP-6.html

[quote]
Farewell <%
They will remove support for the ASP style tags, but the PHP short-code tag will remain (<?) - so to those on php general who reckon the short-tag is 'depreceated' - hah!
[/quote]

[Ninjakreborn]

Yes, I know they can be .tpl

If I ever create a template I will use .tpl.php
I always do that, like
file.class.php
file.inc.php
file.function.php (sometimes)
file.ext.php
I do this to help me stay more organized, I have always prefered that method, as you have to have php specifically setup to parse .tpl files through the browser, and I never bother doing that.

[Nameless12]

I have said some stuff that was not entirely accurate about *.tpl probably beucase I never took the time to do a lot of tests. I just included a plain text file with <?php echo 'hello world!'?>, it works. It makes sense and I feel stupid for even questioning if it is possible because include\require treat anything included as php so *.tpl will work

[redbullmarky]

yeah that's right. however, using .tpl as the definitive extension (as opposed to .tpl.php) or something is not a great idea unless the .tpl files are stored outside the web root. most servers out of the box will either server .tpl files (direct access that is) as plain text or offer them for download.
so when using non-standard extensions (ie, not php/htm/html/jpg/gif/png, etc) it's always a good idea to either:
1, add a further extension (.tpl => .tpl.php) so that if the file IS accessed, it wont reveal anything potentially damaging - after all, the only REASON for a .tpl extension is for visual clues to developer that the file is in fact a template.
2, store them outside of the doc root
3, change the server settings to parse .tpl files as .php files