Re: Questions about architecture

Hi,

Encolpe Degoute wrote:
> 4/
> Come back on visibility. What's visibility for a widget ?
> A widget rendering can be written in the output or not. => invisible state
> With MasterSelectWidget we can see another need: putting a css class and a
> javascript code to manage another visibility type.
> Then 'visible' option can be divide in four properties:
> - hidden_if: do we write then code
> - widget_mode: view, edit, search, but not invisible or hidden
> - css_class: hidden value or not
> - javascript: use to switch css_class for this widget or another widget
>   
Regarding this kind of need, why not using a class like with IVocabulary
(I think of the ATVocabularyManager case)

exemple :

    class IVisibility(Interface):
       def isVisibleInEditMode(self, field, instance):
          raise NotImplemented
       def isVisibleInViewMode(self, field, instance):
          raise NotImplemented
    ...

    visibility = ExprVisibility(viewExpr="object/isThisEnabled",
editExpr="object/isAnotherFeatureEnabled")

Next, there is already 'helper_css' and 'helper_js' which prove very
usefull.

Actually rendering templates lack css class="at-<type>" in either view
or edit mode, and would help with css visibility and end-user customization.
An englobing div with this property would fit well in 'base_edit' and
'base_view'.
The 'at-' prefix is to not clash with the content icon feature.

And then it remains a true problem with dynamic visibility in edit templates
that is partially solved by MasterSelectWidget + helper_js.

Regards

-- 
Alexandre Sauvé