fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Woodlock <keithwoodl...@gmail.com>
Subject Re: Expression language to extend datatables
Date Fri, 26 Feb 2016 12:50:48 GMT
Hi Sander,

>> Ultimately the goal is to get the calculated data stored in the actual
>> datatable so that it can be used in reports, custom loan checks etc.

Yes so if we keep the scope at just this basic need to support
'derived/calculated fields' that are stored on table its fairly
straight-forward to add this capability to datatables on the backend. Add
some metadata table to support adding in some 'expression' or 'rule' that
can be executed at a time you expect it (before, after, create, update)

In terms of implementation I would say that the spring expression language
could be a good fit if you just want to be able to support expressions (
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/expressions.html)
and I do think that Javascript support through Nashhorn is another way to
go if anything more complicated than expressions is required.

>> - When pulling the template API for a certain datatable the configured
>> expression will come back as metadata (same way field types or
>> mandatory/non-mandatory is given back). This would allow any consumer of
>> that API to also implement the same expression library in (for instance)
a
>> Web UI or (offline) Android app and give instant results in their UI.

If you want to replicate the 'expression' calculation on the UI this one is
way you can go, if so they you need to return the expression as part of API
and then clients need to build in support for executing/understanding this
expression.

The other way to go would be to build in support to datatables api to
'process calculation requests' i.e let the UI/form post the data to the
backend api (just for calculation/rules checking, not for saving) POST
/datatables/table_with_calculation/1/12?calculation=true (with body of
parameters in form) and let the api support do whatever calculations are
required and then return the 'response' which the ui would just render.

Keith.

On Wed, Feb 24, 2016 at 3:19 PM, Sander van der Heyden <
sandervanderheyden@musoni.eu> wrote:

> Hi Keith,
>
> Hope you are well?! Long time!!
>
> Ultimately the goal is to get the calculated data stored in the actual
> datatable so that it can be used in reports, custom loan checks etc. So
> therefore what I would expect to happen as an API consumer is:
> - When pulling the template API for a certain datatable the configured
> expression will come back as metadata (same way field types or
> mandatory/non-mandatory is given back). This would allow any consumer of
> that API to also implement the same expression library in (for instance) a
> Web UI or (offline) Android app and give instant results in their UI.
> - When saving the backend will expect this field to be empty (not
> submitted) and will evaluate the expression.
> - Any time the record is updated the expression will be evaluated again.
> - Potentially adding an endpoint/ability to just get back the generated
> results for a table, without storing, to allow online consumers to work
> with the results without implementing the same expression lib.
>
> As there is already quite some work done around datatables by conflux and
> musoni in extending the features, adding metadata to it, this seems like a
> logical next step, although we can also debate whether it might be a point
> where the datatables would be 'forked' into a separate endpoint more
> focussed on user-forms.
>
> So from our end the datatable>rule relationship would mainly be that the
> datatable metadata contains a user-defined expression which can be
> maintained using the CRUD on the datatables endpoint itself and is stored
> in the metadata as a (tiny)text field.
>
> All in all, this would be extending datatables quite significantly and
> therefore I think it would be good to agree on the need for doing that as
> part of a 'fork' of the datatables endpoint into a separate 'user-forms'
> endpoint, also keeping in mind other requests we've got on this such as:
> - conditional fields (Field B is only required if Field A has a value)
> - field types such as GPS or a document upload
>
> And obviously this also comes with a sensible decision on which expression
> library to use, and other ideas around the various items listed above.
>
> So very curious to hear some thoughts. In terms of timelines we'll be
> looking to pick most if this up in Q2 .
>
> Sander
>
> On Wed, Feb 24, 2016 at 10:54 AM, Keith Woodlock <keithwoodlock@gmail.com>
> wrote:
>
> > Hi Sander,
> >
> > >> We've been using the datatables quite extensively with more and more
> of
> > our
> > >> clients, and have also been extending it a bit to make it more
> suitable
> > for
> > >> offline use on a tablet etc.
> >
> > Very good. Be interesting to hear more of what you did to support the
> > offline scenarios. I must take a look at the code area to see it.
> >
> > >> The next step now would be to derive some of the fields in a datatable
> > from
> > >> simple IF/ELSE statements or basic math formula's on other fields. For
> > >> example: The customer has entered a weekly income of 100 (field A)
> and a
> > >> weekly cost of 50 field (B) and we don't want a loan to take up more
> > than
> > >> 30% of his/her profits then in field C the formula would be (A-B)*30%
> =
> > 15.
> > >> This would then obviously be stored and recalculated upon edit (if
> > needed).
> >
> > Assuming that the datatables still just supports the CRUD methods over a
> > table, I suppose you are looking here to capture some rules onCreate or
> > onUpdate of the record in the 'table'.
> >
> > If you were ok with a 'Compile' time solution you could put in simple
> Java
> > code to 'handleOnUpdateDatatableRules' or 'handleOnCreateDatatableRules'
> -
> > That method might then use a naming convention based on the datatable
> name
> > in use and some reflection to trigger call to a method written in java
> that
> > contains your rules/logic.
> >
> > If you really wanted it to be runtime changable, then you would need to
> > support a datatable to rules type relationship. You would want to be able
> > to write in your rule is some scripting language. One possibility is to
> use
> > Javascript - you can invoke it using Nashorn (
> >
> http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html)
> >
> > regards,
> >
> > Keith
> >
> > On Wed, Feb 24, 2016 at 7:16 AM, Sander van der Heyden <
> > sandervanderheyden@musoni.eu> wrote:
> >
> > > Hi all,
> > >
> > > We've been using the datatables quite extensively with more and more of
> > our
> > > clients, and have also been extending it a bit to make it more suitable
> > for
> > > offline use on a tablet etc.
> > >
> > > The next step now would be to derive some of the fields in a datatable
> > from
> > > simple IF/ELSE statements or basic math formula's on other fields. For
> > > example: The customer has entered a weekly income of 100 (field A) and
> a
> > > weekly cost of 50 field (B) and we don't want a loan to take up more
> than
> > > 30% of his/her profits then in field C the formula would be (A-B)*30% =
> > 15.
> > > This would then obviously be stored and recalculated upon edit (if
> > needed).
> > >
> > > To implement this we can obviously already leverage the various
> metadata
> > > tables we have around datatables, but I was not sure which expression
> > > library would be most suitable. I've currently looked around and
> > wrote-off
> > > anything not suitable under the Apache license, or that has not had any
> > > contributions for a long time. This turned up Apache jEXL -
> > > http://commons.apache.org/proper/commons-jexl/. I was wondering if any
> > of
> > > you had any experiences with it or have alternatives that are better
> > > suited?
> > >
> > >
> > > Thanks,
> > > Sander
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message