Why can't f3 find my support files?

[Nikolaos Giannopoulos]

I have a controller that invokes a function in a support PHP file e.g.

$sql = find_marker($sql, 'CREATE', '(', TRUE);

and in a file app/support/core/believe_string.php

function find_marker($subject, $search_start, $search_end, $include_search_str = FALSE) {

and finally in config.ini I have:

AUTOLOAD = app/controls/|app/models/|app/support/core/|app/support/integration/

Yet F3 keeps throwing the error:

Call to undefined function find_marker()

I thought the autoload would mean I do not need to specify requires or require_once anymore.  What am I missing?

Thanks,

--Nikolaos

[Nikolaos Giannopoulos]

So it works if I include in my index.php

require('app/support/core/believe_string.php');

Now to have 30 lines of these or use a loop to recursively require the files.

Not exactly fat-free.  Am I missing how to get f3 to do this for me via AUTOLOAD or some other mechanism?

--Nikolaos

[Nikolaos Giannopoulos]

If I am not missing anything and f3 doesn't load these files then an even better solution is:

function require_all($dir, $depth = 0, $max_scan_depth = 0) {
 if (($max_scan_depth != 0) && ($depth > $max_scan_depth)) {
   return;
 }
 $scan = glob($dir . DIRECTORY_SEPARATOR . '*');
 foreach ($scan as $path) {
   if (preg_match('/\.php|\.inc$/', $path)) {
     require_once $path;
   }
   elseif (is_dir($path)) {
     require_all($path, $depth + 1);
   }
 }
}
require_all('app/support');

Credit:  https://gist.github.com/pwenzel/3438784

--Nikolaos

[ikkez]

the F3 autoloader is a namespace-aware autoloader. so if you want the files in app/support/core/ to be automatically loaded, write classes with namespaces and put your helper functions in there, i.e. like:

file: app/support/core/believestring.php

namespace Support\Core;

class BelieveString {
    static function find_marker() {

    }
}

AUTOLOAD = app/

and in your code:

$result = \Support\Core\BelieveString::find_marker();

this is the way the autoloader is able to find and load your files dynamically.

[Nikolaos Giannopoulos]

Thanks.  That worked well.  I have to say - and this is not a Fat-Free thing - but PHP namespaces get really screwy when setup as they then make everything else relative to the namespace and force you to start using \ for things like \Template and \DB\SQL.  Then again the flip side is that they make what's being referenced extremely explicit.

Moreover, I kind of like that Fat-Free expects the class name and file name to be the same as it also makes it really explicit as to what code file is being used not to mention that I presume this makes the framework more performant to boot :-).  The only improvement that would be nice is to allow AUTOLOAD of .inc as well as .php files (at least when I tested Fat-Free only picked up the .php files).  Not a big deal... the code is coming from a Drupal project hence the .inc can easily be renamed to .php but it would be nice if Fat-Free could pickup either one... then again perhaps not and keep Fat-Free lean except of course if you are incorporating third party code and can't rename it for some reason (but then you should be able to create an autoload wrapper).

In any event, Thanks, turns out this was more of a a) had not done this much in PHP and b) figuring out what Fat-Free looks for when autoloading.

[Rayne]

It would be great if Drupal would stop to use silly file suffixes … and many other things. I had so high hopes when they announced to use some of the Symfony libraries …

You don't have to extend F3 to register another class loader. More information here: http://php.net/manual/en/function.spl-autoload-register.php

[Nikolaos Giannopoulos]

I concur that there is no need for .inc file extensions and have already changed mine to .php.  So I agree there is no need for Fat-Free to do this.

And yes, having built a large application with Drupal over a year (3 years total including other sites) and seeing how thin what I have done in Fat-Free in less than 2 weeks is is a huge contrast!

Unless you want to build a site using a UI heavy CMS, with tons of 3rd party modules, and enjoy keeping up with their updates, and hacking things to work the way you need them to work then Drupal is not for you.  When I first started working with the rendering engine I was impressed and after all the bloated field configuration and building a large set of wrappers to streamline things I am now finding that it was all a huge waste of time.  The caching in the rendering engine was also very enticing but Fat-Free already provides that and caching in multiple other areas to boot.

No need to argue one way or the other but yes in hindsight a lot of things in Drupal appear silly IMHO as well... but for the developer that primarily cobbles things together it may be quite useful.

--Nikolaos