Posts Tagged ‘SCSF’
SCSF April 2008 Fix for Visual Studio 2008 SP1
Smart Client Software Factory April 2008 Fixed for VS 2008 SP1 (MSI-Package) DOWNLOAD |
Please read NEXT FEW lines carefully to understand if it suits for you.
April’s 2008 official release unfortunately has several known issues on VisualStudio 2008 SP1
This package is provided for you by AAR only as a result of careful applying patches described at the CodePlex SCSF knowledge base website to the Aplil’s source code and a minor repackaging all the result as MSI.
Also this prepackaged version contains some popular binary libraries of two additional products:
These files can be found at «Lib» subdirectory under your installation path. These files are passive i.e. do not affect any exisiting installations of corresponding products.
As well this installation contains HxS Help files from the original Smart Client Software Factory, that will be integrated into VS2008 Help system during installation (the last percent of the installation progress indicator is Help merging, and it takes the most time of the overall process).
So, theoretically, this package can be used as the sufficient standalone replacement of scsf.2008.april.
Samples and Reference implementation of SCSF are not included yet, but can be included later if an appropriate feedback will be received.
Реквием по Акрополису, Фанфары Кабу
Об авторе: Уард Белл, продукт-менеджер компании DevForce .NET enterprise application development product from IdeaBlade (www.ideablade.com).
Отрывок из статьи «Реквием по Акрополису, Фанфары Кабу»
[Вольный перевод by Artazor]
… И всё же не смотря на преимущества WPF, я продолжаю рекомендовать использовать CAB/SCSF WinForms технологии для LOB (line-of-business) приложений . Даже для новых разработок.
Да-да, конечно, в моей компании мы делаем значительные успехи в WPF-овских инициативах, и я вполне оптимистичен по поводу нового поколения WPF приложений, которое появится к концу 2008-го года. Потрясающая WPF-овская архитектура связывания данных (WPF data binding) *сама по себе* изменит не только способ создания пользовательских интерфейсов, но и наши инструменты мышления о них.
Но давайте оставаться реалистами. WPF-разработка сегодня — намного сложнее аналогичной WinForms разработки. Бедность инструментов создания WPF приложений и крутая кривая обучения как минимум на год убьют производительность разработчиков . Если вам необходимо сдать большое приложение в разумные сроки, вы должны подумать дважы перед тем, как покинуть остров WinForms: до материка вы можете и не доплыть даже зная, что он есть.
Очевидная опасность — то, что вы останетесь позади. Некоторые шутники будут острить, что ваше приложени стало «Наследством» («Legacy») еще до того как было выпущено. Хорошо если вы им скажете «у меня хотя бы ЕСТЬ релиз».
Ведь вы же можете делать классные, современно выглядящие WinForms приложения, которые прекрасно справляются со своей работой.
Когда вы будете сдавать свой продукт, другие парни будут париться над глючащими, падающими но при этом гламурно-глянцевыми WPF-фронтэндами.
Ходит множество разговоров, как WPF позволяет качественно поднять («прокачать») пользовательский интерфейс (Differenting the UI)
Прокачивание пользовательского интерфейса имеет смысл в публичных приложениях, где нужно красиво сверкнуть задницей, чтобы сорвать куш или просто остаться в бизнесе. Прокачивание же интерфейса ради самого прокачивания абсолютно не имеет смысла во внутренних приложениях, призванных повышать производительность труда, а именно таковы типичные LOB приложения. Вы должны «прокачиавть» достинства вашего приложения а не косметику.
Не поймите меня неправильно. Я крайне убеждён что серьёзный, красивый и удобный пользователский интерфейс — обязателен. И вопрос не ставится в форме «Должны ли мы инвестировать ресурсы в пользовательский интерфейс?». Вопрос — другой — «Является ли WPF UI лучшей альтернативой WinForms для LOB приложений?». Ответ будет «Да». Когда-нибудь. Но не сегодня и не на следующие год, или два.
Мне ещё предстоит встретить управляемое данными LOB-приложение, которое бы использовало WPF действительно с толком. Тут я не имею в виду интерфейс с белыми фонтами на сияюще чёрном фоне, отражения картинок [типа «мокрый пол»], скруглённых краев и больших анимированных кнопок (всей той попсы, которая до одного места дядям, делающим реальный бизнес). Да, я таращился, как тот парень, первый раз смотря как моя форма крутится на «карусели» (WPF-визуализация старого понятия переключения табов или кручения элементов в листбоксе). Это приелось на десятый раз. А в сотый раз я уже был рассержен и ждал, когда интерфейс кончит вращаться и отдаст, наконец, мне мою чёртову форму.
Я начал искать простые WPF эффекты, которые имеют смысл и право быть. Эффект имеет право быть, если от увеличивает продуктивность пользователя. Он должен помочь пользователю увиедть важное событие или важную связь более быстро и более ясно. Он должен
помочь совершать правильный выбор быстрее.
Такие эффекты обычно очень тонкие. Например однажды я увидел картинку, увеличенную всего на 5% от её обычного размера для того, чтобы привлечь внимание к произошедшему событию. За этот эффект цепляется глаз, но при этом эффект не раздражает. Великолепно.
Я могу использовать какой-нибудь неброский эффект для того, чтобы пользователь знал, что операция «save» прошла успешно (иногда пользователю бывает важно знать об этом). Это можно сделать без типичного, назойливого прерывания работы диалогом «Save Completed».
Мы изобретаем многие из таких эффектов и они потом прочно входят в наш лексикон. Это — лексикон повседневных идиом, которые мы используем для построения эффективных пользовательских интерфейсов. Но, к сожалению, эти идиомы не существуют *прямо сейчас* и даже разработчики уровнем выше среднего плохо подготовлены для того, чтобы изобретать их самостоятельно.
Пока у нас не будет одного лексикона оправданных графических идиом на всех, преимущества WPF для создания LOB приложений минимальны.
[Читать полный текст на английском ]