Date conversion

Thanks for creating this issue.

I am largely torn between two methods of conversion right now. As you might have seen, there are two things responsible for rendering the popup picker–the field widget, and the form element under it. I am wondering where I should actually convert the dates.

It's easy to convert the dates in the widget, but a side effect of that is that the form element would only return dates in another calendar, never a date you can actually use for storage (maybe that's a good thing). Alternatively, we can handle the conversion in the TaarikhDate element itself, which is slightly tricky as I am not very sure how to cleanly access the taarikh plugin manager from there.

That makes sense. I suppose it is reasonable for it to work this way as long as it is documented properly.

Speaking of which, there is another point to decide. There are variations in different calendar systems–even in hijri (right now, I have only implemented one). I am thinking of how that choice should be exposed to the site builders. Should this be a site-wide setting or should the site builder be able to specify the calendar system per widget and formatter. Thoughts?

Created #2933763: Taarikh Date Object.

@Anas_maw, thanks for the patch. My primary concern with them is how the algorithm service instances were created. I have been working on a similar methodology and it is close to working. Here is the patch so far.

It works for regular node save and load but fails when there is a validation error in some other field and the node edit form is shown again. I suspect this happens because valueCallback is not called again (as #value would already be set). As such, I don't like the method of unsetting #value we are doing here.

+++ b/src/Element/TaarikhDatetime.php
@@ -32,7 +35,8 @@ class TaarikhDatetime extends Datetime {
       // @todo: idea: Unset #value and set some other property so that valueCallback is always called
-//      unset($element['date']['#value']);
+      $element['date']['#default_value'] = $element['date']['#value'];
+      unset($element['date']['#value']);

I don't see a way around this for now. One thought is that I move the conversion logic to processDate and validateDate methods instead of keeping it entirely in valueCallback. I am going to try this now.

@Anas_maw, can you share your workaround? FYI, moving the logic out of valueCallback results in a slightly similar problem.

This works. I tested all scenarios I can think of and it worked fine. Reviews appreciated.

I am calling it a day. I'll test this again tomorrow and after some clean-up and resolving review comments, if any, I will commit this. Thanks for all your help.

Thanks for testing and reviewing. I did some cleanup and pushed the changes.