[Deprecated] DMZ 1.6.2 (DataMapper OverZealous Edition)

[eluser]selfkill[/eluser]
@OverZealous

Yeah, I figured this wasn't exactly an officially supported way of doing that. It took a lot of trial and error to get something that worked. I really think a variable to specify the actual class name would be a nice feature. For example, what if I wanted to have a library named User to handle user functionality in my project? I would need to rename the model to something like Myuser and the table to myuser, and for a perfectionist who likes consistency, this just bugs the hell out of me. But maybe a feature like this would require a lot of reworking of the code so I don't know.

[eluser]OverZealous[/eluser]
@selfkill

That's really what the model field does: it specifies the class name. (It's a legacy term, so I cannot change it.)

If you need a library to manage users, you should probably name your library User_Manager. It just makes more sense logically. It's a library to manage users. If you name the library user, then it's a user to manage user_models? ;-P

And as for controllers, the common solution of using the plural form for the controller works very well, and is usually only an issue for words that don't have a plural form.

In general, I am strongly averse to adding options like that: it's like the ability to rename the id column, or not have id be an integer. These options would benefit very few DMZ users, and would significantly modify the code (breaking a lot of simple, hard-coded strings into more itty-bitty pieces). Plus, it wouldn't help with the relationships, because the only short form for the relationships is to put the classname as the relationship name. How would DMZ know which class you meant?

But mostly, it's that you are trying really hard to work around a self-created problem. ;-) It just doesn't make sense to have the model and classname be different.

[eluser]selfkill[/eluser]
@OverZealous

The $model variable didn't exactly work that way unfortunately, I tried it.

My example with the User class probably wasn't the best. A better example would probably be a model named Session conflicting with CI's own library named Session or some other third party library that couldn't be renamed.

The other solution I thought up was instead of a variable for the class, you could have another variable for the singular version of the table (i.e. $table and $table_singular). However, if it requires too much work to implement and breaks legacy code, then it's not worth adding such a feature like you said. I just thought otherwise, it would come in handy.

[eluser]emorling[/eluser]
How do I get drop downs to work with the render_form function?

I tried this:
var $validation = array(
'mydropdown' => array(
'label' => 'Pick a number',
'type' => 'dropdown',
'list'=>array('1'=>'one','2'=>'Two'),
)
);

Any help would be appreciated.

[eluser]OverZealous[/eluser]
Deleted

[eluser]NachoF[/eluser]
Hmm, I dont know if I should upgrade or not... I dont want to have to be updating too often at the risk of hurting my app.

[eluser]cahva[/eluser]
I was bold and upgraded today DMZ to one site. Cache doesnt work even after deleting previous cache files. It just gave blank page after that. Without cache it seems to work good. I didnt have time to dig deeper, but if someone else could test DMZ with cache turned on I would be gratefull..

For the upgrade, I did the usual. Overwrite extensions and datamapper lib + empty cache dir. I upgraded from 1.6.2.

[eluser]beemr[/eluser]
[quote author="emorling" date="1266893511"]How do I get drop downs to work with the render_form function?[/quote]

I think if your list is less than six items or so, htmlform will default to checkbox. You should be able to override the defaults for specific fields when you call render_form()

Code:

var $validation = array(
        '{field name}' => array(
            'label' => 'Pick a number',
            'type' => 'dropdown',
            'list'=>array('1'=>'one','2'=>'Two')
        )
    );

Then in the view:

Code:

${model name}->render_form($validation);

Is that what you mean?

[eluser]OverZealous[/eluser]
@cahva
I assume you mean the "Production Cache" feature? (there's like 3 or 4 things called cache in DMZ! ) I'll look into seeing if my changes broke that.

@NachoF
This release, especially, is just a release candidate. If you don't want to help test it, then you should probably wait. (Of course, if there are bugs that affect your application specifically, I won't be able to fix them for the final release.)

However, it's a safe update (if it doesn't work, just replace the new DMZ with the old DMZ). There are no changes to the language files, and the new config option is not necessary, so you probably just replace application/libraries/datamapper.php to test it.

In general, DMZ updates will warn you if something could cause your current app to break.

[eluser]OverZealous[/eluser]
OK, I fixed the Production Cache issue. You can't use var_export to export a stdClass, because the stdClass doesn't know how to re-import the data later.

So, I changed $_field_tracking to an array, which works.

If you need the cache functionality, just re-download the 1.7.0-RC1 lite file, replace the library, and clear your cache again. If you don't, then no worries until I release the final version.