Move the logic of dynamic update in the view

[balai]

i noticed that the dynamic update that regards the child variants does not work in any other view than the category and the productdetails.

More accurately the logic that define the jdynupdate resides inside the layouts.
file: components/com_virtuemart/sublayouts/customfield.php

Code Select Expand

if(VmConfig::get ('jdynupdate', TRUE)){
$view = vRequest::getCmd('view','productdetails');
if($view == 'productdetails' or ($customfield->browseajax and $view == 'category')){
$attribs['data-dynamic-update'] = '1';
unset($attribs['reload']);
} else {
$view = 'productdetails';
}
}

That removes any flexibility for creating custom views, leaving all the logic inside the layout.
Anyone who needs that functionality in a custom view will have to hack that file.
I suggest adding that logic inside the view and passing just 1 variable that allows or not the dyn. update.

[Milbo]

Yeah and you have to adjust these also in the sublayout customfield.php. Your idea is simple said, but hard todo, when you provide a patch I am happy to add it.

[Studio 42]

Code Select Expand

if(VmConfig::get ('jdynupdate', TRUE)){
$view = vRequest::getCmd('view','productdetails');
if($view == 'productdetails' or ($customfield->browseajax and $view == 'category')){
$attribs['data-dynamic-update'] = '1';
unset($attribs['reload']);
} else {
$view = 'productdetails';
}
}
Your code logic is bad, if you want to do something generic then

Code Select Expand

else {
$view = 'productdetails';
}
Is bad.
But if you want rewrite this part, then do it javascript and not in any sublayouts.

A way to do it right is to have a context and not a view.
Why this ?
You have 3 possibles(or perhaps more) way to display products:
- product details
- products modules
- products in category.

So what are the problems here i  already faced off ?
If you display a products module in a product view. How Should this be handled ?
You cannot know if the module need category render or product detail render for the customfields.
Eg if you have a product displayed in the module and in the product details. But need another render for addtocart render, this is not possible currently because we have no context but only the view, you can only trick a little using some additional javascript or CSS.

It's why i added render for some year in the plugin plgVmOnViewCart,plgVmOnViewCartModule ... to solve this problem for cart module render.
But for product itself we shold have plgVmOnViewProductDetails , plgVmOnViewCategory, plgVmOnViewInModule for eg. But i think this is a big change so perhaps in VM 4 ?

[balai]

Studio24 i don't think that layouts functionality should be coupled on the extension it is called upon whatsoever.
There are developers who want their own views or others developed their own modules, etc.

Actually my suggestion  is to be completely agnostic on the view/component etc. it is called upon and work in any occasion if it gets the proper input.
The same principle applies for any layout. Joomla itself allows  a view to either use a layout from another component.

Max i ll check how easy it is to modify that.

[Studio 42]

balai,
i think you don't understand the problem.
YOu can have different render part of the layout, if you don't know the context, you cannot use the right code.
Module is not rendered the same way as category list of product. So simply using the view as context is bad, because on calling plugins for eg. the context is unknow and you cannot change the HTML code or javascript if you don't know this 3 contexts:
-in product details
-in a module
-in the category list.
Of course you can use $attribs['data-dynamic-update'] = '1'; in some $view but this not solve all problems and perha
ps only yours.

I only added my message, because i think that perhaps some other solutions should be compared before changing it.

A possible solution is to add a class per context, eg class="vmmodule",class="vmcategory",class="vmdetails" because some don't want dynupate in the module but need it in the category and product details only and want in other case redirect to the product details.

Currently if you need this, you have to overide VM javascripts in the template and add all HTML changes.

[balai]

No i don't understand.
It's not the layout's responsibility to check the context neither to contain any logic.
if somebody wants to load a sublayout in a parent layout which is not ready for that, it's not the sublayout's responsibility to ensure integrity.

Though i agree that this should become more dynamic.

[Studio 42]

I try a more simple explain.
YOu have a product say "apple"
Now for this apple you need 2 render for customfields : one for the category and one for the module for same product.
The context in your case use view=category, so you don't know in the customfields how to handel it.
Of course on changing the sublayout, you can change some values, but not all.
Another simple example is the related products, you want perhaps not render some customfields the same way as in the product itself and it's hard to overide, you can only estimate with some trick, that you need to render related and not the last product module for eg.

[balai]

But the solution i am suggesting solves exactly that.
The sublayout will be called 2 separate times 1 by the module and 1 by the category.
Each time different variables will be passed concerning the ajax update functionality.

In short what i am suggesting is that a layout should work no matter how many times is called in the same page, no matter from where it is called.
It should always work based on the input and generate the appropriate output.

Anyway i ll check the code to see how easy is that.

[Studio 42]

So perhaps, i don't understand how your code changes handel it. Because i don't know how your value should change when you call it 2 times ?

[Milbo]

But the solution i am suggesting solves exactly that.
The sublayout will be called 2 separate times 1 by the module and 1 by the category.
Each time different variables will be passed concerning the ajax update functionality.

In short what i am suggesting is that a layout should work no matter how many times is called in the same page, no matter from where it is called.
It should always work based on the input and generate the appropriate output.

Anyway i ll check the code to see how easy is that.

I agree 100%, Balai

I suggest adding that logic inside the view and passing just 1 variable that allows or not the dyn. update.

Actually it should be a kind of snippet, you could also provide it as sublayout, so it can be called from anywhere. It is not so simpel. But maybe,... we just need to move this code

Code Select Expand


if(VmConfig::get ('jdynupdate', TRUE)){
$view = vRequest::getCmd('view','productdetails');
if($view == 'productdetails' or ($customfield->browseajax and $view == 'category')){
$attribs['data-dynamic-update'] = '1';
unset($attribs['reload']);
} else {
$view = 'productdetails';
}
}

Just outside of customfield.php and maybe just as property of the VmView (JView). So the logic could be in the view.html.php and be overriden within  a layout.

Hmmm but for modules we need it without any view. We could use vmJsApi::jDynUpdate.

[Studio 42]

What i think is changin for eg.
   static function renderCustomfieldsFE(&$product,&$customfields,$virtuemart_category_id){
to
   static function renderCustomfieldsFE(&$product,&$customfields,$virtuemart_category_id,$context ='product'){
But currently the returned value is used in all layouts, so you can only render the same way all because this have no instance or context.
The dynupdate is one problem, but not the only one. It's wy i say this need some changes in the logic to do it more flexible and not only change a line for one specific case.