custom field editors for Sedona slots

[Murat Egrikavuk]

The documentation (http://sedonadev.org/doc/niagara.html) indicates
two methods for changing the default field editor that Niagara AX uses
for a Sedona slot.
(a) using the Sedona slot facet 'fieldEditor"
(b) using <def> blocks within the module-include.xml file of a Niagara
module.
Both methods seem to achieve the same result, is this true and is
there a particular reason to prefer one over the other?

Method b seems advantageous in two ways: (i) it involves no coding on
the Sedona side, (ii) if the Niagara module is missing, the user still
gets a chance to view/modify the property value in its basic format.

On the other hand, method b would allow for two different fieldEditors
to be associated with the same Sedona component slot. It is unclear
how Workplace would select which fieldEditor to use in this case.

[Matthew]

Murat,

There are subtle, but important differences between the two methods.
One uses a facet, the other uses an Agent.

1) Facet: If a @fieldEditor facet is set on a property, it will
always be used over any def's in the module-include. This has nothing
to do with Sedona per-se, it is the behavior of the Property Sheet.
If no field editor facet is set for a slot, then the property sheet
"falls back" to looking for an Agent of type BWbFieldEditor. So if
you have both a @fieldEditor facet set AND a field editor agent <def/
>, the @fieldEditor facet will always win out on the property sheet.

2) Agents: Every type in Niagara can have multiple agents associated
with it. An agent just means that one BObject can do something with
another BObject. The primary use of an agent in the Sedona Workbench
is for presenting the set of Views on a Sedona Component. When you
right-click and select the "Views" menu, Workbench looks at the set of
Agents registered on that type and presents a list of all the agents
that are a BWbView. If you want a custom view on a Sedona component
type, then you *must* use a <def/> block to declare the agent in the
module-include.

So: If you explicitly want to set the field editor, and not allow it
to be overridden with a <def/> block, then you should use the
@fieldEditor facet.

Otherwise, you can just use <def/> blocks. However, as you said, you
cannot guarantee which field editor agent would be used if multiple
are declared for the same property. This is really only a problem for
field editors, since you can declare multiple views on the same type/
slot.

As a side not, there is a bug in the Sedona Workbench where the
@fieldEditor facet is not recognized on Sedona component types. It is
only recognized on property slots. The next build (1.0.47) of the
Sedona workbench will have a fix where you can declare a @fieldEditor
facet on a Sedona component type:

@fieldEditor="myModule:MyFooFE"
class Foo extends Component {}

Does this answer your question?

On Apr 6, 8:19 am, Murat Egrikavuk <murat.egrika...@ontrol.com.tr>
wrote:

[Murat Egrikavuk]

Yes, thank you. This leads me to conclude that it really doesn't
matter which method you use for typical cases. An example of my
"typical case" is the duration property in basic schedule which is an
int value representing minutes after midnight, but displayed/set in a
more friendly hh:mm format.
Just one bug report or feature request related to this : If a sedona
kit uses the @fieldEditor facet, but the referred module or field
editor is not present in the Niagara installation, the slot doesn't
display at all. I think it should fall back to a default primitive
editor.

Thanks again.

[Matthew]

Murat - That is a good suggestion. The code responsible for that
behavior is in the Property Sheet, which is part of the Niagara
Framework. I will forward this request to developers responsbile for
the Property Sheet to see what they think since the change impacts
more than just Sedona components/slots.

In the meantime, I will also consider enhancing the BSedonaComonent
code to check #agent defs and fieldEditor facets to verify the type
spec before accepting the value. That's something we can probalby
more easily do.

On Apr 6, 1:12 pm, Murat Egrikavuk <murat.egrika...@ontrol.com.tr>
wrote:

[Matthew]

I have added the @fieldEditor facet validation to the
BSedonaComponent. In the next build of the Sedona Workbench (1.0.47)
if the field editor facet is not resolvable to a type, or is not a
BWbFieldEditor, then the facet will be simply ignored. The field
editor will be the default primitive field editor.

> > Thanks again.- Hide quoted text -
>
> - Show quoted text -