Empty and/or Filter ObjectStorage objects - typo3

I have an object appointment with a property expertises of type \TYPO3\CMS\Extbase\Persistence\ObjectStorage<\Vendor\Extname\Domain\Model\Expertise>.
Additionally one important property of Expertise is the bool checked.
What I want to do in my AppointmentController is:
In the first action: Empty the appointment's property expertises (not set it to NULL, I just want an empty ObjectStorage that I can add something to later)
In the second action: Fill appointment with expertises (from a different object) whose property checked equals true
To start out with the emptying I looked at the answer from here but it didn't work for me.
This is what I tried:
$appExp = $appointment->getExpertises();
foreach ($appExp as $exp) {
$appExp->detach($exp);
}
\TYPO3\CMS\Extbase\Utility\DebuggerUtility::var_dump($appointment);
But it shows that all expertises are still in appointment.
In the second action I do this:
foreach ($expertises as $expertise) {
if ($expertise->getChecked()) {
$appointment->addExpertise($expertise);
}
}
It works, but I wonder if there's an easier "filter" function that can automatically filter the checked value and return an ObjectStorage object. Because this way I could just use setExpertises() and the old ones would get overwritten which would make the first step unnecessary.
So does someone have an idea for the emptying and filtering of ObjectStorage objects?
I looked a bit into the ObjectStorage Class reference but there's no obvious function that empties it (removeAll ist just for objects contained in another storage from the current storage) and no filter function either.

There is an easy way to remove all objects from the object storage:
$appointment->getExpertises()->removeAll($appointment->getExpertises());
As for filtering: as you already noticed, you have to do it yourself. I would implement such functions like getActiveExpertises in the Model, because it fits there much better than in a controller.

The setters in ExtbaseObjects that refer to ObjectStorages have an optional parameter that defaults to null. Just call the setter without a parameter. You don't have to waste performance by instanciating an empty StorageObject.
$appointment->setExpertises();

Related

Are setters mandatory in extbase models?

I am following this documentation: https://docs.typo3.org/m/typo3/book-extbasefluid/10.4/en-us/5-Domain/2-implementing-the-domain-model.html
The 'Organization' model defines setters and a method "addContact"
/**
* Adds a contact to the organization
*
* #param Person The contact to be added
* #return void
*/
public function addContact(Person $contact)
{
$this->contacts->attach($contact);
}
I created an extbase model myself, which requires records from an objectstorage. But i figured it out, that I could render records from an objectstorage in fluid, without defining "add{property}" and "set{property} methods. What are the purpose of these methods? When and where are they called?
Setter methods (and adder for ObjectStorages) are not needed by the framework. I'd recommend not adding them if you do not have the use case of setting a value programmatically.
Generally speaking you should not add code that you dont need.
Extbase itself will use reflection to gather and set properties that match database columns.
Setters are for fields that have a representation in the database.
You can add more properties to the models which are i.e. calculated or get the values somewhere else from that don't have setter methods.
Those properties you can access in fluid templates as long as they have also a declaration in the model.
Concerning the method addContact that's one property with probably 4 methods:
getContact (is singular but can have several)
setContact (is singular but can have several)
addContact (adds one contact to the $contact)
removeContact (removes one contact from the $contact)
So this property is still connected / related to the database, just that it's a foreign table as it's foreign model too.
$contact in your case is likely of type \TYPO3\CMS\Extbase\Persistence\ObjectStorage which is like an array iterable but just as object.

Post-Initialization in extbase domain model

In one of my extbase models, I want to initialize some properties derived from the properties that are saved in the database. The computation of these virtual properties is time consuming, so I'd like to cache them. Thus my program flow should look somehow like this:
Load the domain object as usual from the database
Check if the virtual property is available in cache. If so, fetch it from there, otherwise compute and cache it.
I first thought the method "initializeObject" is what I need, but it is not: It is called before any property is initialized from the database. So I came up with two other ways:
I can call an initialization-method manually from the repository after fetching the object, but that seems weird and would break if someone adds another find* method to the general repository.
Another idea is to add a boolean "virtualPropertiesInitialized" to the model, query it whenever one of the virtual properties is accessed and initialize the virtual properties if needed. Also seems weird, but would not break if someone adds another "find"-method to the generic repository.
My question is:
Is there a default/best-practice how to do what I want to do?
If reading the final value from disk or database is less computationally intensive, then store the value using the TYPO3 caching framework or by your own caching method of a static class and restore it in the getter of the virtual property. Doing it in the getter method public mixed getYourPropery() will give you the feature that the value is only get from the cache when you call it.
On the second call, just return the value you stored previously:
private $myValue = NULL;
public function getMyValue() {
if($this->myValue != NULL) return $this->myValue;
$this->myValue = "test";
return $this->myValue;
}

Yii Framework; How to check if a model attribute has a SPECIFIC validator?

I am making a custom ActiveForm method, but it requires the model to have a certain custom validator attached the the attribute that is being passed through (otherwise who knows what will happen!?)
My question is simply... is there a way to run this check in the code that is reliable?
I don't want to add the validator at runtime. That would create confusion and possibly let someone use this type of field where it ought not be used.
So I want to say something like:
if( model NOT HAVE validationMethod ON property)
throw Exception;
I'm also not sure why you want to do this, but in addition to viewing the rules array you can do:
$model->getValidators($attribute)
to check which validators are active for a particular attribute (or all attributes, if the arg is null. (I'm assuming $attribute = property in your example.)
This will return all the validator objects that are active for the current scenario and you can check if a predefined or custom class exists. It also gets you a bit more info than just the rules array (i.e., the properties of the validator class).

Does symfony have a built-in method for comparing tainted values to the original?

I am using symfony 1.4 with Doctrine. I have built a form which uses a table that has the Versionable behaviour. As expected, Versionable creates a new version of the row every time the form is submitted and saved. My problem is that I would like to prevent it doing so if the actual values submitted are not any different from the original values put into the form via the edit action.
I know that I can do this with javascript relatively easily. I'm just curious as to whether symfony or Doctrine have this functionality already, and how it is used if so. It just seems like something that symfony would have a method for, which could be checked right before $form->save() is called. Am I dreaming or perhaps missing something obvious?
You can use the DoctrineRecord::getModified() function which returns an array of the modified fields and associated values from an overridden save() function or in a listener (preSave would be the best I guess).
If the new values are not any different, you can bypass the actual call to save(), so no new version is created.
The comment for the save() method of the Doctrine_Record is
/**
* applies the changes made to this object into database
* this method is smart enough to know if any changes are made
* and whether to use INSERT or UPDATE statement
*
* this method also saves the related components
*
* #param Doctrine_Connection $conn optional connection parameter
* #throws Exception if record is not valid and validation is active
* #return void
*/
so first, you should check whether it does not already work.
If not, Doctrine_Record has a isModified() method you could use. If the bind() method of the form object modifies the object in the form which should at first contain the default values, then this method should return true.
If you don't want to override save() method or implement a listener as jaudette suggested you can instead stay with form binding:
$form->bind($values);
if ($form->isValid()) {
$form->updateObject();
$changes = $form->getObject()->getModified();
// save to database if desired
$form->save();
}
The object will not be saved to database by calling $form->updateObject(), but the actual php object is changed.
Also note that you might have to call getModified() on each related object if you have embedded subforms.

Odd problem with ListBox.DataSource

I'm writing a Windows application and using a Listbox control. I'm developing with Visual Studio C# 2008 Express Edition.
I've got a data object that looks something like this
public class RootObject
{
public List<SubObject> MySubObjects{ get; set;}
}
I've got a ListBox on my form, and also a property "MyRootObject" which, obviously, holds a RootObject. When the control is initialized, I set:
_listBox.DataSource = MyRootObject.MySubObjects;
Now, when the form loads, I debug and see that the DataSource is being set correctly. But nothing is displayed. I've overridden SubObject's ToString() method and it's not even being called. I tried setting _listBox.DisplayMember to a property of SubObject just to see if there was some problem there, but still nothing. I tried calling _listBox.Update() and _listBox.Refresh() after setting the DataSource, but still no love. The DataSource has all the data... it's just refusing to display it.
So while debugging, I wondered WTF and I decided to just do
_listBox.DataSource = new List<SubObject>{ new SubObject(), new SubObject() };
Sure enough, this worked, and I see two things listed in my listbox.
So then, really curious, I decided to try copying the list of objects and putting that in the listbox, like so:
_listBox.DataSource = MyRootObject.MySubObjects.ToArray();
This works! And it's a workaround to my problem for now... but a very annoying one. Does anyone know why I need to basically copy the list of objects like this to get it to work, rather than just setting the _listBox.DataSource = MyRootObject.MySubObjects; ? Again, the DataSource has all the right data either way after setting it... it's just when it's copied data, it actually displays, and when it's not, it's not displayed.
((CurrencyManager)_listBox.BindingContext[_listBox.DataSource]).Refresh();
Sux0r I know, but this works.
(originally found answer here)
Off the top of my head, this is because the ListBox.DataSource property must contain something that implements the IList interface. Your generic List<SubObject> does not implement IList; it implements IList<T> (in the System.Collections.Generic namespace). Array objects, on the other hand do inherit from IList, so handing the data in via that kind of object works.
You could try pulling an Enumerator (which also implements IList) out of your List<SubObject> object and plug that in. If it works, then the issue I've described is your problem. If it doesn't, then I'm talking out of my hat.
If this is indeed the issue, I am surprised that shoving in an unsupported object doesn't throw an exception.
so far that i know, whenever you want to set a collection to a
[ComboBox,ListBox].DataSource
you have to set the DisplayMember and ValueMember. DisplayMember and ValueMember are filled with the property name of the Class in the collection that is assigned to the listbox/combobox. Ex.
//Populate the data
RootObject root = new RootObject();
root.MySubObjects.Add(new SubObject("1", "data 1"));
root.MySubObjects.Add(new SubObject("2", "data 2"));
//Assign data to the data source
_listBox.DisplayMember = "DisplayProperty";
_listBox.ValueMember = "ValueProperty";
_listBox.DataSource = root.MySubObjects;
root.MySubObjects returns List of SubObject, and SubObject has to have properties called DisplayProperty and ValueProperty, ex.
public class RootObject
{
public List<SubObject> MySubObjects { get; set; }
}
public class SubObject
{
public string ValueProperty { get; set; }
public string DisplayProperty { get; set; }
}
I think you have to call Bind method after assigning to the list box data source
something like _listBox.DataSource.bind()
and you will have your listbox disappeared
you could try and use a BindingSource
( http://msdn.microsoft.com/en-us/library/system.windows.forms.bindingsource.aspx )
inbetween the Listbox and your collection. Bindingsources handles a bunch of stuff and also includes Suspend/ResumeBinding properies that can be useful when updating the list
you could also try out wpf as its databinding is far superior to that of winforms :) but maybe thats not possible in your case
I believe you need to call _listbox.DataBind(); after assigning the datasource.
However, I've never used a property as a datasource before, I've only used methods. Have you tried changing your property to a method to see if that's the problem?
You could try
_listBox.DataSource = new BindingList<SubObject> (MyRootObject.MySubObjects);
instead. BindingList implements some more interfaces than List, which are essential for DataBinding.
I have a special rule for problems like this that I always try to remember before wasting an entire day hammering on it (believe me, I've spent many days hammering!). The rule is: when system behavior is really strange, the underlying cause must be very stupid. As intelligent programmers, we have a tendancy to search for esoteric causes or bugs in framework code to explain our problems. Sometimes the answer is that we were in a hurry and made a careless mistake that we haven't yet caught.
To quote Sherlock Holmes, "when you've removed the impossible, then whatever remains, no matter how improbable, must be the truth". In this case, the improbable truth is that the MySubObjects property of MyRoot object is null.