is it even possible to overwrite $_SERVER['REMOTE_ADDR']? I'll try it later on.
I don't think ANYBODY would ever use a framework that did that - if they did, they'd have far bigger problems than this ;) As for Quercus, it's not stable - again, you've got far bigger problems than just $_SERVER being a bit flakey. The ONLY place where $_SERVER may be an issue is where you're not using a CGI environment (eg CLI). As for get/set - yes - POSSIBLY. However, in this instance - we're talking about an IP address, which is presumably being recorded for security/auditing purposes, which changes the game slightly. Assuming this is the case, our concern is that it gets set, it get's set securely, can't be tampered with, and happens automatically (we don't want a developer to "forget" or decide they don't want to implement it). This argument is really only valid when you're talking about security and/or auditing. The rest of the time, I'd recommend using getters/setters. Allowing IP address property to be "set" introduces an attack vector and also extra code that could fail or introduce further security flaws. My advice would be to make IP address a private variable, create a getter method (no setter), and set the value inside the constructor to the object. This makes it much more secure, and easier to use - setting the IP address doesn't then become an "option" and the responsibility of the developer, it's mandatory, and done automatically, with a valid value every time a new object is created. You can also dispense with logic to handle when this value hasn't been set, validation of the value that's been set etc Alternatively, you could probably use a Doctrine behaviour to achieve the same. On 21 Mar 2009, at 10:32, Alan Bem wrote: > Yep, coupling model with outside data is really, really bad idea. > Let's look at Lee's example of using plain $_SERVER array. It works. > It works almost everywhere... ALMOST. > 1. What if U will decide to move models to another project with > another framework? What if that framework import all outside data > and cleans e.g. $_SERVER? > 2. What if you'll decide to deploy current project on another > platform like Quercus (Javas PHP implementation) where existence of > $_SERVER, $_GET, $_POST is not rock solid. > > Remember, always supply outside data to model, model shouldn't do > that. > > Cheers, Alan > > On Sat, Mar 21, 2009 at 11:16 AM, Fabian Lange > <fabian.la...@symfony-project.com > > wrote: > I would do neither! > The is the model. It knows about its data, but id does not know > where to get it from. It should not. No models should read data from > outside themselves. It might be finde to do recalculation of own > data, but where should it get the information from? This is exactly > the problem you have. The eas solution: let it set somewhere .. e.g. > in the action. > > Fabian > > > On Sat, Mar 21, 2009 at 10:42 AM, Lee Bolding <l...@leesbian.net> > wrote: > > Or... $_SERVER['REMOTE_ADDR'] > > It may look "dirty", but your models won't be coupled to Symfony ;) > > It should be marginally more efficient too - after all, at the end of > the day that's exactly how Symfony is gonna get that information back > to you. > > On 21 Mar 2009, at 09:29, michael.pie...@googlemail.com wrote: > > > > > sfContext::getInstance()->getRequest() > > > > Michael > > > > > > On 21 Mrz., 03:00, Benjamin <agtle...@gmail.com> wrote: > >> Hello, > >> > >> In my user model I would like to capture the user's ip address for > >> new > >> records in the user->save() event. I am using symfony 1.2. What > is > >> the best way to access the sfWebRequest object from within the > model? > >> > >> Thank you, > >> Benjamin > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
