Hi BaRzO.  The errors are set on the object itself, not the Controller, so all you need to do with your code example is replace $this with $u. Like so:

Replace:

With:

Alternatively, you can show all errors as a single string (each error within it will be wrapped by the error prefix and suffix tags):

Looping through all errors:

If you had instantiated your object like so:

You would access its errors like so:

If you think I should update my User Guide to make this clearer, let me know.

i did it but is giving this result…

Unable to access an error message corresponding to your field name.

edit :
Your user guide is very good i did read it all..
but if you can put some more example would be very nice i think maybe for beginers like me

Ah, I see.  I didn’t give an example of setting up the error messages for that, sorry.

What DataMapper is trying to do is read an error message for the “unique” validation rule from your validation language file.  One is not there by default since CodeIgniter’s Validation class doesn’t have the “unique” validation rule, DataMapper does, so it’s not finding it.

To solve this for now, copy the following into a file named validation_lang.php, and put it in your system/application/language/english folder.

I’ll make an updated version of DataMapper that includes a language file with this sort of thing already set up for you, since it will need a similar message for the other inbuilt DataMapper validation rules.

For any custom rules you make in your models that extend DataMapper, you can use the error_message() function.

UPDATE

A language file has been included with version 1.2.1 that has the validation error messages for the DataMapper-only validation rules.

Ok now it fixed
thanks i will try my self to learn what can i do with DM

Edit :
It’s me again
I want to ask… How we will drive with validation fields

Good question, and thanks for bringing it up since I think you’ve pointed out a shortcoming in the current version that I didn’t notice.

I’ve got the $rules side covered with the $validation array in the models, but I don’t think I covered off the $fields naming side of things for error messsages.  At the moment it uses the exact name of the field (username, email, etc) but as you’ve shown, sometimes you’ll want it like “Email Address” or “Password Confirmation” which is currently not accomodated.

It’ll require only a small change though, probably a change in format of the $validation array, or splitting it into a $rules and $fields array.  I’ll see what works best when I get the time, and then I’ll write up a full working “real world” example on how to use all aspects of the validation, including the naming of the fields for error messages etc.

Hi,

Two quick questions about DataMapper:

1. Why do you use join tables for one-one and one-many relationships instead of just using foreign keys?

2. Can you search based on relationships? (ie: if you have a “restaurant” model, a “menu” model and a “menu_item” model, and restaurants have one menu and menus have many menu_items, can you find all restaurants that serve items with “chicken” in the name? Can you find all menu_items served at Joe’s Diner?)

Greg

1:
I know I could have used foreign keys for One to One and One to Many relationships but my personal preference is to make it so the normal tables have no information at all about any other tables (including foreign keys).  So, they only contain the information relevant to themselves.  I also found doing it this way made the implementation of DataMapper much easier.

DataMapper ensures the integrity of relationships stored in joining tables are kept intact for each of the different relationship types, so you don’t need to worry about your One to One relationship becoming something else, it wont.

2:
Ok, so the Restaurant has a One to One relationship with Menu, and Menu has a One to Many relationship with MenuItem.

There’s several ways you can find which restaurants have the “chicken” dish.

NOTE: I’m assuming the “menuitems” table has a “dish” field, and the “restaurants” table has a “name” field.

Here’s one way (starting with the MenuItem):

Here’s another way (starting with all restaurants, to find the restaurants with the dish):

All MenuItems served at “Joe’s Diner”:

From what i have read so far in the User Guide, i can see how powerful of a system this is.

I was however reading the section up on ‘Automated Timestamps’ and see at least one main problem with it.

The problem i see with it is that the ‘Created’ and ‘Updated’ fields have to be set ‘DateTime’ type, however when i am creating fields that hold dates i never store them that way i always have it as an integer field which stores the unix_time_stamp.

Is there a possibility of making it so that the automated timestamps can accept either of the 2?

Ray

Yep, that’s do-able although if you need unix style timestamps urgently, you can manage them manually.  I chose to use MySQL’s DateTime for the automated timestamps because it’s much more flexible.  I’ll make it a simple TRUE/FALSE setting as to which type gets used.

Just a bit of trivia, although a long way off the unix timestamp has a year 2038 problem.  Not really an issue though since most people will fix their systems before then

In reply to the chicken dish and Joe’s Diner examples…

That’s perfect, the ability to chain models is very handy! That would make life much easier.

(ie: foreach($restaurant->menu->menu_item as $mi):)

It’d be sweet if you could do something like this:

$menuitem = new MenuItem();
$menuitem->where(‘dish’, ‘chicken’)->where(‘menu->restaurant’, “Joe’s Diner”->get();

instead of having to manually do a foreach loop.

Can use “assign” relations before issuing a save call?
Like this:

$restaurant->menu->menu_item = ‘Chicken’; (or $restaurant->menu->menu_item->add(‘Chicken’);
$restaurant->save();

Otherwise you’d have to do it like this right?
$restaurant->menu->menu_item->save($new_item); (having already created “$new_item” as a menu_item object

Also, can you delete like this?
$c->where(‘name’, ‘Australia’)->get()->delete();

As far as requiring join tables for one-one and one-many relationships… I don’t think it’s valid to say “it was easier to program that way”, becuase now it’s more work for someone using the library to create more tables. As for not wanting tables to know about each other (and therefore not having foreign keys), it’s an interesting way of looking at things. Are there any reasons you can see that would make that a desirable thing? I can’t really think of any major pros/cons either way off the top of my head. It’s something I certainly could get used to if I started using it.

One thing that could make life easier as far as managing lots of join tables is if you could manually set a join table name “prefix” (in database.php config file for example) so all join tables would appear together in an alphabetical list of table names (using “join_” or “_” for example).

Thanks,
Greg