I just came accros a variable defined as ->with('index',$index) and I was wandering, is there a difference between this format and this one I usually use :
->withIndex($index)?
If yes, which one should be promote ?
The only difference is that with() can accept an array with variables, for example ->with(['index' => $index]); and by ->withParamName(); you pass only one variable. Behind the scenes Laravel calls a magic method and transforms the withIndex($index) to with('index',$index), so you can use either. Just make sure you don't use a reserved method name like withHeaders, withCookie, withInput, etc.
Related
I try to use methods in https://laravel.com/docs/9.x/helpers instead of old php functions I used for many
year. I did not find any laravel method like in_array.
I tried to use Str::contains , but failed it. Seems different ?
So any replacement of in_array ?
Thanks in advance!
Using in_array seems perfectly acceptable and if it gets the job done for you and is not causing issues then stick with it.
That aside, there is the Arr::has() helper, or alternatively, you could convert your array to a collection and then use the contains() method, however that just uses in_array behind the scenes anyway.
Since Laravel 5.7, the majority of global Helper functions (specifically the ones related with "Arrays & Objects" and "Strings") are now based on Facades (using Illuminate\Support\Str and Illuminate\Support\Arr classes) instead of being defined as "normal" helper functions, as they were before 5.7 (see difference with previous Laravel 5.6 docs).
Does it really mean that we are not allowed to use them anymore directly within our Blade views? If we do, they have to be obviously prefixed with its full path in any case, resulting in a dirtier Blade views...
Is not this change counter-productive?
EDIT:
Made some googling and found this article that confirms the situation.
Also, I have seen that in 5.8.17 it is planned to include Arr and Str aliases by default within config/app.php (link).
In the meanwhile, I proceed to register Arr and Str aliases in my config/app.php config file to avoid the full path issue.
Thanks
I'm working with a component bitrix:catalog (which is standard one) and faced an issue. I want to add some extra GET parameters to switch view mode. I think there is no need to rewrite whole component to make such switcher, so I added extra keys in result_modifier in a way similar to:
$this->__component->arResultCacheKeys = array_merge($this->__component->arResultCacheKeys, array('key1', "key2"));
Earlier in the same result_modifier I perform adding those extra keys in $arResult['key1'] etc. They seem to be correctly saved, but only for current inquiry such as ?view=list or view=card, that means only one variable value is saved and it does not react on changing of GET parameter. Is there simple and correct way to make that component to cache and to output data based on GET variable? The only idea which came to my mind is to rewrite component by adding extra parameter and checking of GET, but I think there must more simple and correct solution to make in via template. Human Readable Links are turned on. And I want to have auto-cash being turned on as well. If I turn it off it starts working as planned.
One of possible solutions is to rewrite it cache by SetTemplateCachedData but it still seems to me rough and incorrect way for such simple task.
Bitrix masters please help me to find correct solution, google can't help at the moment.
If you use standard bitrix:catalog component, you may be use standart bitrix:catalog.section. In that component.php used standart component cache.
That means you can describe additional parametr in you custom .parameters.php, and set it in bitrix:catalog.section params.
Standart component cache set cacheId based on arParams.
So you include component should look like this:
$APPLICATION->IncludeComponent(
"bitrix:catalog.section",
"",
array(
"IBLOCK_TYPE" => $arParams["IBLOCK_TYPE"],
"IBLOCK_ID" => $arParams["IBLOCK_ID"],
"ELEMENT_SORT_FIELD" => $arParams["ELEMENT_SORT_FIELD"],
"ELEMENT_SORT_ORDER" => $arParams["ELEMENT_SORT_ORDER"],
....
....
"NEW_ADDITIONAL_GET_PARAMS"=> $_GET['view']
),
$component
);
Of course better way somethink like
"NEW_ADDITIONAL_GET_PARAMS"=> (in_array($_GET['view'],array('list','card'))?$_GET['view']:'list')
But may be you need just set right catalog params: SEF_MODE SEF_FOLDER SEF_URL_TEMPLATES
I add a virtual column, then I filter it using "having". When I need to filter by one value, all works fine, but I also need to filter by "not null". having expects only 3 arguments, including the clause, the value and the binding type, is there any way to pass in a criteria?
$Sharings->having("TotalSharing = ?",2, \PDO::PARAM_INT);
Or do I have to add a new virtual column who has as value what I need directly?
Thanks a lot in advance!
Gioia
Ok, was actually a lot easier then I thought, I just used:
$Sharings->having("TotalSharing > ?",0, \PDO::PARAM_INT);
So I didn't need to use a Criteria object, silly of me not to think about this, just so used to use filterBy...
in some tutorials they tell you to set up an attribute like this:
$manager = Doctrine_Manager::getInstance();
Doctrine_Manager::getInstance()->setAttribute(
Doctrine::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
and in the documentation it shows you this:
$manager = Doctrine_Manager::getInstance();
$manager->setAttribute(
Doctrine::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
i wonder which one i should use? isn't it the latter one? cause how can you set an attribute to a singleton class in the first one? isn't the second one more correct?
Do you even understand the code you're looking at?
The first code is "wrong". First it assigns Doctrine_Manager object $managger, and then this variable is not used.
If you want to do more than one thing on Doctrine_Manager then it's natural to get assign this reference to something that won't mess up your code. If you want to do just one thing there is no need to use extra variable, in other words:
Doctrine_Manger::getInstance()->setAttribte(...);
or
$manager = Doctrine_Manger::getInstance();
$manager->setAttribute(...);
$manager->setAttribute(...);
$manager->doSth();
$manager->blahblahblah();