Make Client and Server Side Formatters Same

[sid]

Hi.
The formatters available for client side and server side are not same. There are a few formatters that might only make sense on server/client side, but most should be same - both in terms of availability and functionality.

1. Formatters like hasItems, encode, decode etc should be available on both client and server side.
2. Formatters like where, split, join etc should have the same syntax on both client and server side.

The second point would be a breaking change, but a good change to implement. I would not mind refactoring hundreds of lines of codes in various projects, if this is rolled out with prior warning/notification.

[bpj]

Good shout!

I would add to this that the default formatter behaves differently in the case of empty strings:

Default - different behaviour for SC to Client-Side

Is the data binding default function meant to work the same for both SC (in my case PHP) and client-side? I’m finding that the behaviour for empty strings (not NULL) is different: Server Connect treats an empty string as something that would trigger the default value however, client-side formatter seems to leave it as an empty string. e.g. imagine a SC returns two values firstname = 'John' preferredname = 'Johnny' I use preferredname.default(firstname) to show the preferred name if presen…

I am, however, very nervous about changing existing formatters. Could some be recreated and given a new name e.g. .where becomes .find (essentially becoming an extra formatter) with the old inconsistent ones not being available in the UI but work to preserve legacy usage?

[mebeingken]

@bpj

Could some be recreated and given a new name e.g. .where becomes .find (essentially becoming an extra formatter) with the old inconsistent ones not being available in the UI but work to preserve legacy usage?

Agreed. Similar to what was recently done for the handling of timestamps–there is a legacy mode to protect existing code, and new improved options for going forward.

[sid]

@bpj

Could some be recreated and given a new name e.g. .where becomes .find (essentially becoming an extra formatter)

I would not prefer that since it will lead to code baggage of sorts.
And such breaking changes should force the team to update their docs as well, solving the problem of outdated docs as well to some extent.

I would have preferred to not have the DB date handling to have multiple options as well.
Because the team did not handle the breaking change with enough time to transition, legacy options had to be added.

Even though the final dropdown for date handling is good, I would have preferred a clean break.

[bpj]

This can easily be addressed. The new/legacy formatters could be in different files/folders Have a project option to select legacy option and if selected or unset (for existing projects) then include legacy formatters on the page. For new projects it would be disabled so only new formatters would be included.

I have several projects using many of these formatters in many files and it would be prohibitively time consuming to change them all. So my CHOICE would be for a little code baggage to preserve behaviours and functionality. If you are fortunate enough to have the time to make all the necessary changes to existing projects then you can make that CHOICE and only include the new versions and therefore no code baggage.