Hi everyone,
a few points of view from my side:
We should not introduce regressions or remove functionality within new
features without dicussion. If someone needs something for his custom
projects and wants to bring that into the codebase, he should take the
responsibilty to assure that the above is considered. At least it should
be openly explained that the new solution does not support existing
functionality so that the community has enough data to decide if it can
be brought into the codebase.
That said, it should be considered to enhance the functionality of the
new datepicker. This would be necessary to be a valid replacement for
the existing one.
Else, this should not happen.
Best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 11.03.25 um 08:54 schrieb Florian Motteau:
Hi Jacques,
Le 11/03/2025 à 08:42, Jacques Le Roux a écrit :
Hi All,
With this effort, Florian put in the new date range picker without
changing existing date picker usage in OFBiz.
At https://issues.apache.org/jira/browse/OFBIZ-13209 now closed, I
asked him then
<<Before closing, why not using it to replace some (or all?)
current fields with date picker? Of course that would be another Jira.>>
He answered me
<<This is what I did for our project, we introduced it for a few
forms, and as a default for autofield forms on date fields (so we
have it in the
webtools). We could do that, we just have to keep in mind that
this field does not meet every possibilities allowed by date-find,
since I did not
implement the operator's choice (you must define a closed range,
you can't search for entities where date is greater than the chosen
one, or
entities where date is same day...). So we would need to define
where these drawbacks are acceptable, in relation to the gain in
terms of user
interface.>>
What do you think about that?
Also @Florian, why did you not implement the operator's choice? Is it
a technical issue, a lot of work, or simply you did not need it for
your project?
It was not a requirement for our use case (as a matter of fact the
operator brought confusion to our users in the first place), and it
would have raise some questions since the DRP library is not designed
to work with an additional operator. I thought about keeping the
operator but I would have had to decide how to handle it when the user
picks a date range ("before a date range" ? does it make sense in
terms of user experience ? not so sure :)) or add some logic to
prevent the combination of the operator and a date range (only allow
operator if the DRP is configured as a date picker only).
TIA
Jacques
Le 12/02/2025 à 11:34, Florian Motteau a écrit :
Hi all,
I just pushed https://github.com/apache/ofbiz-framework/pull/879,
which also adds a demo form on /webtools/control/WebtoolsLayoutDemo,
with a section that demonstrates some of the date range picker's
options.
Looking forward to your feedback !
Le 10/02/2025 à 10:50, Florian Motteau a écrit :
Hi All,
I created https://issues.apache.org/jira/browse/OFBIZ-13209, and
plan to move forward on this subject.
Le 20/12/2024 à 11:29, Florian Motteau a écrit :
I was not, thanks ! I'll create a Jira.
Le 20/12/2024 à 11:13, Jacques Le Roux a écrit :
Hi Florian,
I don't know if you are aware of
https://issues.apache.org/jira/browse/OFBIZ-10750 so I put it here.
At this stage, I have just read your email and have not yet a
clear opinion about.
Anyway, I think a subtask of 10750 would be welcome.
TIA
Jaques
Le 19/12/2024 à 16:26, Florian Motteau a écrit :
Hi all,
Following a request from one of our customers (who was
complaining about the date-find field), I recently implemented a
new kind of form field that uses the Date Range Picker jQuery
plugin (https://www.daterangepicker.com, I'll use "DRP" from now
on). This plugin provides a lot of flexibility when it comes to
picking a date (with or without time), or a date range. It
provides a very standard UI to do so, with a lots of options
(https://www.daterangepicker.com/#options).
I chose this plugin because it's a jQuery plugin, with a lot of
options that allows to replace both <date-find/> and
<date-time/>, and replace jQuery UI date picker
(https://jqueryui.com/datepicker/) which is far more less
flexible. This plugin is quite old and is not maintained anymore
(last commit 4 years ago), but it does the job, and is widely
used (so lots of support and resources).
I also considered https://air-datepicker.com/, which is still an
active project, is written in pure JavaScript, and does not
depend on MomentJS like DRP (which is a problem, see
https://momentjs.com/docs/#/-project-status/). In fact it does
not depend on anything which is great (and pretty rare in the JS
ecosystem...). In fact, as I write, I'm thinking of giving it a
shot :).
Anyway.
At first I tried to modify the date-find field, in such a way
that it could support the classic UI, or the DRP UI (basically,
something that would look like <date-find
input-method="classic|dateRangePicker">). After all, why would I
introduce another date picker field in OFBiz ?
After a few hours messing around with macros and the Java form
builder, it appeared that it would add a lot of complexity to
build a single field capable of displaying the standard date
picker or the new one (supporting all of the features that DRP
offers). I also thought that, for our use case, it could be
pretty handy to keep the standard date picker as it is. Also,
DRP has at least one limitation compared to the standard : OOTB
you cannot search entities where a date field is empty (but it
could be implemented on top of it).
So I finally chose to write a new field, <date-range-picker/>,
which supports almost all the options that DRP offers (as
field's attributes). It is really a wrapper around DRP, more
than a generic date picker field. It can be used to pick only
one date (like <date-time/>), or a range (like <date-find/>, you
can choose to pick time or not, and many other things showcased
here : https://www.daterangepicker.com/#examples. In our use
case, we plan to use it on a few critical forms (the ones that
our client complained about), and keep the <date-find/>
everywhere else. If everything goes fine, we will eventually
extend its usage.
So my question would be : do you feel that a new date/date-range
picker field, with a more fancy UI, would be an interesting
addition to the common theme in OFBiz ? Would you have any
suggestion about that ? If we go forward, do you have an opinion
about wether I should choose DRP or Air Picker (the method would
be the same : implement every option that the plugin offers as
OFBiz field attributes) ?
Thanks for your time!
Florian
