Appearence of the product field on product template form view

[Udo Spallek]

Hi,

the products field in model product.template[1] has per default a
hard coded::

mode="form,tree"

which displays the first product in a one2many form instead of the
usual list.
This default greatly helps to ease the understanding of product (aka
variant) and templates for setups using simple products without
variants.

But for setups using variants, it seems better to have a::

mode="tree,form"

which shows all products (variants) in a list of the product template
form.

I think about if it is a good general pattern for the appearance of a
one2many field in a form view:

* if it has more than one entry, show initially a list
* otherwise show initially a form

What do you think? For product and variant it would fit perfect IMHO,
since even if a setup uses variants, there can also be products without.

As the view_attribute[2] is already used to set *spell* and *state*
PYSON encoded conditions for attributes defined in the XML, I tried to
implement on this base.

But the following code (in version 4.0), but it doesn't work,
the view_attribute[2] does not *dynamically* set the
*mode*[3] attribute::


class Template:
__metaclass__ = PoolMeta
__name__ = "product.template"


@classmethod
def view_attributes(cls):
res = super(Template, cls).view_attributes()

res.append((
"/form/notebook/page[@id='general']/field[@name='products']",
'mode',
If(Greater(Len(Eval('products')), 1),
'tree,form', 'form,tree')
))
return res

Are there any ideas how it could work? What is missing?

TIA and regards
Udo Spallek

[1]
http://hg.tryton.org/modules/product/file/tip/view/template_form.xml#l29
[2]
http://doc.tryton.org/4.8/trytond/doc/ref/models/models.html?highlight=view_attribute#trytond.model.ModelView.view_attributes
[3] http://doc.tryton.org/4.8/trytond/doc/topics/views/index.html#field
--
virtual things
Preisler & Spallek GbR

Windeckstr. 77
81375 München

Tel: +49 (89) 710 481 55
in...@virtual-things.biz
https://www.virtual-things.biz

[Cédric Krier]

On 2018-04-24 17:53, Udo Spallek wrote:
> But the following code (in version 4.0), but it doesn't work,
> the view_attribute[2] does not *dynamically* set the
> *mode*[3] attribute::
>
>
> class Template:
> __metaclass__ = PoolMeta
> __name__ = "product.template"
>
>
> @classmethod
> def view_attributes(cls):
> res = super(Template, cls).view_attributes()
>
> res.append((
> "/form/notebook/page[@id='general']/field[@name='products']",
> 'mode',
> If(Greater(Len(Eval('products')), 1),
> 'tree,form', 'form,tree')
> ))
> return res
>
> Are there any ideas how it could work? What is missing?

It can not work because clients build first the view before bind it with
record values.

I think it will be better to have a configuration option that defines if
the company is working with variants or not. This configuration will be
used to set a proper mode.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Udo Spallek]

Wed, 25 Apr 2018 09:40:58 +0200
Cédric Krier <cedric...@b2ck.com>:

>On 2018-04-24 17:53, Udo Spallek wrote:
>It can not work because clients build first the view before bind it
>with record values.

Thank you for the explanation.

>I think it will be better to have a configuration option that defines
>if the company is working with variants or not. This configuration
>will be used to set a proper mode.

I thought about a configuration, too. IMHO a configuration has
limitations, as it is company-wide and not product specific:

* Even when using variants in a setup, there can also be other
products which are not variants.
* When using variants it can be useful to have the product (variant)
form view shown on new product templates, just for quick encoding.

But I found another solution. I put two products fields in the
view. There is one for mode="tree,form" and another for
mode="form,tree", each of them surrounded by a group with a separate
id::

<xpath
expr="/form/notebook/page[@id='general']/field[@name='products']"
position="replace">
<group id="products" colspan="2" col="1" yexpand="1" yfill="1">
<group id="products-tree" yexpand="1" yfill="1">
<field name="products" mode="tree,form"
view_ids="product.product_view_tree_simple,product.product_view_form_simple"/>
</group>
<group id="products-form" yexpand="1" yfill="1">
<field name="products" mode="form,tree"
view_ids="product.product_view_form_simple,product.product_view_tree_simple"/>
</group>
</group>
</xpath>

(Maybe it can be done simpler with less use of groups)

And now each group can be switched by view attributes::

class Template:
__metaclass__ = PoolMeta
__name__ = "product.template"

@classmethod
def view_attributes(cls):
res = super(Template, cls).view_attributes()

res.append((

"//group[@id='products-form']",
'states',
{'invisible': Greater(Len(Eval('products')), 1)},
))
res.append((
"//group[@id='products-tree']",
'states',
{'invisible': Less(Len(Eval('products')), 2)},
))
return res

For me it is the perfect solution:

if the Variants have more than one record, it is shown as a list
if the Variants have less than two records, it is shown as a form

Is it an interesting enhancement of the product module?

Regards Udo

[Cédric Krier]

On 2018-04-25 14:07, Udo Spallek wrote:
> For me it is the perfect solution:
>
> if the Variants have more than one record, it is shown as a list
> if the Variants have less than two records, it is shown as a form
>
> Is it an interesting enhancement of the product module?

I do not think so because the behaviour is strange when user adds a
second variant. The field on which the second variant is added become
invisible.

[Udo Spallek]

Am Mittwoch, 25. April 2018 16:05:05 UTC+2 schrieb Cédric Krier:
> On 2018-04-25 14:07, Udo Spallek wrote:
> > For me it is the perfect solution:
> > if the Variants have more than one record, it is shown as a list
> > if the Variants have less than two records, it is shown as a form
> > Is it an interesting enhancement of the product module?
> I do not think so because the behaviour is strange when user adds a
> second variant. The field on which the second variant is added become
> invisible.

You are correct, it does not work when adding a second variant in the
variants form view. What a pity, it looked promising.
Thanks a lot for your feedback!