Comments 22
>Минусы: ацкий геморой с синхронизацией с MySQL,
Это еще почему? :D
С данными хорошо работать в silverlight.
Это еще почему? :D
С данными хорошо работать в silverlight.
пример из жизни — есть сайт, есть winforms приложение рулящее этим сайтом, на сайте используется кеширование данных из бд, чтобы ее постоянно не дергать.
вопрос — как узнать, что кеш надо обновлять? дергать БД с определенным интервалом не получится, кеши не отдельным демоном идут. реализовано на asp.net
вспоминая количество мата и времени на реализацию вышесказанного, web-интерфейс все-же предпочтительней.
вопрос — как узнать, что кеш надо обновлять? дергать БД с определенным интервалом не получится, кеши не отдельным демоном идут. реализовано на asp.net
вспоминая количество мата и времени на реализацию вышесказанного, web-интерфейс все-же предпочтительней.
да можно сделать, но сколько на это сил уйдет. Целиком и полностью согласен с госоподинон savant комментарием ниже.
Я как ПМ ищу путь наименьшего сопротивления и баланса удобство использования и скорости разработки
Я как ПМ ищу путь наименьшего сопротивления и баланса удобство использования и скорости разработки
UFO just landed and posted this here
Неверно. Java JDBC ещё никто не отменял с 1997 года. Да и таблицы в Swing «кликабельны» — достаточно посмотреть демки в Java SE SDK.
А у MS каждый год меняются технологии доступа к данным.
Использовать легче всего проверенные временем технологии, а не только что вылупившиеся технологии-однодневки.
Автору темы предлагаю посмотреть в сторону Java/JavaFX. Тем более, сейчас JavaFX может работать и на мобильных устройствах.
А у MS каждый год меняются технологии доступа к данным.
Использовать легче всего проверенные временем технологии, а не только что вылупившиеся технологии-однодневки.
Автору темы предлагаю посмотреть в сторону Java/JavaFX. Тем более, сейчас JavaFX может работать и на мобильных устройствах.
хоткеи в web-интерфейсе реализовать можно. примеры — jira или gmail.
да и если у таблицы нет особых приколов с фильтрами и форматированием, то в google docs они открываются вполне прилично.
а с win32 приложением огребете таких приколов, особенно на кешировании, что связываться потом не захочется. Хотя, можно данные дергать через xml-rpc, например, и обратно отдавать через него-же, нервов может сэкономить немало.
да и если у таблицы нет особых приколов с фильтрами и форматированием, то в google docs они открываются вполне прилично.
а с win32 приложением огребете таких приколов, особенно на кешировании, что связываться потом не захочется. Хотя, можно данные дергать через xml-rpc, например, и обратно отдавать через него-же, нервов может сэкономить немало.
> хоткеи в web-интерфейсе реализовать можно. примеры — jira или gmail.
Согласен сам то их и использую :)
> да и если у таблицы нет особых приколов с фильтрами и форматированием, то в google docs они
> открываются вполне прилично.
Может быть я старообрядец, но лично мне проще в Екселе, да и то Гугл, а у нас ограниченные ресурсы. Вопрос опять таки баланса…
Согласен сам то их и использую :)
> да и если у таблицы нет особых приколов с фильтрами и форматированием, то в google docs они
> открываются вполне прилично.
Может быть я старообрядец, но лично мне проще в Екселе, да и то Гугл, а у нас ограниченные ресурсы. Вопрос опять таки баланса…
Глянь ExtJs Grid, там пагинатор есть, аяксом будет всё подгружать и не будет браузер держать в себе огромное кол-во данных.
Я не пойму слов — >геморой с MySQL
Почему? %\
Можно спокойно под win привинтить (mysql) и сделать интерфейс (на чем хочешь :)
odbc никто не отменял
Почему? %\
Можно спокойно под win привинтить (mysql) и сделать интерфейс (на чем хочешь :)
odbc никто не отменял
Flex очень хорошо подойдет под поставленную задачу.
+ Если есть необходимость в десктоп приложении можно без лишних усилий скомпилить AIR app
+ Если есть необходимость в десктоп приложении можно без лишних усилий скомпилить AIR app
Рекомендую использовать Flex.
Хорошо продумайте с самого начала, как будет устроен обмен данными с сервером, отработка ошибок, авторизация. Это позволит избежать многочисленных проблем потом. Попробуйте несколько схем работы реализовать для теста — через JSON, XML, веб-сервисы и выберите наиболее удобную в использовании на сервере и в приложении. Потом сделайте DAO-слой — если попытаетесь обойтись без него, получится приложение в духе FoxPro или ранних Delphi — все в кашу.
На флексе можно делать очень классные динамические интерфейсы, которые легко меняют свое представление — это делается проще, чем на веб-страницах. Имеет смысл, спроектировав пользовательский интерфейс, реализовать его прототип, включающий панели, состояния, диалоги и отработать переключение состояний. Потом только спускаться к диалогам, контролам и т.п.
Приложения на Flex имеют паршивый look-n-feel по умолчанию. (Это я не с пустого места решил, а на основании фидбека от пользователей нескольких проектов). Сразу стоит закладываться на то, что базовый CSS придется перепахать, а поведение некоторых контролов переписать. Не имеет смысла заниматься оптимизацией интерфейса с самого начала (особенно разрабатывать собственные версии контролов), лучше заложить возможность этого этапа — сходные поведением элементы наследовать от общих классов, замыкать в классах логику поведения элементов.
Хорошо продумайте с самого начала, как будет устроен обмен данными с сервером, отработка ошибок, авторизация. Это позволит избежать многочисленных проблем потом. Попробуйте несколько схем работы реализовать для теста — через JSON, XML, веб-сервисы и выберите наиболее удобную в использовании на сервере и в приложении. Потом сделайте DAO-слой — если попытаетесь обойтись без него, получится приложение в духе FoxPro или ранних Delphi — все в кашу.
На флексе можно делать очень классные динамические интерфейсы, которые легко меняют свое представление — это делается проще, чем на веб-страницах. Имеет смысл, спроектировав пользовательский интерфейс, реализовать его прототип, включающий панели, состояния, диалоги и отработать переключение состояний. Потом только спускаться к диалогам, контролам и т.п.
Приложения на Flex имеют паршивый look-n-feel по умолчанию. (Это я не с пустого места решил, а на основании фидбека от пользователей нескольких проектов). Сразу стоит закладываться на то, что базовый CSS придется перепахать, а поведение некоторых контролов переписать. Не имеет смысла заниматься оптимизацией интерфейса с самого начала (особенно разрабатывать собственные версии контролов), лучше заложить возможность этого этапа — сходные поведением элементы наследовать от общих классов, замыкать в классах логику поведения элементов.
Flash может работать по tcp/ip с чем угодно. Для MySQL уже написали — code.google.com/p/assql/
Толстый клиент на Fleх — это оригинально, но на практике может оказаться совершенно неприменимо.
Вы смеетесь? Ни в коем случае нельзя напрямую связывать флеш и бд. Это просто черная дыра в безопасности.
у нас есть четко означенная аудитория — операторы некой компании, а не кто угодно и откуда угодно.
совершенно верно.
да вообще все что касается безопасности, надо искать грань. есть люди которые говорят что подключаться к базе через ODBC не безопасно, ну возможно. Ну допустим что кто то узнает, захочет взломать и возможно даже взломает. Ценность информации низка, а в свою очередь откатим до предыдущего бэкапа и залатаем дыру. В принципе ничего страшного не случиться
да вообще все что касается безопасности, надо искать грань. есть люди которые говорят что подключаться к базе через ODBC не безопасно, ну возможно. Ну допустим что кто то узнает, захочет взломать и возможно даже взломает. Ценность информации низка, а в свою очередь откатим до предыдущего бэкапа и залатаем дыру. В принципе ничего страшного не случиться
Насчет отсутствия полноценных гридов конечно погорячились. Есть упомянутый ExtJS, есть много других вариантов. Смотря какие потребности.
Насчет скорости работы. Откройте gmail. Сколько у вас писем в ящике? У меня, например, несколько тысяч. И мне почему то не приходит в голову мысль, что как-то медленно все работает. Про Google Reader я вообще молчу. Почему этими вещами пользуются и не жалуются? Потому что многие вещи продуманы очень хорошо.
Вообще привязанность к гридам пришла со старой школы Win32 программирования. Особенно гриды со встроенными комбобоксами, картинками из blob полей и т.д. Это я сужу по своему опыту, не надо тут холивары разводить.
На мой взгляд вам нужно продумать интерфейс, хотя бы на бумажке с карандашом. Определить цепочку действий пользователя. Грид далеко не лучшее решение в 90% случаев. Оно возможно самое простое и первое приходит в голову. Если таблица, значит грид. Неправильно это. Попробуйте на на какое то время вообще забыть, что существует такой контрол, как грид. Попробуйте по другому представить интерфейс и взаимодействие с ним пользователя. Если ничего не придумаете или решение покажется неудобным, вернитесь к гриду.
А по поводу Flex мнение такое: не заморачивайте себе голову первым пришедшим на ум решением.
Потому что
a) не быстрее, если только у вас в команде нет гуру по Flex'у. Но если всплыла эта тема, я так понимаю, что нет.
б) не дешевле. хороших специалистов по по Flex'у надо еще поискать и стоить они будут явно недешево.
в) не дешевле. исходя из п.а и п.б — подумайте во что обойдется дальнейшая поддержка решения на Flex.
Насчет скорости работы. Откройте gmail. Сколько у вас писем в ящике? У меня, например, несколько тысяч. И мне почему то не приходит в голову мысль, что как-то медленно все работает. Про Google Reader я вообще молчу. Почему этими вещами пользуются и не жалуются? Потому что многие вещи продуманы очень хорошо.
Вообще привязанность к гридам пришла со старой школы Win32 программирования. Особенно гриды со встроенными комбобоксами, картинками из blob полей и т.д. Это я сужу по своему опыту, не надо тут холивары разводить.
На мой взгляд вам нужно продумать интерфейс, хотя бы на бумажке с карандашом. Определить цепочку действий пользователя. Грид далеко не лучшее решение в 90% случаев. Оно возможно самое простое и первое приходит в голову. Если таблица, значит грид. Неправильно это. Попробуйте на на какое то время вообще забыть, что существует такой контрол, как грид. Попробуйте по другому представить интерфейс и взаимодействие с ним пользователя. Если ничего не придумаете или решение покажется неудобным, вернитесь к гриду.
А по поводу Flex мнение такое: не заморачивайте себе голову первым пришедшим на ум решением.
Потому что
a) не быстрее, если только у вас в команде нет гуру по Flex'у. Но если всплыла эта тема, я так понимаю, что нет.
б) не дешевле. хороших специалистов по по Flex'у надо еще поискать и стоить они будут явно недешево.
в) не дешевле. исходя из п.а и п.б — подумайте во что обойдется дальнейшая поддержка решения на Flex.
Sign up to leave a comment.
Целесообразность использования Flex (RIA)