Views :: Unable to load the requested file

Incidently, when I try to develop [root]/system/expressionengine/third_party/trevor/mcp.trevor.php, I am able to pull a requested view file without a problem.

<?php 
if ( ! defined('BASEPATH')) exit('No direct script access allowed');

class Trevor_mcp {
    
    function Trevor_mcp(){
        $this->EE =& get_instance();
    }
    function index(){
                $vars['trevor'] = 'Trevor';
        return $this->EE->load->view('cactus', $vars, TRUE);
    }
}

?>

Trevor,

I am going to move this thread to the new Development and Programming forum for you as it is more appropriate there.

The view path to your package is not automatically added for front end requests. On the front end, you will normally get your markup and data from the user’s template data. Have a look at the core module file example in the ExpressionEngine development guide.

View files can be used on the front end, but ExpressionEngine does not currently add that path as we are trying to discourage it. Users expect that a module will only output the markup and variables that they supply in their templates; it’s a very fundamental part of ExpressionEngine that its tags stay out of your way and do not impose their markup and sensibilities on the developer implementing the site.

That makes sense. I am use to working with others CMSs where part of the development process is to force designers to into using prefab page elements.

You can do it like this:

$this->EE =& get_instance();
$this->EE->load->_ci_view_path = PATH_THIRD.'modulename/views/';

But I don’t think EE approves this way of doing it.

Whilst Ellis Labs might not like the use of front end views, as a PHP dev it’s one of the best things about EE2. With most of my projects the end client has nothing to do with the templates so a module tag that outputs based on views is no issue.

However, there is some housekeeping to do if you’re going to switch to views, as you need to change the view path back in case something else is using it. A helper function similar to this is useful:

function dm_view($view, $path, data=array() ) {

    $CI =& get_instance();

    $tp = $CI->load->_ci_view_path;
    $CI->load->_ci_view_path = $path;

    $out = $CI->load->view($view,$data,true);

    $CI->load->_ci_view_path = $tp;
    return $out;
}

That’s really the only consideration though. I’ve recently completed a big job with custom modules and I’d say the ability to use views rather than templates saved me days if not weeks of work.

Whilst Ellis Labs might not like the use of front end views, as a PHP dev it’s one of the best things about EE2. With most of my projects the end client has nothing to do with the templates so a module tag that outputs based on views is no issue. … That’s really the only consideration though. I’ve recently completed a big job with custom modules and I’d say the ability to use views rather than templates saved me days if not weeks of work.

It’s not that we don’t “like” it; it just goes against the grain and is contradictory to a prime mechanism of how ExpressionEngine works for the front end developer: templating. On a project where you’re the only person involved, and no one will have to come behind you, and no client or other front end developer will need to modify the site (a rare combo for a site that requires a content management / publishing system), using views instead of tagdata is setting the stage for frustration down the road.

Modules and plugins in ExpressonEngine get their source markup and variables from template, and it’s how the user knows that they are controlling the output. If working with views is more natural to you as a PHP developer, then working with templates as flat files should not be a difficult hurdle, and it will save you and the people who inherit your work tremendous amounts of time and confusion down the road.

I think we’ll have to agree to disagree on that one Derek! Good documentation and good commenting is all it takes.

I like EE for it’s out-of-the box CMS features - and when I’m using them it’s template tags all the way.

But I also like it for it’s ability to stay out of my way when I’m doing something bespoke. Without the ability to use CodeIgniter features (including views) there are a lot of projects I’m now planning to do in EE that I would have done some other way before.

Good documentation and good commenting is all it takes.

While that is helpful, that’s not entirely true. How does the content publisher who doesn’t have FTP access make a change to the output on the page from that module when their supervisor asks for it?

In any case, I applaud your ingenuity. I like seeing people stretch EE, it’s just a fine line between saying “hey that’s neat” and “this is methodology we should recommend”.

How does the content publisher who doesn’t have FTP access make a change to the output on the page from that module when their supervisor asks for it?

Never going to happen on the project I’ve just completed. There’s a dev team supporting the source code via SVN, the content authors are locked down to only accessing Channel entries and certain module UI.

With EE2 you’ve given us the best of both worlds - a great CMS but also a development environment where we can do anything we like. So get used to some unexpected applications - you’re certainly going to see them! 😉

I think you can agree that your project and environment are atypical. So I will still recommend publicly only methods that apply to the majority of sites built with EE and the majority of developers and their organizations. EE is flexible enough to work with extreme varieties, but there is still a main stream, and we have a duty to represent that in the forums, particularly to a new user who is just learning EE development.

You and I having this conversation just now, for instance, put your recommendation into additional context, which will allow people to have a greater understanding of why EE encourages a particular path, and when specifically what you are recommending might be a fair option.

That being said, I don’t think there’s anything that you’re doing with source controlled view files that you could not just as easily do with source controlled flat file templates.

Just to comment on this:

You can get module data into templates, but how to do it the other way around.

For example, e-mail templates for my custom module, where do i store these? Now i use the “hack” above and store them as a view.

Could be great if could store them as template, but how to get the template data back into the module?

They only other solution i see is to store them into the database and write a backend interface, that adds a lot of extra logic. I will be the only one editing these templates, so why should I make the effort?

Not sure I’m understanding your specific question, dWise, so I’m going to give an example of what I think you’re asking, but if I’m wrong, please clarify and I’m happy to help.

Template:

{exp:foo_module}
<some>
  <markup>and {variables}</markup>
</some>
{/exp:foo:module}

In your module, the markup and variables above, i.e. the module’s own “template” is accessible via $this->EE->TMPL->tagdata. And if you keep the actual template above in a flat file template of its own, it’s ready for use in your source control system.

After fetching and prepping your variables as necessary, the parsing is done as:

$output = $this->EE->TMPL->parse_variables($this->EE->TMPL->tagdata, $variables);

The documentation on the Template Parsing class may help as it dives more deeply into the above topics.

thanks for the answer, but that’s not exactly what i meant.

This a template targeting a module function to parse the variables. I would like to do it the other way around. getting template data into a string, do something with the string, and then use it (for example) as the body of an e-mail.

In that case the custom module would get the contents from the template.