Thread

Still getting this:

Parse error: syntax error, unexpected $end in D:\xampplite\htdocs\em\system\application\controllers\admin.php on line 198

Line 198 contains only }

Usually this is because of an unclosed tag, but now…

Parse error: syntax error, unexpected $end in D:\xampplite\htdocs\em\system\application\controllers\admin.php on line 198

That means the error is in your code.  If the error was related to DMZ, it would mention one of the DMZ files.

A parse error basically means a typo.

Run this on the command line to see that it is your file:

php -l D:\xampplite\htdocs\em\system\application\controllers\admin.php

(This assumes PHP is a global executable.)

Actually is your example from rar 😉

@Jack Scott, OverZealous

It broke with a
Fatal error: Uncaught exception ‘Exception’ with message ‘Unable to call the method “_assign_libraries” on the class Rem4_property_file’

To offer an alternative to what Phil said, I believe the problem is that you’re loading the class via CI’s Loader, which calls _assign_libraries. If you follow the DMZ way of not calling load->model and just do a “new Whatever()” you shouldn’t run into that problem.

On a side note, I don’t see why you’d really need to auto-load related models in your model’s constructor, because accessing the related variable, e.g. “$user->group” will auto-load the related class anyway.  That’s just part of DMZ.  And if you wanted the model in your controller, instantiating a DMZ model (as in the above paragraph) auto-loads as well.  So maybe you have some reason for doing so, but I’d guess that you’re going about it the hard way and that extension to the constructor isn’t necessary.

Letting the built-in lazy loading of related classes do its thing rather than loading all related classes whenever one is instantiated is bound to have some performance benefit too, possibly significant if you’ve got a bunch of classes all related to each other.

Actually is your example from rar 😉

By example, you mean the example app, or examples in the docs?

I just tried the example application, completely resetting it, and never saw the error.  There might be a typo in the docs, however.

I just cloned the CI from bitbucket, copied the example from archive into /system overwriting everything 😊

download my code from here:

<a href="http://dl.transfer.ro/em-transfer_RO-17mar-86edf3.rar">http://dl.transfer.ro/em-transfer_RO-17mar-86edf3.rar</a>

To offer an alternative to what Phil said, I believe the problem is that you’re loading the class via CI’s Loader, which calls _assign_libraries. If you follow the DMZ way of not calling load->model and just do a “new Whatever()” you shouldn’t run into that problem.

Good call.  I actually didn’t know that CodeIgniter calls _assign_libraries on models.

I’ll have to think about what to do.  It’s actually kinda bad to use Loader::model(), since DMZ specifically says don’t do it.

I might rename _assign_libraries (like, _assign_libraries_private), then use the original method to throw an error when models get loaded manually.  This will prevent DMZ models from being loaded by CI.

Or, I could just let CI load the model, but there’s no telling if that would be a problem or not.

I’ll think about it.

Just updated to 1.7 and I apparently have that same error. :(

ok found out why, I don’t need to load models at all !

Not in autoload, neither in the controller. It work with magic.

OverZealous, did you download my archive?

@Mareshal
I don’t know what to tell you.  It’s not DMZ — there’s no parse errors with the source for the admin.php file.  It hasn’t been changed since 8/25/2009 (I can see it in the repository).

I just double-checked the ZIP, too, it’s OK there.

Maybe that file is corrupted on your copy?

FOR ALL THOSE WITH THE _assign_libraries ERROR

Remove all the models from autoload, just as it says in the installation manual.

Double-checking your installation is the first step in the troubleshooting document.

I just tried everything from scratch, same error. I am using xampp with PHP 5.3.2

@Mareshal
Well, did you try to run the admin.php file through PHP lint (-l)?

Did you check to see if the file was corrupt?

Also, why are you using the CI from bitbucket?  Are you sure it is an official version?  The latest version of CI is 1.7.2.  You might have issues with running a pre-release or dev version of CI.

I can’t help you much more.  You’ve basically said “I’ve installed it, it doesn’t work.”  But it does work.  The example app is my main testing ground for DMZ.  I run it all the time.  Is it configured correctly?

I think the example app still uses short tags, since I prefer them.  Maybe you need to enable short tags.

I can’t help beyond that.  Feel free to update if you figure out what the problem is.

Don’t know why and how but works. Short Tags were On, because when I install xampp I make my own config.

But I really don’t get something. On this page: http://www.overzealous.com/dmz/pages/update.html

this query:

// Mark all users as new
$user = new User();
$success = $user->update('isnew', TRUE);

Produces this: UPDATE `users` SET `isnew` = TRUE

How does DMZ know which talbe to update? or where do you tell the script to update the table I want?

Or maybe I don’t understand how datamappers work.

Edit: I think I understood now. Every table has a related model, where tables are declared. Am I right?

Regarding my previous post:

My app’s loading models using CI->load->model(), I guess that’s my bad.  CI’s load->model() calls _assign_libraries() on the loaded model, which causes the fatal error.

My app’s running under Expression Engine 2.0, which sits on top of CodeIgniter.  I’m guessing EE uses an early version of CI version 2; it allows addons to be packaged into a third party directory and supports include paths for libraries and models which DataMapper’s autoload() doesn’t know about.  That’s why the app needed its models manually loaded through CI, DataMapper couldn’t find ‘em.  I have a patch to autoload() that reads the CI include path, I’ll post it if you like.

While debugging the patch, I noticed autoload() fires each time ExpressionEngine loads ones of its modules or plugins.  I’m not sure if that’s a good thing, it could cause a problem if a plugin and model share the same name.

is it worth considering letting CI load DataMapper models?  I never noticed a problem with CI-loaded models under DataMapper 1.6.2 or earlier versions, and I’ve been working on this app for several months.  Letting CI handle loading is less likely to trip up CI users new to DataMapper, and might save some problems in the future as CI grows.  I like your idea of renaming _assign_libraries() to _assign_libraries_private(), that should allow models to autoload or let them load through CI.