[Deprecated] DMZ 1.6.2 (DataMapper OverZealous Edition)

[eluser]OverZealous[/eluser]
[quote author="tdktank59" date="1260187561"]
Now I have to go read the docs again... O well, it's all worth it in the end right?[/quote]

FYI: you should really only need to read two pages: the Change Log and Upgrading Instructions.

;-)

1.6.0 -> 1.6.1 is mostly a bugfix. 1.5.x -> 1.6.0 is a major upgrade!

[eluser]tdktank59[/eluser]
yeah im still at the 1.5.3 so im reading the 1.6.0 update lol

I know but its still the processes of learning and using the new functionality (when needed)

edit: btw I normaly do read the change log to see what you did lol

[eluser]OverZealous[/eluser]
I figured you did. I just like to ... um ... reinforce the existence of certain aspects of the docs. :-)

[eluser]tdktank59[/eluser]
[quote author="OverZealous" date="1260190240"]I figured you did. I just like to ... um ... reinforce the existence of certain aspects of the docs. :-)[/quote]

Yeah I think after the second time you "um ... reinforced the existence" of them I've started going there first to find my answers then coming here!

But yeah I agree, I've noticed a lot of well documented/repetitive questions that are easily answered in the technical issues, or some main page of the docs. So reinforcement is good!

NOTE: I am not saying anyone is lazy/dumb/stupid etc... for asking questions even if they are answered in the docs. I know we all at some points just space and don't see something right in front of us. Or just need more clarification. (in the later instance provide the knowledge that you know whats going on tho. It helps us save time in helping you.)

[eluser]silvergear99[/eluser]
Hello
I have been using this Datamapper for a few weeks and its works perfect. Thank you very much.

But i come up with a problem.

I have a loginform in the right sidebar.
And in the main area i have a registerform.

When I fill in wrong data in the registerform I get two "There was an error saving the form." Both in the main area and in the sidebar.

Both forms are rendered from a user model. Is this the problem ?
I tried using custom templates, like this

Code:

echo $user->render_form(array('username' , 'password' => 'password'),'login/check_login',array('save_button' => 'Log in'),'dmz_htmlform/login_form','dmz_htmlform/login_row','dmz_htmlform/login_section');

But I have no luck,

[eluser]BrianDHall[/eluser]
Say, what's a good way of dealing with validation where a field is only used on creating a new object - but is otherwise never used?

I want to use a password_confirm field to control account creation, but obviously beyond account creation it is never used. I'm probably just going to hack a custom validation rule that checks $this->id, or use a bit of controller logic - but is there a better way to handle this that is eluding me?

[eluser]OverZealous[/eluser]
[quote author="silvergear99" date="1260216099"]
Both forms are rendered from a user model. Is this the problem ?[/quote]

If they are the same user model, then yes, because the validation is done on the object itself, and the errors are tracked on the object.

I assume that after the user attempts to login with the sidebar, they are redirected to the "normal" login page, correct? If so, simply create a new, empty User object to use for rendering the sidebar, or, alternatively, create an empty user for the registration page (since logically the user is new).

But the error messages shouldn't be shared across two different user objects.

[eluser]OverZealous[/eluser]
[quote author="BrianDHall" date="1260244483"]
I want to use a password_confirm field to control account creation, but obviously beyond account creation it is never used.[/quote]

In this specific example, you don't need to make it complicated. If you use matches and required on a password_confirm field, DMZ will automatically fill in the virtual password_confirm field when loading an existing object. The only time you need to do something special is when programmatically changing the password (like a generated password); then you'll need to set both.

Besides, can't the user change the password at a later date? They'll need a password_confirm then, too.

----------

But, if you still want to create an only-required-when-new field, you'll probably need to do this:

1) Create a custom required method on your object, that has a specific check for the confirmation field:

Code:

function required($field) {
    if($field == 'password_confirm' && $this->exists()) {
        // You could try setting password_confirm here
        // This may not work if you are properly encrypting the password!
        // $this->password_confirm = $this->password;
        return TRUE;
    } else {
        return parent::required($field);
    }
}

2) For any other validation rules used on that field, you'll probably need to override them like above. (You might even want to add a method for doing the field/exists check, so you aren't copying and pasting code all over.)

----------

I might add (yet another) validation rule required_when_new that handles this internally. It's an easy addition.

[eluser]someoneinomaha[/eluser]
I apologize if this is covered in the guide. I didn't find it, but maybe I wasn't looking in the right place.

I'm wondering if there is a way to get the count of related items without going to the database.

So I have a user object that has a has_many relationship with an alias object. I get the collection of aliases by $user->alias->get(); But once I have that collection, it seems to me that I should be able to get the count of aliases by determining the number of records in the collection.

Is there a best practice way to accomplish this with DataMapper OverZealous and Codeigniter?

$user->alias->count() works, but goes to the database. If that's the best way to get the data I need, that's cool.

Thanks for your time & for the great library.

[eluser]OverZealous[/eluser]
@someoneinomaha
Just use PHP!

Code:

$count = count($user->alias->all);

I'm pretty sure there are examples of this in the [strike]DB[/strike] docs.

Update: Added this to the count documentation.