LinkItem.showValue()

[yavery]

Hi,

Again, with my migration from 8.2p to 8.3p issues ... This time, it's related to another custom FormItem
we have that's based on a LinkItem ... So we have an AttachmentManagerItem which displays an hyperlink
but that also holds data (attachments information).

We used to have this component setup using our getValue()/setValue() approach which we learned wasn't
right (should use showValue()/storeValue()), so we changed it to use the later, but somehow the showValue()
is never called on that FormItem ...

I tried implementing hasDataElement() to have it force the return of true. I also trie canEdit : true, but none
of those seem to trigger showValue() being called on that LinkItem derived class.

Is there anything else that we should be doing ?

Thanks,

[yavery]

Looks like showValue() is specific to CanvasItem derived classes. So what would be the approach
for other field types that require data binding ... Would it be as we were doing before, which is
using the getValue()/setValue() approach ?

Thanks,

[Isomorphic]

showValue() is indeed specific to CanvasItem.

setValue() / getValue() overrides have never been a documented way to create a custom FormItem - the APIs would need lengthy explanations of value lifecycles and various other APIs you might need to override in order for a developer to know enough to override them.

We don't know what your item does or how it's implemented so right now we can't recommend an approach.

[yavery]

It's an hyperlink FormItem (with showPickerIcon : true) that visually displays as its
link title, the following wording:

"Attachments ({N})"

Where {N} is the number of attachments the item currently holds. When the hyperlink
gets clicked, the showPicker() method will open up a popup window that contains the
actual list of attachments associated. The user can add or remove attachments and the
hyperlink title gets updated accordingly with the new count.

The LinkItem is added to a DynamicForm and its data gets loaded/saved as a nested XML
element (collection), part of the main XML payload for the underlying screen in which it is
embedded.

When adding or removing attachments, the attachment's binary data gets uploaded to the
server on a standalone basis (not thru the underlying DynamicForm).

Whenever the form containing this LinkItem gets saved, it also saves the data held
by the LinkItem (not the attachment binary per say but the actual list of attachment
details such as blob key, file name, etc).

We had this initially (8.2p) setup using the setValue() / getValue() approach but this no
longer works in 8.3p, so I'm looking for an alternate way that would not require a complete
overhaul of my existing code base (ideally) ... Something similar to the showValue() / storeValue()
approach proposed for CanvasItem in a prior forum post would be great ...

Thanks,

[Isomorphic]

In general with a pop-up picker, once you've done your interaction with the user, use a call to setValue() to update the stored value.

As far as something like the formatting you mention ("Attachments ({N})"), you'd generally do that with a formatValue() implementation, and the current value is passed to you. If you are implementing anything else that needs the value, calling item.getValue() is the way to get it.

This approach - and in general the requirements you specify - involve *using* getValue()/setValue() but not *overriding* getValue()/setValue() - it's the latter that's a problem.

Let us know if this leaves any kind of gap in meeting your requirements.

[yavery]

Thanks. That worked ...

A combination of calling setValue() and removing my implementations for getValue()/setValue()
and instead implementing formatValue() did the trick ... Code is also a lot simpler too ... Things
too complicated are often a sign that we're doing things wrong.

Thanks again!

[Isomorphic]

Good to hear this is working for you.
One note on this. Calling "setValue()" will not fire any explicitly defined change or changed handler on the item.
We've decided to add support for calling a method "storeValue(<new value>)" on any custom form item in order to both fire change handlers and store out the new value, making it easier to write entirely custom items in the future.
This will be available in SC 9.1d / SGWT 4.1d branches only, starting with the next nightly build.

Note that you should be able to continue to use your existing approach - there is no need to switch to calling 'storeValue()' (rather than 'setValue()') whenever you upgrade to 9.1 or above, unless you want to take advantage of having the change / changed notification methods fire when the user interacts with your item to change the value.

Regards
Isomorphic Software

[yavery]

Thanks,

I'll know for when we migrate to 9.x, whenever that is ...