Jacopo Cappellato escribió:
> I think you are right; there is currently another issue about the
> formatting of numbers with decimals affecting the performFind service:
>
> https://issues.apache.org/jira/browse/OFBIZ-221
Thanks, maybe we could fix this too :)
>
>> Does anyone know the best way to workaround/fix this problem? Maybe
>> another suffix for the forms with the type of the field?
>>
>
> Or two new input parameters: local and timezone of the incoming data
AFAIK these data can be get from the service context.
>From the prepareField description:
// Strip the "_suffix" off of the parameter name and
// build a three-level map of values keyed by fieldRoot name,
// fld0 or fld1, and, then, "op" or "value"
// ie. id
// - fld0
// - op:like
// - value:abc
// - fld1 (if there is a range)
// - op:lessThan
// - value:55 (note: these two "flds" wouldn't really go
together)
// Also note that op/fld can be in any order. (eg.
id_fld1_equals or id_equals_fld1)
// Note that "normalizedFields" will contain values other than those
// Contained in the associated entity.
// Those extra fields will be ignored in the second half of this
method.
p.e. the form to search workEfforts has this kind of fields:
estimatedStartDate_fld0_value - estimatedStartDate_fld0_op -
estimatedStartDate_fld1_value
Of course, estimatedStartDate_fld? are dates and should be converted to
the server timezone/format, but prepareFind/prepareField/performFind do
not know about it
What I propose is adding another optional suffix which can be _date or
_number, so performFind can use it as a condition to convert these
fields from the localized/timezoned original data, so the fields will be:
estimatedStartDate_fld0_value_date - estimatedStartDate_fld0_op -
estimatedStartDate_fld1_value_date
WDYT?
Regards,
--
Daniel
