Date handling about exact-php-client

[kvij]

I have an idea about implementing typehanders that is versatile enough for your carbon usecase. The (optional) typehandlers that I will be including will only use native PHP though. Unfortunately I do not have that much time on my hands at the moment but I will try to get it done before the holiday season starts.

[stephangroen]

I don't think automatically converting to DateTime would be a good option. Not everyone uses DateTime and it's an unnecessary performance hit to always convert the timestamp to an object.

We could add your function to the README to help people on their way to use the return values from Exact.

[kvij]

Yes I agree with you. That is part of why I was in indecision. On one hand the value we get form Exact is useless. On the other we don't want an expensive and complex operation.
As Exact already documents it as DateTime and DateTime is the most versatile approach to date and time operations in PHP I don't agree with that part of your counter argument.

Perhaps what we are missing is a way to inject strategies. That way I could also have build the lazy loading as an addon without breaking compatibility. The downside is of course that the Model requires initialization and might become overly complex.

Thanks again for your time and free to add the function tot the documentation!

[stephangroen]

I personally use Carbon a lot, which extends DateTime. In this case I would get a DateTime object and then create a Carbon object from that. I notice quite some devs use other libraries that extend the not so readable DateTime class of PHP.

If it is doable, we could make it an option for the client. We don't really have any option / configs yet, but it could be on the connection as this is injected for everything.

The excellent Excel library box/spout has this feature: https://github.com/box/spout#datetime-formatting

As a dev you can then choose to use DateTime or original values and only add the overhead of transforming the data if you choose so. This also keeps everything backwards compatible.

[Pirabarlen-Cheenaramen]

public function __get($key)
{
    if (isset($this->attributes[$key])) {
        if (is_string($this->attributes[$key])
            && preg_match(
                '(\/Date\(\d+\)\/)', $this->attributes[$key]
            )
        ) {
            return $this->exactToDateTime($this->attributes[$key]);
        }
        return $this->attributes[$key];
    }
}

?

[kvij]

@Pirabarlen-Cheenaramen That would work for you most likely but will break backward compatibility and we are looking for a more generic solution so we can handle any type of data flowing trough the model.

[silvant]

Maybe even nicer to do something with injection:
$connection->setDateFormatter(callable $dateFormatter);

And in the model use:
return $this->connection->dateFormat($exact);

And in the connection.php:

private $dateFormatter;

public function setDateFormatter(callable $formatter)
{
    $this->dateFormatter = $formatter;
}

public function getDateFormatter()
{
    if (empty($this->dateFormatter)) {
        $this->dateFormatter = function ($exact) {
            $timestamp = substr($exact, 6, 10);
            $date = new \DateTime();
            $date->setTimestamp($timestamp);
            return $date;
        }
    }
    return $this->dateFormatter;
}

public function dateFormat($exact)
{
    $formatter = $this->getDateFormatter();
    return $formatter($exact);
}

[kvij]

@silvant I have been a bit over allocated both at work and in private. I did draft a generic solution for typehandling but there are some issues I need to work out.
We have more Exact integration planned for the first quarter of this year. I can at least use some corporate time to do some testing and benchmarking.

[silvant]

@kvij Want me to take a look at it? If you make a branch I can do. I usually have a few hours a week available for these kind of things (and a having paying customer who wants an Exact integration also helps 😃 )

[kvij]

@silvant Sorry I missed this entirely 😞. I have made a working implementation, it's fairly complex with and has some issues. Most notably there is to large a performance impact and to much magic going on.
This all has everything to do with trying to do typehanding in a framework that loses all type information but comunitcates with a statically typed backed.

Therefore I am going to solve this by first restoring the type information in the entities (without losing backwards compatibility). And from there on workout the basics of the type-handling.

I will toss the current typehandler branch and create a new one. I will let you know when I am done with the basics so we can work together on this if you are still interested!

[stephangroen]

Closing this for now, since there is nothing planned on date handling at the moment and no activity.