On 17/04/2019 10:07, Taher Alkhateeb wrote:
I see, well for one thing, maybe we should rename integer. It feels
like a programmer word and perhaps does not imply the business value.
Where do we format things as integer for example?
I agree

Also if I may suggest, the commit should maybe have some examples of
where each type of formatting is used. And some documentation is
necessary to make use of that formatting. Throwing this stuff into the
code base without background information might not help people adopt
these features perhaps?

It's also my vision. I will work on it and submit an other patch with more business logic

Nioclas


On Thu, Apr 11, 2019 at 10:30 PM Nicolas Malin <nicolas.ma...@nereide.fr> wrote:
Hi Taher,

I appreciated your return, in line

On 09/04/2019 22:46, Taher Alkhateeb wrote:
looks good. I'm not sure what's the difference between accounting and
default formats though? And why do we have Integer format?
I loaded some example to help mind projection, yes Integer isn't
logical, but accounting is different than default on accounting we
display (5.00) and for default -5.00

I would probably limit the types of formatting to percentage and
currency and quantity. Between those three you probably have all cases
covered no?
:) I think not, I think never. Where you see different technical
formating case, I see functional case where a displayed number could
have an importance to help end user to read. This reason I see a
difference between an "invoice number", "order number", "product number"
(and what product type exactly) so we can have a huge case that
displaying a number with a specific format can have an importance.

The main reason that I tried to found extensible system, I wonder about
how many type we need to implement as default to found a balance between
not so much for maintainability and enough to offer good example use.

    * accounting, default, percentage, of course
    * amount, quantity, I think
    * For other I'm open

Currency is different because the currencyUomId is needed, and currently
I didn't found how homogenize it

I have a last point, store the definition on properties is really
helpful to surcharge/extend by plugin but I don't like to use arthimetic
on accounting. I propose to store it on common/config/number.properties
and name properties ${type}-displaying-format. If you have some suggets
on it ! :)

Nicolas

On Fri, Apr 5, 2019 at 7:58 PM Nicolas Malin <nicolas.ma...@nereide.fr> wrote:
Hello

I would improve an idea present by Charles STELTZLEN on issue OFBIZ-7532 [1]

Currently when you display a number you have different possibility to
format it :
    * by ftl with <@ofbizAmount>
    * by widget with <display type="accounting-number"/>
    * or everywhere with UtilFormatOut.formatDecimalNumber(number,
template, locale)

Main problem, we haven't a simple solution to homogenize display
template number by purpose without check each case on source code.
A example, if you display your invoice amount on 3 digits and your order
amount on 6 digits, you can't use ofbizAmount or accounting-number so
you do raw call :
    * for invoice: UtilFormatOut.formatDecimalNumber(invoiceAmount,
'##0.000', locale)
    * for order: UtilFormatOut.formatDecimalNumber(invoiceAmount,
'##0.000000', locale)

on ftl
${Static["org.apache.ofbiz.base.util.UtilFormatOut"].formatDecimalNumber(invoiceAmount,
'##0.000', locale)}
on widget
       <display description="${groovy:
org.apache.ofbiz.base.util.UtilFormatOut.formatDecimalNumber(invoiceAmount,
'##0.000', locale)}/>

There is huge cases where we want different displaying template.

For homogenize all I propose to introduce each format template on
properties that would be use everywhere in ofbiz, example :

        format.properties
            invoice.format=##0.000
            order.format=##0.000000

on ftl
        <@ofbizAmount amount=invoice.amount format='invoice'/>
on widget
        <display type="number" format-type="invoice"/>

All displaying template pass through new util
*UtilFormatOut.formatNumber* as generic function to works with a format
type present on properties. With this idea, you can use on you specific
source code your own format and override standard ofbiz format.

I will suggest a patch on issue OFBIZ-7532 [1]

I thinks it's important feature to help customization so if you have a
suggest, your welcome :)

Cheers,
Nicolas

[1] https://issues.apache.org/jira/browse/OFBIZ-7532

--
logoNrd <https://nereide.fr/>
          Nicolas Malin
The apache way <http://theapacheway.com/> : *Charity* Apache’s mission
is providing software for the public good.
informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way
<http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/>

Reply via email to