Документация разработчика: управление документооборотом Sharepoint по сравнению с [закрытым] ScrewTurn Wiki
Это мои 2 цента на основе ответа Grax , но с двумя параметрами, необходимыми для общего метода.
Предположим, что ваш метод определяется следующим образом в классе Helpers:
public class Helpers
{
public static U ConvertCsvDataToCollection(string csvData)
where U : ObservableCollection
{
//transform code here
}
}
В моем случае тип U всегда является наблюдаемым объектом хранения коллекции типа T.
Поскольку у меня есть предопределенные типы, я сначала создаю «фиктивные» объекты, которые представляют наблюдаемый набор (U) и объект, хранящийся в нем (T), и который будет использоваться ниже, чтобы получить их тип при вызове Make
object myCollection = Activator.CreateInstance(collectionType);
object myoObject = Activator.CreateInstance(objectType);
Затем вызовите GetMethod, чтобы найти вашу общую функцию:
MethodInfo method = typeof(Helpers).
GetMethod("ConvertCsvDataToCollection");
До сих пор вышеупомянутый вызов в значительной степени идентичен тому, что было объяснено выше, но с небольшой разницей, когда вам нужно передать ему несколько параметров.
Вам нужно передать массив Type [] в функцию MakeGenericMethod, которая содержит типы «фиктивных» объектов, которые были созданы выше:
MethodInfo generic = method.MakeGenericMethod(
new Type[] {
myCollection.GetType(),
myObject.GetType()
});
Как только это будет сделано, вам нужно вызвать метод Invoke, как указано выше.
generic.Invoke(null, new object[] { csvData });
И все готово.
UPDATE:
Поскольку @Bevan выделен, мне не нужно создавать массив при вызове функции MakeGenericMethod, поскольку он принимает параметры, и мне не нужно создавать объект, чтобы получить типы, поскольку я могу просто передать типы непосредственно этой функции. В моем случае, поскольку у меня есть типы, предопределенные в другом классе, я просто изменил свой код на:
object myCollection = null;
MethodInfo method = typeof(Helpers).
GetMethod("ConvertCsvDataToCollection");
MethodInfo generic = method.MakeGenericMethod(
myClassInfo.CollectionType,
myClassInfo.ObjectType
);
myCollection = generic.Invoke(null, new object[] { csvData });
myClassInfo содержит 2 свойства типа Type, которые я установил во время выполнения на основе перечисления значение передается конструктору и предоставит мне соответствующие типы, которые затем я использую в MakeGenericMethod.
Еще раз спасибо за выделение этого @Bevan.
11 ответов
Я надеюсь, что это будет некоторым использованием - дополнительные очки или нет:)
Сервер SharePoint (SPS) или Windows SharePoint Services (WSS) ОЧЕНЬ хорош, если Вы работаете с офисными документами - можно присвоить версию, проверить в, доля, искать и т.д. Я не думаю, что существует что-либо на рынке, который приближается для той функции (это также делает пользовательские списки и наполняет действительно хорошо).
, Но как Вы указываете, функция WIKI является, ну, в общем, нестандартной.
Для документации разработчика, Wiki намного лучше, поскольку можно легко связать документы, и даже если по единственной причине, что разработчики склонны ЛЮБИТЬ разметку Wiki! Заставляет его чувствовать, что они пишут код, не документ. Ну, хорошо, мне нравится он. Документы Word? бесконечное разочарование, специально для отрывков кода и вещей как API. Wiki обычно обрабатывают код и структурированное форматирование действительно, действительно хорошо.
, Но вот основной момент того, что я отправлял:
, Если можно разместить ASP.NET - и если у Вас есть SPS, Вы уже можете! - тогда просто устанавливают ИХ ОБОИХ. Сделайте новый IIS виртуальным хостом, поместите STW в тот один ('cos, SPS будет в своем собственном виртуальном хосте), *. Массажируйте DNS немного (таким образом, можно совершить нападки http://wiki или что-то), и просто пойдите для него.
, Поскольку это является все внутренним к Вашей компании, и STW имеет безопасность Windows и версии, безопасность не является огромной проблемой. Каждая страница может быть связана с отовсюду - это - страница HTML, в конце концов - таким образом, можно связаться с ним от сверхзвуковой Wiki, если Вы действительно хотите. Существует, некоторые привязываются, я предполагаю, но не много.
Здесь в BBC Во всем мире, мы используем много технологий:
- Слияние Atlassian (WIKI) для некоторых проектов. Я люблю эту Wiki, но это - система крупного-предприятия-y.
- Поворот Винта для некоторого материала внутриотдела.
- Trac для некоторого другого материала (кто-то еще настроил его с SVN на нашем источнике repo, таким образом, он использовал немного - это хорошо, мне скорее нравится он, но это - a*se для установки)
- SPS/WSS для управления документацией.
существуют ссылки между STW, Trac и SPS - например, мы пытаемся не сохранить документы как вложения в trac, скорее связаться с ними в SPS, и т.д.
Работы хорошо.
Что касается боеприпасов: SPS работает хорошо, если он соответствует тому, что Вы хотите сделать (или можно соответствовать тому, что IT делает). В противном случае Вы или завинчены или должны сделать много dev, которое является действительно тем же самым:)
, Но кроме управления, становящегося все забавным об этом, я не вижу проблемы с установкой обоих. STW свободен, в конце концов. У Вас есть сервер (серверы).
И это получает запись dev документов, который редко является плохой вещью. Хорошо, это - плохая вещь, если настоящие люди должны считать его, но документы для другого dev's? Вся польза.
*note: виртуальный ХОСТ. Не ВИРТУАЛЬНЫЙ КАТАЛОГ.
Я сделал обоих. После тех событий вот мое предложение:
- , Если Вы нуждаетесь в WYSIWYG и не заботитесь о чрезмерном увеличении размера Sharepoint и отсутствии функций (Wiki упрощенно, но имеет основные функции, в которых Вы нуждаетесь в Wiki), пойдите с этим. Это работает Wiki и помогает, когда деловые люди должны подбросить Wiki ударом - партия меньше времени, уча им использовать его и т.д.
- , Если можно работать со скелетами и просто хотеть простую Wiki, это быстро и гибко, Вы не можете победить screwturn.
Что касается, почему использовать Wiki, или screwturn или sharepoint - это бьется, документы в формате Word в Sharepoint передает. Для использования Sharepoint прежде всего необходимо загрузить документ, редактирование, загрузку или интеграцию Office использования, которая рискованна в лучшем случае Wiki устраняет все трение и делает его очень простым для обновления. Устранение трения является ключевым, потому что, когда необходимо работать с документами в формате Word, Вы заканчиваете тем просто, что не обновляли их так часто, как Вы должны. С Wiki это - 2 второго поп в/редактирование/сохранение транзакции. С документом в формате Word требуются минуты, чтобы загрузить слово, открыть документ, редактирование, беспокойство о форматировании, сохранить, и т.д.
Эй у меня есть опыт здесь. Мы начали использовать ScrewTurn на работе, но нас попросили переключиться, так как компания уже купила SharePoint. Качество документации понизилось, потому что документы Word не идут ни в какое сравнение с Wiki, и как другие указали, SharePoint не в нормальном состоянии.
, По-моему, ничто не бьет Wiki для документации. Я думаю, что это - главным образом способность создать ссылки на страницы, которые еще не существуют. Тем путем я могу погасить документацию, и остальное заполнено по мере необходимости. Это делает документацию более краткой и читаемой.
С документами в формате Word, связывание гиперссылками, очень вероятно, не будет использоваться, но это настолько полезно удобочитаемости документации. Я мог продолжить...
Как обобщение, слово довольно ужасно для технических документов. Поскольку это работает очень плохо на большие, структурированные документы, это поощряет быстрое увеличение маленьких документов без перекрестных ссылок между документами. Масштабируйте это до любого значительного размера, и Вы испытаете затруднения при нахождении, какие документы принадлежат проблеме, которую Вы пытаетесь исследовать. Со временем Вы найдете людей, тратящих впустую все больше времени, ища через беспорядок документов слова, электронных таблиц, схем Visio и даже powerpoint presentaions для нахождения информации, которая может или не может быть зарегистрирована.
Помещение их в sharepoint просто вынуждает Вас направить свой поиск браузера.
Любой инструмент технической документации должен поддерживать перекрестные ссылки между документами, чтобы не терять те ссылки. Wiki достигает настолько далеко лучше, чем слово когда-нибудь будет. Кроме того, это намного легче к incorported сгенерированное содержание, такое как словари данных или документы API в Wiki, и можно сделать цели XRef стабильными.
Вот открытый исходный код, расширенный Wiki для SharePoint, который может более подойти:
http://www.codeplex.com/CKS/Wiki/View.aspx?title=Enhanced%20Wiki%20Edition&referringTitle=Home
Во-первых, проверьте этот поток StackOverflow . Подобный вопрос спросили о Sharepoint wikis и ответах там, и за и против действительно полезно и обрисовывает в общих чертах "невозможный в Sharepoint" часть Вашего вопроса.
я посреди попытки реализовать команду Wiki в Sharepoint прямо сейчас для почти его точно та же самая вещь как Вы, используя Sharepoint для документов команды в течение пары лет. Мои наблюдения:
Библиотеки Документа Sharepoint
Мой опыт состоит в том, что Sharepoint для документов достоин. Это может быть облуплено, и Вы будете иногда терять редактирования или иметь проблемы производительности, хотя хорошая служба поддержки Sharepoint может помочь с частью этого. Я действительно находил библиотеки документа Sharepoint лучше, чем хранение вещей в сети. Это делает документы и библиотеки легкими связаться с. Разумное использование свойств метаданных может сделать представление списка Sharepoint очень полезным для наблюдения, каков документ, что это для, и в каком состоянии это находится, таким образом, наши аналитики, премьер-министры, разработчики, и т.д., все знают сразу, у кого есть шар и когда что-то ожидает на них. Это было запущено для пары проекта несколько лет назад; сегодня рабочие процессы 2007 Sharepoint могут, вероятно, предоставить уведомления.
существует также управление версиями для документов. Но поскольку некоторые другие отметили, что выполнение вещей в документах имеет наверху и дефекты, вовлеченные в создание, загрузку и совместное использование. Контроль справки документов, но свободные разработчики орудия может загрузить документы, отредактировать их, и, чем хранят их в другом месте таким образом нанесение поражения управлению версиями. Это произошло с нами, хотя это - проблема дисциплины и не отказ Sharepoint.
Sharepoint Wiki
На ответ Chris Hynes, трение является хорошим словом для описания проблемы. Поскольку справочник внутренних деталей инфраструктуры команды Wiki, кажется, работает лучше на нас. Wiki делает данные почти мгновенно видимыми, не имея необходимость нажимать на ссылку сначала и ожидать Word для загрузки. Редактирования более быстры и легче также... и хотя я все еще экспериментирую с ним, Sharepoint wikis имеют управление версиями и позволяют "выезды" статей Wiki.
Как Вы и другой ТАК поток, на который указывают, по сравнению с другими механизмами Wiki, Sharepoint легок. В чем это лучше? Ну, я использую его, потому что это там, не потребовал никакой специальной установки, лучше чем ничего, и откровенно говоря, это хорошо работает для внутреннего материала, который не должен быть устойчивым или стоять с клиентом. Легко продать боссу, потому что это не стоит чего-то большего чем что мы уже потратили. Wiki также не может как легко быть поставлена под угрозу свободными типами орудия, которые я упомянул ранее, и мы будем в состоянии просмотреть журнал аудита или откат при необходимости.
легко добавить и записи перекрестной ссылки, хотя, если Вы хотите встроить графику, необходимо загрузить их сначала на библиотеку Sharepoint. Можно отредактировать HTML в Wiki также, хотя я не уверен что ограничения, там с этим и управлением CSS, которому я верю, не доступно без доступа безопасности и Разработчика Sharepoint. Таким образом, что-либо кроме текста (как таблицы) не очень устойчиво.
До сих пор мне нравится он лучше, чем хранение всего как документы. Непосредственность наблюдения и редактирования данных дает Wiki реальный край. Это, конечно, легче, чем раскрытие документа и перепроверение его в. Со средним нерасположенным к документации разработчиком это помогает снять барьеры вокруг того, чтобы хранить обновленную информацию.
Что-то еще для рассмотрения. Вы ожидаете, что Ваш devs будет восторжен и активно вовлеченный в редактирование Wiki? Если так, Вы могли бы хотеть функции обсуждения другого механизма Wiki. Мои разработчики похожи больше всего; эти две вещи, которые они ненавидят больше всего, тестируют и документация. Таким образом, я - статьи создания парня, объясняющие процедуру сборки, использование среды базы данных, экземпляры приложения, карту сервера, контрольный список документации SOX, и т.д. другой devs главным образом сошлется на него и отправит незначительные обновления. Наше управление версиями и поддержка параллелизма в большой степени не подчеркиваются.
Wiki, намного более вероятно, будет использоваться, чем набор документов в формате Word просто, потому что это более быстро и легче найти, что запись редактирует или создает новую страницу, чем набор документов в формате Word когда-либо будет!
вопрос тогда становится, какой wiki
Почти любая Wiki лучше, чем Wiki SharePoint, что каждый вне шутки
, Screwturn превосходен, имеет ACLs и WYSIWYG в v3, и очень легок расшириться
, например, Используя плагин XSLT является большим для встраивания вывода серверных процессов, сборок CI, тестов, статистика управления исходным кодом и т.д.
, например, у Нас есть плагин OLEDB, который читает критические значения из различных баз данных компании и встраивает их в страницы, описывающие, что данные и что оценивает его, должен иметь. У нас есть одна основная страница, которая перечисляет все страницы, которые имеют данные за пределами предписанных диапазонов. Вид смешения СООТВЕТСТВИЯ и системного контрольного инструмента
, Если у Вас есть позиция управления по "всему", должен быть в SharePoint, тогда существуют плагины Screwturn, которые представляют страницы Screwturn как PDF, HTML, xml и т.д. (можно преобразовать в docx тогда), и имейте сценарий для дампа измененных screwturn страниц каждую ночь к SharePoint для поиска и целей "управления"
Вы могли бы хотеть проверить Слияние , поскольку это вероятно ведущее предприятие Wiki на рынке. Существует Коннектор SharePoint для той Wiki также. Как один из участников Коннектора SharePoint я немного смещаюсь, но Вы, вероятно, вредите себе, если Вы не проверяете несколько опций, которые являются там. Wikis может быть мощным и заразным, но этого не произойдет, если Wiki будет ниже среднего.
Никто никогда не мог быть доволен Wiki SharePoint путем сравнения его с любой другой системой Wiki.
Так, не сравнивайте его. Это имеет основные характеристики, необходимые, чтобы Wiki была полезна: можно ввести богато (несколько)-форматированный-текст, наряду со ссылками на другие страницы, существуют ли они. Щелчок на ссылку к несуществующей странице возьмет Вас к странице редактирования для новой, пустой страницы, позволяя Вам сохранить страницу.
Да, поддержка изображения сосет. Необходимо создать изображение сначала, затем вставить URL изображения. Так, займите две минуты и создайте библиотеку изображения для размещения фотографий Wiki в.
Помнят главные цели для Wiki - чтобы не конкурировать с другими инструментами Wiki, но записать идеи, быстро, и не останавливаясь для структурирования их. Структура может быть добавлена позже, если вообще.
, Поскольку другие сказали, telerik предлагает замену для Визуального редактора, существует CodePlex procject, работающий (медленно) над улучшениями, и, люди, это - SharePoint - если Вам не нравится он, можно настроить его. Это - ASP.NET, веб-сервисы и Windows Workflow Foundation.
я не рекомендую, чтобы любой вышел и купил лицензию MOSS только для реализации Wiki (или блог, в этом отношении). Но если Вы уже получили Инфраструктуру SharePoint (возможно, как часть Системного Сервера Основы Команды Команды Visual Studio), затем пойдите для него. Я видел несколько SharePoint, библиотеки Wiki, пользовавшиеся к чрезвычайно , улучшают сумму и качество документации разработчика, доступной нескольким группам в крупной организации разработки программного обеспечения. Как только мы закрываем обсуждение того, как большие другие wikis были, довольно много документации просто произошло, отдельно, точно так же, как это, как предполагается, делает.
Я использую Sharepoint вполне регулярно, и я нахожу это довольно медленным и все виды раздражения. Если все уже - документ Office И если Вы - компания, готово сохранить общий компьютер до скорости с версиями Office, то Sharepoint может хорошо работать. Если у Вас есть множество версий Office (как, мы делаем), тогда, это намного менее хорошо. Моя машина имеет некоторые более старые версии офисных компонентов, и интеграция не всегда работает правильно. Я учился не пытаться использовать интеграцию вообще.
самая важная вещь с любым решением состоит в том, чтобы удостовериться, что Ваши люди знают, как использовать его. У нас были некоторые проблемы вначале (версии файлов с различными именами вместо того, чтобы использовать управление версиями, встроенное в sharepoint), которые были действительно просто разрывами в обучении людей.
Мы в настоящее время используем комбинацию обоих, sharepoint для спецификаций и формализованных документов и Wiki для "молчаливого знания". Каждое из наших решений имеет страницу в Wiki, и это работает очень хорошо из-за простоты добавления содержания.