[Deprecated] DMZ 1.6.2 (DataMapper OverZealous Edition) |
[eluser]chadbob[/eluser]
[quote author="OverZealous" date="1261567139"]Make 100% sure you are doing this: count($p->all) and not this: count($p). I just tested it to be sure, and the latter always returns 1. I've got helpers all over, and have never seen anything like this. It just doesn't make sense, since $p->all is a normal PHP array, and count is an internal PHP function. Is the Datamapper library getting loaded correctly before it is used in your helper? Are you sure that $p is a valid object? Again, I just tested it, using almost exactly the same code. Works perfectly for me.[/quote] Yeah, I triple checked when I saw your first reply and panicked that I did something really dumb, haha. I don't see why it wouldn't work either, that's why I'm kind of stumped... I give up for now, I'll look over it all with fresh eyes tomorrow and I'm sure I'll see some obvious logic problem or something... Thanks for the quick replies as always!
[eluser]jpi[/eluser]
Hi, Here comes the french translation. Keep the good job ! In fact I have not used DMZ since version 1.4 (no PHP project at the moment) and I am a bit afraid of all the new features, I am afraid I will find DMZ not as easy to use as it used to be. Don't you think that the main advantage of DMZ over others ORM is is that every thing is straightforward ? Here is my point : the more you add features, the more complexe DMZ will be, up to a point it will look like Doctrine (for example). But Doctrine has a better "support" (the lead developper is paid by a company) and a "communauty", so maybe DMZ will not be as attractive for CI users. Just my thought ![]() (Sorry for my weird vocabulary or sentences, I am not fluent in English, but I try !) ---------------------------------------------------------------- <?php $lang['alpha_dash_dot'] = 'Le champ %s ne doit contenir que des caractères alphanumériques, des tirets bas ou haut, et des points.'; $lang['alpha_slash_dot'] = 'Le champ %s ne doit contenir que des caractères alphanumériques, des tirets bas ou haut, des slashes et des points.'; $lang['min_date'] = 'Le champ %s doit etre ultérieur à %s.'; $lang['max_date'] = 'Le champ %s doit ëtre antérieur à %s.'; $lang['min_size'] = 'Le champ %s doit ëtre supérieur à %s'; $lang['max_size'] = 'Le champ %s doit être inférieur à %s.'; $lang['transaction'] = '%s a échoué à %s.'; $lang['unique'] = 'La valeur du champ %s renseignée est déjà prise.'; $lang['unique_pair'] = 'La combinaison des champs %s et %s est déjà prise.'; $lang['valid_date'] = 'Le champ %s doit contenir une date valide.'; $lang['valid_date_group'] = 'Les champs %2$s doivent contenir une date valide.'; $lang['valid_match'] = 'La valeur du champ %s doit ëtre %s.'; $lang['related_required'] = 'Une relation %s est requise.'; $lang['related_min_size'] = 'La relation %s doit être supérieure à %s.'; $lang['related_max_size'] = 'La relation %s doit être inférieure à %s.'; $lang['dm_save_rel_failed'] = 'La relation %s n\'est pas définie correctement.'; $lang['dm_save_rel_nothis'] = 'Impossible de sauvegarde la relation %s : cet objet n\'est pas sauvegardé.'; $lang['dm_save_rel_noobj'] = 'Impossible de sauvegarde la relation %s. L\'objet en relation n\'est pas sauvegardé.'; /* End of file datamapper_lang.php */ /* Location: ./application/language/english/datamapper_lang.php */
[eluser]OverZealous[/eluser]
@jpi I'm not sure what the issue is. DMZ has not truly eliminated or significantly changed any features almost since I started extending DataMapper. Almost all of the features I have added are about solving real problems. Extensions allow anyone to add certain types of features in a clean, supported manner, without touching the source code. If you want to use DMZ the way it was in the past, you still can. If you want to use the new features, they are there to make life simpler. I've never used Doctrine, however, if it is anything like most "full" ORMs, it probably requires a significant amount of time to learn, configure, and integrate with CodeIgniter. If you are planning on developing a large PHP project, it would be worth it. If you are just building a small, one-off website, it might not be. Again, I don't know anything about Doctrine, and I am not speaking about Doctrine specifically! Doctrine may be a lovely ORM. I just am already using DMZ, and swapping ORMs is effectively impossible without starting over. DMZ is still targeted at simpler websites, where the main goal is to integrate a database with objects. I understand that Doctrine might be better supported. Heck, I never intended to support DataMapper in the first place. But the original DM stagnated, and I needed specific features. I add in the features I use, and try to support requested features. I release these changes so that others can benefit. I do my best to keep the manual up-to-date, and relevant, but there might be mistakes. I've also had semi-regular releases about once-a-month. Beyond that, I make no promises. :-)
[eluser]Dantetekanem[/eluser]
Hey, I did some little upgrades to DataMapper. Just added the possibility to model has after_save and before_save methods. How works ? very simple: class Model extends DataMapper { $after_save = "call_function_after_save"; $before_save = array("func1", "func2"); } and that call a internal function on the Model. Very simple. The version can be founded here: http://www.leonardopereira.com/datamapper.phps Here is a translation of DMZ to brazilian-portuguese: http://www.leonardopereira.com/datamapper_lang.phps And thank you soo much for this incredible library ! Cya. ----- Leonardo Pereira Cya
[eluser]OverZealous[/eluser]
Thanks, I added the pt_BR language to the source repository. Eventually I'll be adding methods that can be used to hook into the main methods (save, delete, etc.) for use in extensions, which will be better for upgrades and so forth. Validation can be used to modify fields just before a save, and that is the recommended method in most cases of handling before save code. However, if you need after save or other functionality, it would be easier to do this in a subclass: Code: class User extends DataMapper Then you don't have to modify the source to DMZ, nor do you have to worry too much about upgrades.
[eluser]Michael Ditto[/eluser]
Is it possible to add a relation to an object from inside one of its custom validation rules? Specifically, I'm taking some user-provided content (a tweet), parsing through it looking for hashtags and URLs, shortening said URLs, checking to see if they exist in the database already, and saving them as related objects. It's all preparatory logic because it can alter the content of the tweet (shortened URLs, eliminating duplicate hashtags if necessary, all to get it under 140 characters) so the logical place to do it is in a validation method. Currently I'm doing it outside of the object, but it would be really sweet for my model to be totally self-contained to avoid repeating a bunch of logic.
[eluser]OverZealous[/eluser]
I don't recommend performing any logic like that inside a validation rule. You could easily get caught in an infinite loop. However, why don't you do something like this: Code: class Whatever extends DataMapper { The only catch is you always need to save it from the Whatever object, but that should be a rather easy-to-enforce situation.
[eluser]Cro_Crx[/eluser]
Yo all. I'm having some problems with using the include_related_count() function on advanced relationships. It seems to work 100% fine on non advanced relationships. My application is getting a bit complex so I installed a fresh copy of the latest CI (1.7.2) and DMZ (1.6.1) and created an example to show the problem: SQL: Code: CREATE TABLE IF NOT EXISTS `owners` ( Puppy Model: Code: <?php Owner Model: Code: <?php And Finally The Controller: Code: <?php When I run that. It gives me the following: Code: A Database Error Occurred If I change the relationships back to simple and use the include_related_count it works completely fine. I had a look through the function in the library, although I think the problem is probably located within another function. I haven't really had much time to look through it thoroughly. Anyone else ran into this problem ? If I can't figure out a fix I might have to use a simple relationship. I was just using an advanced relationship to have an easier to use name instead of the name of the class in my original scenario. Update: In case you don't want to read all of the SQL error (I just realised how long it is). The problem is here: Code: somethingelse_`owners_subquery`.id Just CTRL+F that part to see the problem. If I could get 'somethingelse_' to not be there, that would be awesome ![]()
[eluser]OverZealous[/eluser]
@Cro_Crx Yep, looks like that is a bug. I'm not sure how I'm going to fix it (or if it is even possible), but I'll look into it when I get a chance. |
Welcome Guest, Not a member yet? Register Sign In |