2017-02-13 21 views
0

Как переопределить поведение Flurl по умолчанию при сериализации объектов для запроса строковых значений? Например. код нижеFlurl (Fluent Url) пользовательская сериализация

DateTime date = new DateTime(2017, 1, 2, 3, 4, 5); 
Url url = "http://domain.com".SetQueryParam("date", date); 

производит следующий URL:

http://domain.com?date=01%2F02%2F2017%2003%3A04%3A05 

То, что я хочу это:

http://domain.com?date=2017-01-02T03%3A04%3A05.0000000 

, который будет являться результатом сериализации даты следующим образом:

date.ToString("O") 

ответ

0

Flurl заботится о f URL-кодирование, но помимо этого не имеет особого отношения к пользовательскому форматированию строк. Я предполагаю, что самый очевидный способ сделать то, что вы хотите, это:

"http://domain.com".SetQueryParam("date", date.ToString("O")); 

Если вы делаете это много, и хотите, чтобы избежать определения битового форматированием каждый раз, вы можете добавить свои собственные методы расширения (один для Url и один для string, согласно pattern):

public static Url SetDateParam(this Url url, string name, DateTime date) 
{ 
    return url.SetQueryParam(name, date.ToString("O")); 
} 

public static Url SetDateParam(this string url, string name, DateTime date) 
{ 
    return new Url(url).SetDateParam(name, date); 
} 

Тогда у вас есть:

"http://domain.com".SetDateParam("date", date); 
+0

Благодаря @Tod, это позор Flurl не позволяет определить S правила инициализации для разных типов. Еще более раздражает то, что сериализация даты даже не учитывает текущую культуру потока и жестко запрограммирована как m/d/y. Почему не канонический формат y-m-d, чего я пытаюсь достичь? Если я отправляю дату в строке запроса на сервер, работающий на, например, Австралийские региональные настройки, он попытается интерпретировать его как d/m/y, а половина моих дат будет ошибочной. На данный момент я решил не использовать Flurl и написать собственный построитель строковых запросов ... – Andrew

+1

@ Андр Я задаю ваше мнение здесь в нескольких отношениях. Во-первых, я не считаю постыдным вообще, что функция не существует, о которой никто не просил до сих пор. Вы рассматривали вопрос о вводе предложения или подаче PR на GitHub, прежде чем жаловаться здесь? Во-вторых, я предложил 2 очень простых, простых решения, чтобы делать то, что вы хотите с Flurl. Если вы прочтете их и поймете их, и все же пришли к выводу, что отбросить его и написать собственный строитель - это ваш лучший вариант, я боюсь, что не буду следовать вашему мыслительному процессу. –

+0

@@ Тодд, извините, я не понимал, что вы автор Flurl, и может лично написать свой комментарий. Я не критикую компонент в целом, я думаю, что это здорово, и у меня были все намерения использовать его, пока я не обнаружил это поведение. Предлагаемые вами решения не будут работать для меня. Вы говорите, что вы «не следуете моему мыслительному процессу», но вы не знаете моих точных требований. Я также откровенно не следую вашему мыслительному процессу, когда вы решили сериализовать дату в формате hardcode как m/d/y, а не использовать однозначный y-m-d. Не могли бы вы объяснить? – Andrew