Extending Column Callouts to execute always

[Jan Thielemann]

For some time now, i was wondering why callouts only get executed if there is a change in the field they belong to. Imagine the following example:

-You have a callout which depends on another field of the same tab (e. g. a custom field and the currency field on the order window). 

-You enter some value in your own field and your callout gets executed. 

-In your callout, you detect that the currency wasn't set yet and you return a message to the user

-The user sets the missing value and goes back to the field from which your callout got executed

-The user enters the same value again and leaves the field (but nothing happend since the callout only gets exectued if there is a change in the field)

-The DAU thinks everything is ok since he only knows that he has to enter something in the field and leave it 

-Now you have an inconsistency

I understand that executing a callout everytime the field is left can lead to cycles if you concatenate callouts with each other but here is my suggestion how we could fix that at least for the OSGi way (which is the best way anyway :)):

Extend IColumnCalloutFactory.getColumnCallouts() with a third parameter: "boolean executeAlways"

public interface IColumnCalloutFactory {

public IColumnCallout[] getColumnCallouts(String tableName, String columnName, boolean executeAlways);

}

What do you think? How would you handle my problem? Have you ever encountered something similar? 

Regards

Jan

[Jan Thielemann]

For the old classname approach, we could add a Y/N checkboy (default no) for execute callout always so that old functionallity would still work as expected

[Hiep Lq]

seem callout just for warning, set default,... help user more easy input data. not help user total. 

for consistency data, check it in before save or other place.

in your case, for simple, reset wrong data to old value.

so, after filter missing value, user must retyping value and callout recall.

--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/6839a208-498f-4aee-9142-8d3dc6885a2a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Lê Quý Hiệp
Email: hie...@hasuvimex.vn
Skype: admin.hasuvimex
Mobile: 0915277401

Company: Thanh Hoa Fishery Import - Export J.s.c  (Hasuvimex) DL 47

Add: Lot E, Le Mon Industrial Zone, Thanh Hoa, Vietnam

[Carlos Antonio Ruiz Gomez]

Jan, advice from Hiep is correct and indeed is a rule, all callout validations must be repeated on beforeSave (said in other words, you cannot trust on callouts for validations)

About your use case my advice would be that in step:

-In your callout, you detect that the currency wasn't set yet and you return a message to the user

the callout must clear the custom field


Anyways, your suggestion can be worthy for some special cases, would that mean that callout will be triggered by lostFocus event?
What if we call those new callouts maybe FocusCallout instead of adding the third parameter?
I would not mind being backward compatible with old callouts, if just the OSGi way supports this new notation I think is ok.


Regards,

Carlos Ruiz

On 24/03/14 11:45, Hiep Lq wrote:

[Jan Thielemann]

About your use case my advice would be that in step:
-In your callout, you detect that the currency wasn't set yet and you return a message to the user
the callout must clear the custom field

I think that would do the trick. I haven't thought about this before.  

Anyways, your suggestion can be worthy for some special cases, would that mean that callout will be triggered by lostFocus event?
What if we call those new callouts maybe FocusCallout instead of adding the third parameter?
I would not mind being backward compatible with old callouts, if just the OSGi way supports this new notation I think is ok.

That could also be a good idea. A second type of callout which always get executed when the field loses the focus no matter if it has changes in the field. I would vote for this. 

[Jan Thielemann]

I did it for now with resetting the field. If anybody tries do do the same, heres how i did it in my callout:

mTab.setValue(mField.getColumnName(), new BigDecimal(0));

Using the mField.setValue() methods didn't work so i had to use the mTab.setValue() method.