Re: 3 csets were pushed to core/commerce: Merge [email protected]:/var/bk/xaraya/c...

In article <[email protected]>, Marcel van der Boom 
<[email protected]> wrote:
>
>
>mikespub wrote:
>
>> I haven't dived into the exact use case for this "Hidden" status
>> yet, but somehow it feels in the wrong place there. After all
>> we already have a property type "Hidden" too, for those fields
>> you want to hide but keep functional - isn't that enough ?
>>
>I dont think so, the property has to be of type item id for dynamic 
>objects, so the type is set. The most frequent usecase is that there 
>are views and display screens of the object.
>By setting it to "display only"  that solves half the situation: 
>hiding it in the view screens, but it will still be visible in the 
>display screens. The 'hidden' status would solve that.
>
Ah - so it's the itemid that bothers you then ? Same here - but I was 
thinking of handling that in the input templates rather than in code
someday :-)

>I do agree however that the definition of the states (including the 
>hidden) is then not using one "rule" for division and may lead to 
>confusion.  I also think disable was already kind of confusing, but 
>that may be me.
>
>marcel
--> disabled on the object level vs. disabled on the GUI level are
not the same thing...

The status deals with which properties are assigned to the object
in the class constructor (and related methods), rather than how
they might be shown in templates afterwards, which is why this
"hidden" status feels uncomfortable here - it's in the wrong place
= way too deep within the class definition for something that should
only affect the display in input forms.

The current statuses are *meant* to affect everything within DD, which
is why they're so deep inside the class definition - the "hidden" status
seems to be another matter though. Unless I'm mistaken of course :-)

But I guess we can evaluate all that when checking which
commerce changes will be merged into core/stable someday...

Mike.