zotonic/z_stdlib

What to do with {trans, ...}

Closed this issue · 6 comments

There are some functions which have knowledge on zotonics trans tuples.

What should we do with them?

Maybe wrap them using ifdefs?

kaos commented

I think it would be nice if there was no ties back to zotonic from z_stdlib.

maybe the functions that need to support some additional non standard inputs could have an extra fun argument, that can be used as a fallback.

So, the z_string:to_name/1 could be rewritten something like this:

-export([to_name/2]).

to_name(Name, _) when is_list(Name) ->
    to_name(Name, [], 0);
to_name(Name, Fallback) when is_binary(Name) ->
    to_name(binary_to_list(Name), Fallback);
to_name(Name, Fallback) when is_atom(Name) ->
    to_name(atom_to_list(Name), Fallback);
to_name(Name, Fallback) when is_function(Fallback) ->
    Fallback(Name).


%% and can be called like this from another module

....
z_string:to_name(Foo, my_stringlib:to_name/1),
....

%% in my_stringlib.erl
-export([to_name/1]).

to_name({trans, Tr}) ->
    ....

This ought to be doable for the other occasions of {trans, ...} records too, although I haven't looked at them...

kaos commented

Oh, and still keep the z_string:to_name/1 for those not using the fallback, of course...

to_name(Name) -> to_name(Name, undefined).

I think the {trans, [...]} representation is actually quite harmless and useful.
Without having it here we need to have wrappers in Zotonic, mimicking all libraries.

And as a trans tuple can be nested inside a bigger data structure I would prefer to keep support in z_stdlib.

Then we can also add the code handling the translation selection etc.

kaos commented

Sure, I think I saw a call to z_trans some where, but if we move z_trans over to z_stdlib, then that should be fine :)

However the fallback method could be a useful approach to un-tie other parts that depend on zotonic knowledge...
And yes, doing it this way we may need to add some wrappers/helpers to the zotonic source to provide the fallback argument. But that isn't such a high price to pay to keep the lib clean, imho.

I think we can just keep them in here, is just a kind of extra format for textual data.