[Smtk-developers] Proposed change to Attribute and Item Definitions

[John Tourtellott]

With regard to Label, you could still support it "inline" with the
definition, and allow the View to override it. (And in turn, allow a
workflow spec to override a view-specified Label, I suppose.) However, I'm
not sure I like this, since it is the inverse of the standard
css-inheritance paradigm. If we want to keep it simple, I would move it to
the view, even though I know I'll complain about it later :)

As for workflows overriding default values:

   - I don't foresee multiple/different workflows sharing the same
   attribute definitions, but maybe my thinking is too limited here.
   - If there are use-cases for that (different workflows using variations
   of the same definitions), then we might want the workflows to override
   other definition characteristics in addition to the default value.




On Wed, Nov 23, 2016 at 3:03 PM, David Thompson <david.thompson at kitware.com>
wrote:

> > ... There is one possible change I would like to propose and wanted to
> get your feedback on concerning how attribute definitions and item
> definitions are currently defined. ...  Note that how the information is to
> be represented in a GUI is (for the most part) not part of these classes
> but is represented in the Views.  The one exception are the Labels.  They
> represent the alternative way of displaying the "type" information of the
> attribute definition and the "name" information of the item definition.
> >
> > Since in 5.0, the GUI generation will support specifying where items
> should be placed within a View's  widgets that are  rendering the
> information, I was wondering if moving the label information into View
> structure would make more sense.
>
> I agree that labels belong with the view, not the items/attributes.
>
> > It would allow workflows to customize how the type and name info is
> displayed (as well as allowing for localization).
> >
> > Along those lines I was wondering if we should support allowing the
> Workflow the ability to "override" the default values of Items since (based
> on the assumption that a default values may be workflow specific).
>
> That seems reasonable.
>
> > Happy Thanksgiving!
>
> Many happy returns of the morrow!
>
>         David
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20161123/014b29da/attachment.html>