Часто вижу людей потрясающе хорошо разбирающихся в новых технологиях , будь то новые фреймворки, библиотеки или разные прогрессивные языки ,но совершенно не понимающих зачем следует писать простой и понятный код ,лишенный лишних зависимостей и читаемый не только аффтором. Так же очень сложно бывает втолковать зачем стоит делить приложение на понятные классы ,которые в свою очередь на понятные и логичные функций , почему не стоит называть переменные односимвольными именами и создавать вложенные циклы с хитрыми условиями.
Наверное в понятие опыт входит некое чувство красоты кода и некое чувство жопы ,которая будет если этой красотой пренебрегать.
Большая часть этого блога посвящена вопросам и мыслям, которые возникают у меня при разработке программного обеспечения.
четверг, 3 июля 2008 г.
среда, 2 июля 2008 г.
Добавление митинга в MeetingWorkspace
Появилась необходимость создавать митинги используя SharePoint Object Model (SOM). В MSDN для этого существует ф-я SPMeeting.Add, с совершенно невразумительным прототипом принимающим все параметры в виде строчек (будь то числа ,GUID или даты). При попытке ее использовать вот в таком варианте:
Я неизменно получал исключение вида:
При этом создать тот же самый митинг используя ф-ию WebService Meetings.AddMeeting получалось без проблем:
C точки зрения логики ясно что ф-я AddMeeting вызывает внутри себя SPMeeting.Add ,а следовательно ф-я Add в принципе как то должна работать. Поиски в инете никаких результатов не дали , такое ощущение что с этой ф-ей никто ещё вообще не работал.
Когда уже руки опускались пришла идея посмотреть с помощью Reflector for .NET библиотеки самого веб сервиса и там нашелся вот такой вот замечательный вызов:
четко видно что перед передачей дат в функцию они подвергаются конвертации с помощью ф-ии DateToISO8601BasicDATE. В ней как оказалось и кроется вся соль.
После изменения кода вот так ,все замечательно заработало :
Заметьте внутри ф-ии уже осуществляется конвертация в UTC так что дополнительно конвертировать не надо.
В результате всего этого остается только вопрос к MS зачем было так все усложнять и почему нельзя было хотя бы описать это в MSDN.
static void Main(string[] args)
{
SPSite oSite = new SPSite("http://mmsp7");
SPWeb webRootWeb = oSite.RootWeb;
SPWeb Web = webRootWeb;
string weburl = "tmeet";
SPWeb MettWeb = null;
MettWeb = Web.Webs[weburl];
var MettInf = SPMeeting.GetMeetingInformation(MettWeb);
short mettcount =0;
var StartDate = DateTime.Now;
StartDate.AddDays(15);
var EndDate = DateTime.Now;
EndDate.AddDays(17);
int res = MettInf.Add(
null,
System.Guid.NewGuid().ToString(),
0,
DateTime.Now.ToString(),
"New Meetin",
"Room 5",
StartDate.ToString(),
EndDate.ToString(),
false,
out mettcount);
}
Я неизменно получал исключение вида:
Unhandled Exception: System.ArgumentException: Value does not fall within the ex pected range.
at Microsoft.SharePoint.Library.SPRequestInternalClass.AddMeeting(...
При этом создать тот же самый митинг используя ф-ию WebService Meetings.AddMeeting получалось без проблем:
static void Main(string[] args)
{
ICredentials cred = new NetworkCredential("Administrator", "1", "VELASKEC");
var meetingsWs = new Meeting.Meetings();
meetingsWs.Credentials = cred;
meetingsWs.Url = @"http://mmsp7/tmeet/_vti_bin/meetings.asmx";
var StartDate = DateTime.Now;
StartDate.AddDays(5);
var EndDate = DateTime.Now;
EndDate.AddDays(7);
meetingsWs.AddMeeting(
"",
System.Guid.NewGuid().ToString(),
0,
DateTime.Now.ToUniversalTime(),
"New Meetin",
"Room 5",
StartDate.ToUniversalTime(),
EndDate.ToUniversalTime(),
false);
}
C точки зрения логики ясно что ф-я AddMeeting вызывает внутри себя SPMeeting.Add ,а следовательно ф-я Add в принципе как то должна работать. Поиски в инете никаких результатов не дали , такое ощущение что с этой ф-ей никто ещё вообще не работал.
Когда уже руки опускались пришла идея посмотреть с помощью Reflector for .NET библиотеки самого веб сервиса и там нашелся вот такой вот замечательный вызов:
public SoapXml.SoapXmlElement AddMeeting(string organizerEmail, string uid, uint sequence, DateTime dateStamp, string title, string location, DateTime dateStart, DateTime dateEnd, bool nonGregorian)
{
SoapXml.SoapXmlElement element = this.AddMeetingCore(organizerEmail, null, uid, sequence, this.DateToISO8601BasicDATE(dateStamp), title, location, this.DateToISO8601BasicDATE(dateStart), this.DateToISO8601BasicDATE(dateEnd), nonGregorian);
return element;
}
четко видно что перед передачей дат в функцию они подвергаются конвертации с помощью ф-ии DateToISO8601BasicDATE. В ней как оказалось и кроется вся соль.
После изменения кода вот так ,все замечательно заработало :
static private string DateToISO8601BasicDATE(DateTime dt)
{
string format = "yyyyMMdd'T'HHmmss'Z'";
return dt.ToUniversalTime().ToString(format, DateTimeFormatInfo.InvariantInfo);
}
static void Main(string[] args)
{
SPSite oSite = new SPSite("http://mmsp7");
SPWeb webRootWeb = oSite.RootWeb;
SPWeb Web = webRootWeb;
string weburl = "tmeet";
SPWeb MettWeb = null;
MettWeb = Web.Webs[weburl];
var MettInf = SPMeeting.GetMeetingInformation(MettWeb);
short mettcount =0;
var StartDate = DateTime.Now;
StartDate.AddDays(15);
var EndDate = DateTime.Now;
EndDate.AddDays(17);
int res = MettInf.Add(
null,
System.Guid.NewGuid().ToString(),
0,
DateToISO8601BasicDATE(DateTime.Now),
"New Meetin",
"Room 5",
DateToISO8601BasicDATE(StartDate ),
DateToISO8601BasicDATE(EndDate),
false,
out mettcount);
}
Заметьте внутри ф-ии уже осуществляется конвертация в UTC так что дополнительно конвертировать не надо.
В результате всего этого остается только вопрос к MS зачем было так все усложнять и почему нельзя было хотя бы описать это в MSDN.
Подписаться на:
Сообщения (Atom)