![]() |
[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - Printable Version +- CodeIgniter Forums (https://forum.codeigniter.com) +-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20) +--- Forum: Archived Libraries & Helpers (https://forum.codeigniter.com/forumdisplay.php?fid=22) +--- Thread: [Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) (/showthread.php?tid=18196) |
[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 05-13-2009 [eluser]OverZealous[/eluser] [quote author="Daniel H" date="1242279448"]And then my db table: Code: CREATE TABLE `accounts_users` FYI: This is 100% acceptable, but an alternate way of doing it, since creator and editor are both $has_one, is to put editor_id and creator_id directly on the accounts table, and save accounts_users for just the many-to-many: Code: CREATE TABLE `accounts` This might be preferable, because you don't have to have all the NULLed columns for every join. [Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 05-13-2009 [eluser]Daniel H[/eluser] Ah yeah, I see, but then how do I access the creator and editor user objects using the $account->editor->get(); syntax? I figured this would be the only way to do this? [Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 05-13-2009 [eluser]OverZealous[/eluser] You don't change anything else from your example. DMZ just automagically determines where to store the relationship. You access, save, and delete it the same way, no matter how it is stored internally. [Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 05-13-2009 [eluser]Daniel H[/eluser] Oh I see! That really is superb. Thanks!! [Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 05-17-2009 [eluser]BaRzO[/eluser] Hi all, i will have users as admin, mod, gold, silver and standard in my project and all users can be friends with other users even if the user admin or standard all users can have many articles, groups etc. how can i manage users pls give me an example [Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 05-17-2009 [eluser]warrennz[/eluser] EDIT Have just read through the docs and discovered that validation on an existing record only runs if the value of the new field has changed. That pretty much answers my question. THanks ![]() ----------------------- Heya Quick query regarding validation Is it possible, at all, to partially validate save() data. For example if I have 2 fields, firstname and lastname, that both have a 'required' flag for validation. That works fine when I create a new user, or update an entire user. But what I need is to be able to only update the lastname ( have it checked against its own validation ) and not require the first name to be there. Possibly defeats the entire purpose of validation...i dunno ![]() Am I missing something.. is there a solution for this? Thanks in advance [Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 05-17-2009 [eluser]warrennz[/eluser] Hiya again Please advise on recommended practice for the following In my controller have a user object. I then pass this user object to my view. In the view all the fields I set their value to object->db_fieldname When the form is submitted the posted values(that are db fields) are assigned to the object->posted_field and save() is ran. Various validation rules etc run fine, if the submission does not succeed the form is shown again and all the last entered values from object->db_fieldname appear in the fields as expected. Is this a good practice? Are there any other methods that are better/secure/faster? For example standard CI has a form validation helper that has a set_value($fieldname) to call that posted/validated value.. Many thanks [Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 05-17-2009 [eluser]OverZealous[/eluser] @warrennz That sounds really overcomplicated. Why wouldn't you just set the value of the field to object->fieldname. Then load up the object, set the fields, and attempt a save. If the save fails, use the update object to prefill the form. If the save succeeds, you don't need to do anything else. Something like this: Code: function edit($id = 0) { Then in your view, output both the object and any errors that exist ($widget->error->{$fieldname}). This way, if someone types in a change, but makes a mistake, the changed value is passed back to the browser. You should never reset an incorrect form to the original values. That's just bad programming! :-) FYI: I won't be able to provide much feedback until next week, so questions may go unanswered. Also, for BaRzO, I'm sorry, but you need to read the documentation, look through the rich history of examples, etc. I highly doubt anyone is going to write your app for you. ![]() [Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 05-17-2009 [eluser]warrennz[/eluser] @OverZealous It appears I didn't make myself all that clear by my last post, I am sorry for that. Here's a better break down of what I'm doing, as you can see it is very similar to your posted example.. Code: function create() *1 - Initialize the user object. This way my view code doesn't break when nothing is posted. Is this a good/bad idea? is there a better way? *2 - Create a property that is not in the table field. This is _solely_ for the purpose of repopulating the html form. Again, good or bad? is there a better way.. I know it doesn't throw up any errors and $u->save() will ignore it but still... I don't think there's anything seriously wrong with the way I'm writing code ( will happily be proven wrong though! ![]() Thanks again [Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 05-17-2009 [eluser]OverZealous[/eluser] There's nothing wrong at all, but one thing you should look at is the DataMapper example for validating the password (using confirmpass). You can actually create a validation field that doesn't map back to the database field, and use it in validation. The rule would look something like this: Code: array( Of course, you'll probably want to include a check to make sure it isn't empty. You might be doing all of this already. Beyond this, there's nothing at all wrong with having "fake" fields on your object. I use them all the time, for much the same purpose. |