I'm in a need to use beforeFind() in a child class of CActiveRecord.
Basically, I need to convert some data from before actual search in the DB is performed.
How do I alter the about-to-occur-find-operation that is about to take place, inside beforeFind()? Messing with $this attributes is not useful since its not even populated, which is a little surprise.
I've seen that the documentation mentions a "hidden CDbCriteria parameter" but I just couldn't guess how to use it... . Unfortunately, the documentation on this subject is slim.
What I need to do is rather simple: I've got a table column for storing IP addresses. The most efficient design from scalability perspective, is to use a VARBINARY(16) data type for the column. See for example this SO question page (and answers) on this.
So, the cleanest solution would be to have beforeFind(), afterFind() and beforeSave() work transparently for the users.
In the code stack, the IP addresses would be the normal dotted-quad and in the DB level, its whatever that goes into the field after utilizing PHP's inet_pton() method in those after/before hook methods.
It was supposed to be cool. and it is cool - with afterFind() and beforeSave(), where I have the ip_address attribute of the object at hand, at the mercy of my uber-manipulation powers.
Here's the point, and the need: thing is, I don't know how to achieve that on beforeFind(). I cannot do a blind mergeWith() as I need to check if ip_address attribute is part of the original criteria, and that I don't know how to do.
Help!
TIA :)
I've got this nice suggestion on yii forums.
Basically, I just need to override findByAttributes() in the child class and I'm done :)
Related
would it be considered a valid implementation if I do not use the model for certain parameters? For example a webform posting values directly to the controller which then passes them to another class. Is it necessary to make sure that all the fields in the webform are also referenced/stored in the model?
I consider it a valid implementation, but suggest that you do this only if the parameters you want to exclude from the Model are absolutely NOT going to be used by the View (other than for confirmation of data entry in your webform), AND there is no need for the parameters to be referenced again once handled by the Controller.
Yes, it would work, strictly speaking.
However, you probably want to use the model. You don't want to create a new variable every time you run the view, which would happen if you use the controller.
I would consider it valid implementation if you decided not to use the model for certain parameters. I believe there are instances where certain fields may not relate directly to the model in question therefore giving valid reason to break those fields/parameters off from the model.
I am brand new to Magento and the documentation, primarily the phpDocs, are difficult to navigate. For example,
$attributeSet = Mage::getModel('eav/entity_attribute_set')->load($id);
In the php doc for Class Mage_Eav_Model_Entity_Attribute_Set there is no mention of the method getAttributeSetName() either in inherited methods or otherwise and yet this works.
$attributeSet = Mage::getModel('eav/entity_attribute_set')->load($id);
echo $attributeSet->getAttributeSetName();
So I suppose I have several questions.
Can someone explain to me why the documentation is this way?
Where I can find the mysterious getAttributeSetName() method in the phpDocs?
My theory is that there is some inheritance or a design pattern implementation going on that I'm not understanding, maybe someone can shed some light on this for me.
If you really want to fry your brain, take a look at the source code for Mage_Eav_Model_Entity_Attribute_Set and follow the inheritance chain all the way back. You won't find a getAttributeSetName method defined anywhere.
All Magento objects that inherit from Varien_Object can have arbitrary data members set on them. Try this.
$attributeSet = Mage::getModel('eav/entity_attribute_set')->load($id);
$attributeSet->setFooBazBar('Value');
var_dump($attributeSet->getFooBazBar());
var_dump($attributeSet->getData('foo_baz_bar'));
var_dump($attributeSet->setData('foo_baz_bar','New Value'));
var_dump($attributeSet->getFooBazBar());
You can also get all the data members by using
var_dump($attributeSet->getData());
but be careful dumping these, because if there's a data object that has a circular reference and you're not using something like xDebug, then PHP will have a fit trying to display the object.
Magento stores data properties in a special _data array property. You can get/set values in this array with getData and setData. Magento also has implemented magic getting and setter methods, so when you say something like
$object->getFooBazBar();
The method getFooBazBar is transformed into the data property foo_baz_bar. and then getData is called using this property. It's a little tricky to get your head around, but once you get it you'll start to see how much time you can save using this pattern.
One side effect of this is, of course, it's impossible to infer what data properties any object might have by looking at it's class file, so there's no phpDocs for these methods.
What is the best way to create logs & history in CakePHP. I was thinking if there is a way to create a Helper "that accesses" one table and then I call this helper inside of each controller that I want. However, I have read that this is not MVC standard. How would it be the correct way to do that?
I appreciate your time spent answering me that. Thanks!
thats what behaviors are for.
I use the LoggableBehavior from here:
https://github.com/alkemann/CakePHP-Assets/blob/master/models/behaviors/logable.php
works like a charm. they are then fetched and displayed in the view, if you want to.
Just implement a different log engine for that purpose. The CakeLog class actually works somewhat like an observer and the log engines like listeners.
Simply use CakeLog::write() and your custom engine that could load your log model in the constructor using ClassRegistry::init() and pass the incoming data from write() to the model.
The manual will help you with that. http://book.cakephp.org/2.0/en/core-libraries/logging.html#creating-and-configuring-log-streams
In Windows Phone a ListBox support the virtualization of the data, that means it can only load the data needed and not everything. Peter Torr explains the interface you need to implement.
The short version is that you have to create both a method that return the position of an element and another one that return the element in a specific position. The problem is that the example of Peter Torr is rather dumb, he just return an object with the index as a name.
My question is: how do you actually implement this ?
My idea is to create one file that contains a list of an (integer) index and an (integer) id and a file for every object that contains the actual data. It doesn't seem a really elegant idea, but I can't think of anything better, can you ?
UPDATE
It seems that my question is inaccurate. When I say that the example of Peter Torr is "rather dumb" I am not saying that he has done anything wrong; his objective was simply to explain what interface you need to implement. The practical implementation will depend on the specific data.
What I am asking is what choices do I have to implement this ? Should I simply put the data on a web service and query it every time (with a local cache, of course), build a database, create a file the store the indexes and one for the data ? Is there a solution good enough in every case ? What are the downsides and upsides of every choice ?
The article you linked to includes a link to a downloadable project which demonstrates how to implement this.
What more are you after? The general idea is that the ListBox will call into your IList when it needs data. it will ask for an item at a specific index and you pass back an object. it then, presumably, calls ToString() on that object and displays the result in the list.
What that actual object is and where you pull it from is completely up to you. You might be using a really large array in memory. You might be pulling from IsolatedStorage or a web service. You could certainly use it to pull file info, but I don't suspect anyone has a ready-built IList implementation so that's the part that you will have to implement based on your specific project.
After writing a few lesser programs when learning Java the way I've designed the programs is with Model-View-Control. With using MVC I have a plethora of getter methods in the model for the view to use.
It feels that while I gain on using MVC, for every new value added I have to add two new methods in the model which quickly get all cluttered with getter & setters.
So I was thinking, maybe I should use the notifyObserver method that takes an argument. But wouldn't feel very smart to send every value by itself either so I figured, maybe if I send a kind of container with all the values, preferably only those that actually changed.
What this would accomplish would be that instead of having a whole lot of getter methods I could just have one method in the model which put all relevant values in the container.
Then in the view I would have a method called from the update which extracted the values from the container and assigning them to the correct fields.
I have two questions concerning this.
First: is this actually a viable way to do this. Would you recommend me doing something along these lines?
Secondly: if I do use this plan and I don't want to keep sending fields that didn't actually change. How would I handle that without having to have if statements to check if the value is not null for every single value?
I've more familiar with the MVP paradigm, but hopefully they're similar enough to comment. While getters (and setters) in and of themselves are not necessarily evil, they are sometimes a sign that your subsystems are too strongly coupled. One really great way to decouple this is to use an event bus: see Best practices for architecting GWT apps. This allows the view to just shoot off events for the controller to listen for whenever something important happens, and the view can listen for events whenever something changes in the model that corresponds to updating the view. Ideally you wouldn't even need to ever pass the model to the view, if you can break up any changes into incremental pieces and just tell the view to change this part and then this other part.
If you feel you have too many getters (and setters) in your model class, maybe you have too many fields altogether. Is it possible that there are several distinct classes hiding within your model? If you extract these into separate classes, it may make your model more manageable.
OTOH the associated container you are thinking about could also be viable - but then why duplicate all data? You could instead use the associated container directly in the model to store all properties you can think of. And you can also pass this around for observers to get updates (preferably wrapped into an unmodifiable container, of course) - although in this setup you wouldn't need to.
In general, Java is a verbose language which expects you to put all those getters and setters (and a lot more) in place. However, any decent IDE can generate those for you with a few keypresses. Note also that you need to write them only once, and you will read and call them many many more times. Verbose also means easily readable.
If you have too many getter it's ok. But you shouldn't need the setter. The view is supposed to only read/query the model.
The MVC pattern should promote something that is asymmetric: the control update the model by calling methods in the model that embed the logic and update the sate accordingly; this respects encapsulation. The view reads/queries the model via the getters. This goes a bit against information hiding, but that's how MVC works.
I wouldn't personally pass all information in the events. It sounds complicated to me: either you end up with something that is not statically typed (e.g. you pass hashmaps), or with a plethora of typed events. I would stick with something simple, and have (possibly many) getter in the model.