Title logic is not used with format

Description

Hi,

Steps to reproduce :

Log in System and put this title logic in the 'Expense Report' window : @C_BPartner_ID<C_BPartner.Name>@ @DateReport<dd/MM/yyyy>@

It should display the BPartner name and the date of the report with a specific format.

It works well in the recent items, but the window name remains as 'Expense report'. If just write @DateReport@, the date will appears but not formatted.

Regards,

Nicolas

Environment

None

Attachments

2

Activity

Show:

Carlos Ruiz August 31, 2015 at 11:13 AM

Solved with

Nicolas Micoud January 28, 2015 at 5:59 PM

IRC

[18:37] <nmicoud> CarlosRuiz : do you have any idea for a lighter approach ? i though about something like a list of values (reading the title logic) which will be stored, and if one of these value is updated, then we could create PO and get the new value. But 1st, not sure is a good idea. And 2nd, no idea for doing it
[18:38] <@CarlosRuiz> maybe you can try to implement formatting on Env.parseContext
[18:39] <nmicoud> already try that. and need PO
[18:39] <@CarlosRuiz> I tried and got stuck because Env.parseContext manages Strings - maybe you could discover the datatype of the column and use number / date or messageformat according to the datatype
[18:41] <nmicoud> hum...
[18:41] <nmicoud> will try this
[18:44] <@CarlosRuiz> another possibility could be
[18:44] <@CarlosRuiz> over the patch we're working - restrict the DataStatusEvents where the getPO is called
[18:45] <@CarlosRuiz> at this moment is called every time - but maybe we can call it just when opening the window - navigating and saving - one time per each - I see sometimes the DataStatusEvent is passed twice on some cases
[18:46] <nmicoud> and what about adding a new event "refresh window title", which could be called only when a title logic is defined and after previous, next, save ?
[18:47] <@CarlosRuiz> also noticed that Env.parseVariable manages format, but not default - and parseContext manages default but not format - it would be good to unify both approaches
[18:48] <@CarlosRuiz> it could be possible to manage in both cases @variable<format>:default@
[18:48] <nmicoud> yes, seems necessary
[18:48] <@CarlosRuiz> but would need to solve the datatype resolution on Env.parseContext - not easy as you just have the WindowNo
[18:50] <nmicoud> and a new syntax @variable<format><datatype>:default@ ?
[18:51] <@CarlosRuiz> ah - that sounds interesting
[18:52] <nmicoud> ugly, but it should work
[18:52] <@CarlosRuiz> easier and it will avoid the cost of resolving the datatype from dictionary
[18:53] <nmicoud> yep
[18:53] <@CarlosRuiz> I think it can be good to implement a variable resolver - that parses such thing (variable/format/datatype/default) and we call it from both parseContext and parseVariable
[18:54] <@CarlosRuiz> that will solve your issue too, right - no need for the PO for the title logic if we implement such thing

Carlos Ruiz January 28, 2015 at 5:32 PM

, I found a simpler patch with the same results, attached as IDEMPIERE-2224_CR.patch

But, my concern about this (same on your patch) is that it's too expensive, it's creating a PO object on any DataStatusEvent, and there are many.
If you set a breakpoint on GridTable.getPO you'll see how many PO objects are created on each event.

IMHO this cost is prohibitive and we would need to find a lighter approach.

Nicolas Micoud January 23, 2015 at 9:54 AM

Hi,

With this patch, you can define a title logic like @DocumentNo@ - @C_BPartner_ID<C_BPartner.Name>@ - @DateAcct<dd/MM/yyyy>@
And it will show DocumentNo, BPName and Date Acct in the desired format

Regards,

Nicolas

Fixed

Details

Assignee

Reporter

Labels

Priority

Created October 3, 2014 at 8:09 AM
Updated November 4, 2015 at 1:18 AM
Resolved August 31, 2015 at 11:13 AM