Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>>>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.
G>>>В эпоху тач устройств не важно.
А>>"тач устройства" только для баловства, а приложения бывают для работы

G>Работа, не связанная с набиранием текста, легко делается на тач устройствах.

photoshop, autocad, 3dmax легко ? ( если забыть про требуюмую мощность и размер экрана для производительной работы )

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Аноним, Вы писали:

А>>>Какие на ваш взгляд есть недостатки ?

А>>>Пока вижу 2

А>>>1) javascript — открытый код, то есть где он не будет удовлетворять требованиям безопасности придется отказываться от ajax в данных формах, в результате замедление отклика интерфейса.
G>>Как связаны ajax и безопасность?
А>ajax — реализация некой логики в javascript, который открыт для просмотра и изменения.
Для начала стоит посмотреть определение этого термина хотябы в википедии.

А>так и связаны, что можно подменить скрипт.
А>Если будешь сумму кошелька вычислять и хранить в javascript, то это врятли будет считаться безопасным решением.
В таком подходе у тебя много проблем и до безопасности будет.
А если ты сделаешь корректное приложение, то "подмена скрипта" уже не будет вектором атаки.

А>>>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.
G>>В эпоху тач устройств не важно.
А>Тач устройства пока не используются в промышленном виде, например когда приходишь в какуюнить контору ( банк например ) там операционист не на планшете твои данные вбивает, и врятли будет на планшете вбивать, требования к по в сбере например — любые действия чтобы можно было сделать по кнопкам без мыши. так быстрее.
Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Аноним, Вы писали:

А>>>>>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.
G>>>>В эпоху тач устройств не важно.
А>>>"тач устройства" только для баловства, а приложения бывают для работы

G>>Работа, не связанная с набиранием текста, легко делается на тач устройствах.

А>photoshop, autocad, 3dmax легко ? ( если забыть про требуюмую мощность и размер экрана для производительной работы )

У этих приложений интерфейс не адаптирован под тач, а вообще проблем не вижу.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, Аноним, Вы писали:

А>>>>Какие на ваш взгляд есть недостатки ?

А>>>>Пока вижу 2

А>>>>1) javascript — открытый код, то есть где он не будет удовлетворять требованиям безопасности придется отказываться от ajax в данных формах, в результате замедление отклика интерфейса.
G>>>Как связаны ajax и безопасность?
А>>ajax — реализация некой логики в javascript, который открыт для просмотра и изменения.
G>Для начала стоит посмотреть определение этого термина хотябы в википедии.

А>>так и связаны, что можно подменить скрипт.
А>>Если будешь сумму кошелька вычислять и хранить в javascript, то это врятли будет считаться безопасным решением.
G>В таком подходе у тебя много проблем и до безопасности будет.
G>А если ты сделаешь корректное приложение, то "подмена скрипта" уже не будет вектором атаки.
В асинхронных приложениях как правило не брезгуют кэшем значений и пр. , поэтому казалось бы только ассинхронность что тут опасного, но в любом случае для выполнения асинхронных запросов через javascript , одно дело когда отправил запрос http://mysite?page=10 и получил целиком страницу. Друое дело когда у тебя страница загружается ajax запросами, каждый торчащий лишний метод — уже дополнительная дырка для атаки.



А>>>>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.
G>>>В эпоху тач устройств не важно.
А>>Тач устройства пока не используются в промышленном виде, например когда приходишь в какуюнить контору ( банк например ) там операционист не на планшете твои данные вбивает, и врятли будет на планшете вбивать, требования к по в сбере например — любые действия чтобы можно было сделать по кнопкам без мыши. так быстрее.
G>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, Аноним, Вы писали:

А>>>>>>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.
G>>>>>В эпоху тач устройств не важно.
А>>>>"тач устройства" только для баловства, а приложения бывают для работы

G>>>Работа, не связанная с набиранием текста, легко делается на тач устройствах.

А>>photoshop, autocad, 3dmax легко ? ( если забыть про требуюмую мощность и размер экрана для производительной работы )

G>У этих приложений интерфейс не адаптирован под тач, а вообще проблем не вижу.
А чем же он тогда не адаптирован под тач ? Проблем много, одно дело когда нужно нажать 2 кнопки на клавиатуре, другое когда нужно лазить по меню.

Здравствуйте, Аноним, Вы писали:

А>В асинхронных приложениях как правило не брезгуют кэшем значений и пр. , поэтому казалось бы только ассинхронность что тут опасного, но в любом случае для выполнения асинхронных запросов через javascript , одно дело когда отправил запрос http://mysite?page=10 и получил целиком страницу. Друое дело когда у тебя страница загружается ajax запросами, каждый торчащий лишний метод — уже дополнительная дырка для атаки.
Смешались в кучу кони, люди...
Давай по отдельности:
1) Как кеширование значений влияет на безопасность?
2) Как количество эндпоинтов влияет на безопасность?

Вообще сейчас придет Владимир Кочетков и расскажет где ты неправ.



G>>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
А>Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.
Если у тебя 40 контролов и тебе более 80% надо ввести, тогда хоткеи тебе не помогут, все равно все надо вводить данные.
Если у тебя 40 контролов, но вводить надо <20%, то на кой на форме тогда 40 контролов, а не 8?

При правильном проектировании форм хоткеи не нужны, а при плохом и хоткеи не помогут.

Здравствуйте, Аноним, Вы писали:

А>>>photoshop, autocad, 3dmax легко ? ( если забыть про требуюмую мощность и размер экрана для производительной работы )

G>>У этих приложений интерфейс не адаптирован под тач, а вообще проблем не вижу.
А>А чем же он тогда не адаптирован под тач ? Проблем много, одно дело когда нужно нажать 2 кнопки на клавиатуре, другое когда нужно лазить по меню.
1) Модальностью интерфейса. Типа клик это одно, а ctrl+click другое.
2) Ориентацией на нажатие ПКМ.
3) Слишком маленькими anchor_ами для клика, в которые пальцем не попадешь.
4) Ориентацией на клавиатурный ввод.

Рекомендую глянуть OneNote MX и Grapholite приложения в Windows Marketplace. Они в правильном направлении идут.

Здравствуйте, Pavel Dvorkin, Вы писали:

А>>Какие на ваш взгляд есть недостатки ?

PD>Примитивизм. Достаточно сравнить MS Office и Google Docs.

Лучше сравни атлук и аутлук веб, оффис и оффис веб. Для многих разница незначительна.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>>>photoshop, autocad, 3dmax легко ? ( если забыть про требуюмую мощность и размер экрана для производительной работы )

G>>>У этих приложений интерфейс не адаптирован под тач, а вообще проблем не вижу.
А>>А чем же он тогда не адаптирован под тач ? Проблем много, одно дело когда нужно нажать 2 кнопки на клавиатуре, другое когда нужно лазить по меню.
G>1) Модальностью интерфейса. Типа клик это одно, а ctrl+click другое.
G>2) Ориентацией на нажатие ПКМ.
G>3) Слишком маленькими anchor_ами для клика, в которые пальцем не попадешь.
G>4) Ориентацией на клавиатурный ввод.

Дело тут не в ориентации нажатий на ПКМ, и прочем.
Например чтобы добавить новую сцену и создать на ней объект нажму Ctrl-N, Ctrl-O. Этого никакими концепциями OneNote MX не заменить.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>В асинхронных приложениях как правило не брезгуют кэшем значений и пр. , поэтому казалось бы только ассинхронность что тут опасного, но в любом случае для выполнения асинхронных запросов через javascript , одно дело когда отправил запрос http://mysite?page=10 и получил целиком страницу. Друое дело когда у тебя страница загружается ajax запросами, каждый торчащий лишний метод — уже дополнительная дырка для атаки.
G>Смешались в кучу кони, люди...
G>Давай по отдельности:
G>1) Как кеширование значений влияет на безопасность?\
можно подменить значение на клиенте и вмешаться в логику работы, а как это влияет на безопасность думаю объяснять не надо
G>2) Как количество эндпоинтов влияет на безопасность?
тут вопрос риторический, если знаком с теорией вероятностей то ответ очевиден. Каждый ендпоинт — дыра с определенным % критичных проблем, больше endpoint — больше общий % и возможностей для маневра.


G>>>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
А>>Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.
G>Если у тебя 40 контролов и тебе более 80% надо ввести, тогда хоткеи тебе не помогут, все равно все надо вводить данные.ъ
Ага, а если я ввел неправильно фамилию в 1м контроле , потом на середине это замечено и нужно исправить ? Табом лезть 20 нажатий ? Иногда при таком подходе случайно можно пролететь мимо и опять круг в 40 контролов давать. Нет уж спасибо.
Если обращал внимание на всех нормальных формах у лейблов есть подчеркнутая буква, которая является как раз быстрым хоткеем для данного поля.

G>Если у тебя 40 контролов, но вводить надо <20%, то на кой на форме тогда 40 контролов, а не 8?
Даже 8 контролов хоткей не помешает по причине приведенной выше. Если контролы раскиданы по закладкам то быстрый переход от одной закладки к другой тоже важен.

G>При правильном проектировании форм хоткеи не нужны, а при плохом и хоткеи не помогут.
Неверно. Хоткеи нужны практически всегда. Если это не программа перделка с одной кнопкой. Чтобы обеспечить быстрый доступ к сотне функций приложения.

Из рекомендаций MS:
Используйте насыщенные клиентские приложения, если:
 Приложение должно поддерживать сценарии без подключения или без постоянного подключения.
 Приложение будет развертываться на клиентских ПК.
 Приложение должно обеспечивать высокий уровень интерактивности и минимальное время отклика.
 UI приложения должен обеспечивать насыщенную функциональность и взаимодействие с пользователем, но без расширенных графических возможностей или возможностей воспроизведения мультимедиа RIA.
 Приложение должно использовать ресурсы клиентского ПК.

Используйте Веб-приложения, если:
 Приложению не требуется поддерживать насыщенный UI и мультимедиа, что предлагает насыщенное Интернет-приложение.
 Требуется обеспечить простую модель развертывания в Веб.
 Пользовательский интерфейс должен быть независимым от платформы.
 Приложение должно быть доступным через Интернет.
 Требуется максимально сократить зависимости на стороне клиента и потребление ресурсов, таких как дисковое пространство или вычислительные мощности процессора.

Здравствуйте, <Аноним>, Вы писали:

А>Впринципе о любых, которые нельзя выносить наружу.

Речь о standalone client-side приложениях или все же о полноценных веб, с серверной частью и HTTP-запросами?

Здравствуйте, gandjustas, Вы писали:

G>А с другой стороны есть facebook\vk\linkedin, десктопные клиенты которых до сих пор очень далеки до веб-версии. Просто исторически так сложилось, как и с Office.

Может быть, да, исторически сложилось. Но это как раз аргумент в мою пользу. Ну не сделали такой десктопный клиент, не надо.
А вот сделать все же Word/Excel в web-исполнении — не получается. Сделали бы, надо, но не могут.

PD>>Ну а насчет аналогов Photoshop или Autocad или чего-то вроде DevStudio, и т.д. в web-исполнении я не слышал. Если есть — дай ссылку.
G>Я тоже не слышал, но это абсолютно ни о чем не говорит.

А вот их, судя по всему, при нынешнем подходе к web-приложениям, просто нельзя сделать. Заметь, я не говорю "вообще нельзя". В принципе ясно, что можно. Только здесь надо заново продумать, что будет делаться на клиенте, а что на сервере, и как они обмениваться данными будут.

Вот есть такой текстовый редактор UltraEdit. Редактирует текстовые файлы любой длины, я с его помощью редактировал csv в сотни Мб. Ясно, что механизм отсылки этого файла на сервер и редактирования там с последующей отсылкой результата на клиент не проходит. Но на клиенте он вполне мог бы редактироваться и в web приложении, если бы web-приложение имело право прямо писать на клиент. А оно не имеет права по известным причинам...

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Аноним, Вы писали:

G>>Давай по отдельности:
G>>1) Как кеширование значений влияет на безопасность?\
А>можно подменить значение на клиенте и вмешаться в логику работы, а как это влияет на безопасность думаю объяснять не надо
Если значение кеша влияет на логику, то это уже не кеш, а что-то странное. У тебя быстрее другие проблемы возникнут при таком подходе.


G>>2) Как количество эндпоинтов влияет на безопасность?
А>тут вопрос риторический, если знаком с теорией вероятностей то ответ очевиден. Каждый ендпоинт — дыра с определенным % критичных проблем, больше endpoint — больше общий % и возможностей для маневра.
Модель угроз не строится на теории вероятностей.


G>>>>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
А>>>Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.
G>>Если у тебя 40 контролов и тебе более 80% надо ввести, тогда хоткеи тебе не помогут, все равно все надо вводить данные.ъ
А>Ага, а если я ввел неправильно фамилию в 1м контроле , потом на середине это замечено и нужно исправить ? Табом лезть 20 нажатий ? Иногда при таком подходе случайно можно пролететь мимо и опять круг в 40 контролов давать. Нет уж спасибо.
Про shift+tab не в курсе?

G>>Если у тебя 40 контролов, но вводить надо <20%, то на кой на форме тогда 40 контролов, а не 8?
А>Даже 8 контролов хоткей не помешает по причине приведенной выше. Если контролы раскиданы по закладкам то быстрый переход от одной закладки к другой тоже важен.
Закладки на формах ввода надо выжигать и делать клеймо тем, кто их придумал туда воткнуть.

G>>При правильном проектировании форм хоткеи не нужны, а при плохом и хоткеи не помогут.
А>Неверно. Хоткеи нужны практически всегда. Если это не программа перделка с одной кнопкой. Чтобы обеспечить быстрый доступ к сотне функций приложения.
Приложение с сотней функций делать нет смысла. Большинство из них не будут использованы.
Почитай about face алана купера.

Здравствуйте, Ikemefula, Вы писали:


PD>>Примитивизм. Достаточно сравнить MS Office и Google Docs.

I>Лучше сравни атлук и аутлук веб, оффис и оффис веб. Для многих разница незначительна.

Согласен, многих устраивает. Я же не говорю, что они вообще никуда не годятся. Просто они примитивны по сравнению с десктопными. Но многих, да, этот примитив устраивает.
Кого-то и Word времен MS-DOS вполне устраивал.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Аноним, Вы писали:

А>>>>>photoshop, autocad, 3dmax легко ? ( если забыть про требуюмую мощность и размер экрана для производительной работы )

G>>>>У этих приложений интерфейс не адаптирован под тач, а вообще проблем не вижу.
А>>>А чем же он тогда не адаптирован под тач ? Проблем много, одно дело когда нужно нажать 2 кнопки на клавиатуре, другое когда нужно лазить по меню.
G>>1) Модальностью интерфейса. Типа клик это одно, а ctrl+click другое.
G>>2) Ориентацией на нажатие ПКМ.
G>>3) Слишком маленькими anchor_ами для клика, в которые пальцем не попадешь.
G>>4) Ориентацией на клавиатурный ввод.

А>Дело тут не в ориентации нажатий на ПКМ, и прочем.
А>Например чтобы добавить новую сцену и создать на ней объект нажму Ctrl-N, Ctrl-O. Этого никакими концепциями OneNote MX не заменить.

А ты вообще смотрел OneNote mx прежде чем писать? Похоже что нет.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, gandjustas, Вы писали:

G>>А с другой стороны есть facebook\vk\linkedin, десктопные клиенты которых до сих пор очень далеки до веб-версии. Просто исторически так сложилось, как и с Office.

PD>Может быть, да, исторически сложилось. Но это как раз аргумент в мою пользу. Ну не сделали такой десктопный клиент, не надо.
PD>А вот сделать все же Word/Excel в web-исполнении — не получается. Сделали бы, надо, но не могут.
А ты webapps не видел? Сделали уже, около 40% функций десктопной реализует. Для аутлука почти 100%.потому что owa появилась в 1996 году, а webapps в 2010.

Причём если бы изначально офис делали для веба, то ситуация получилась бы обратная.

PD>>>Ну а насчет аналогов Photoshop или Autocad или чего-то вроде DevStudio, и т.д. в web-исполнении я не слышал. Если есть — дай ссылку.
G>>Я тоже не слышал, но это абсолютно ни о чем не говорит.

PD>А вот их, судя по всему, при нынешнем подходе к web-приложениям, просто нельзя сделать. Заметь, я не говорю "вообще нельзя". В принципе ясно, что можно. Только здесь надо заново продумать, что будет делаться на клиенте, а что на сервере, и как они обмениваться данными будут.
Да все можно, на сервере надо минимум.

PD>Вот есть такой текстовый редактор UltraEdit. Редактирует текстовые файлы любой длины, я с его помощью редактировал csv в сотни Мб. Ясно, что механизм отсылки этого файла на сервер и редактирования там с последующей отсылкой результата на клиент не проходит. Но на клиенте он вполне мог бы редактироваться и в web приложении, если бы web-приложение имело право прямо писать на клиент. А оно не имеет права по известным причинам...
Ты про FileApi не в курсе? Твои знания устарели года на 3, почитай что браузеры сейчас умеют, удивишься...

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, Аноним, Вы писали:

G>>>Давай по отдельности:
G>>>1) Как кеширование значений влияет на безопасность?\
А>>можно подменить значение на клиенте и вмешаться в логику работы, а как это влияет на безопасность думаю объяснять не надо
G>Если значение кеша влияет на логику, то это уже не кеш, а что-то странное. У тебя быстрее другие проблемы возникнут при таком подходе.

Кэш в любом случае влияет на логику, т.к. он используется в каком либо коде, иначе он не нужен вообще.


G>>>2) Как количество эндпоинтов влияет на безопасность?
А>>тут вопрос риторический, если знаком с теорией вероятностей то ответ очевиден. Каждый ендпоинт — дыра с определенным % критичных проблем, больше endpoint — больше общий % и возможностей для маневра.
G>Модель угроз не строится на теории вероятностей.
Ага, только причем тут модель угроз, речь о вероятности взлома, которая увеличивается от количества дырок.

G>>>>>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
А>>>>Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.
G>>>Если у тебя 40 контролов и тебе более 80% надо ввести, тогда хоткеи тебе не помогут, все равно все надо вводить данные.ъ
А>>Ага, а если я ввел неправильно фамилию в 1м контроле , потом на середине это замечено и нужно исправить ? Табом лезть 20 нажатий ? Иногда при таком подходе случайно можно пролететь мимо и опять круг в 40 контролов давать. Нет уж спасибо.
G>Про shift+tab не в курсе?
Какая разница 20 нажатий вверх, или вниз. Проблемы которые описаны остануться.



G>>>Если у тебя 40 контролов, но вводить надо <20%, то на кой на форме тогда 40 контролов, а не 8?
А>>Даже 8 контролов хоткей не помешает по причине приведенной выше. Если контролы раскиданы по закладкам то быстрый переход от одной закладки к другой тоже важен.
G>Закладки на формах ввода надо выжигать и делать клеймо тем, кто их придумал туда воткнуть.

G>>>При правильном проектировании форм хоткеи не нужны, а при плохом и хоткеи не помогут.
А>>Неверно. Хоткеи нужны практически всегда. Если это не программа перделка с одной кнопкой. Чтобы обеспечить быстрый доступ к сотне функций приложения.
G>Приложение с сотней функций делать нет смысла. Большинство из них не будут использованы.
G>Почитай about face алана купера.
Скажи как сделать 3дмакс из 3х функций, потом говори глупости

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Аноним, Вы писали:

А>>>Здравствуйте, gandjustas, Вы писали:

G>>>>Здравствуйте, Аноним, Вы писали:

G>>>>Давай по отдельности:
G>>>>1) Как кеширование значений влияет на безопасность?\
А>>>можно подменить значение на клиенте и вмешаться в логику работы, а как это влияет на безопасность думаю объяснять не надо
G>>Если значение кеша влияет на логику, то это уже не кеш, а что-то странное. У тебя быстрее другие проблемы возникнут при таком подходе.

А>Кэш в любом случае влияет на логику, т.к. он используется в каком либо коде, иначе он не нужен вообще.
А что мешает кеш в толстом клиенте поправить у десктопного приложения, если он на логику влияет? В чем разница с вебом будет?



G>>>>2) Как количество эндпоинтов влияет на безопасность?
А>>>тут вопрос риторический, если знаком с теорией вероятностей то ответ очевиден. Каждый ендпоинт — дыра с определенным % критичных проблем, больше endpoint — больше общий % и возможностей для маневра.
G>>Модель угроз не строится на теории вероятностей.
А>Ага, только причем тут модель угроз, речь о вероятности взлома, которая увеличивается от количества дырок.
Если у тебя нет модели угроз, то как ты можешь вероятность чего-либо найти? Прочитай чтонить про ИБ для начала. У тебя очень дилетантские суждения.

G>>>>>>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
А>>>>>Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.
G>>>>Если у тебя 40 контролов и тебе более 80% надо ввести, тогда хоткеи тебе не помогут, все равно все надо вводить данные.ъ
А>>>Ага, а если я ввел неправильно фамилию в 1м контроле , потом на середине это замечено и нужно исправить ? Табом лезть 20 нажатий ? Иногда при таком подходе случайно можно пролететь мимо и опять круг в 40 контролов давать. Нет уж спасибо.
G>>Про shift+tab не в курсе?
А>Какая разница 20 нажатий вверх, или вниз. Проблемы которые описаны остануться.
Промахнуться не проблема, а кнопку tab можно ооооочень быстро нажимать. Не обращал внимание как в ПФ в досовском интерфейсе данные вбивают?


G>>Почитай about face алана купера.
А>Скажи как сделать 3дмакс из 3х функций, потом говори глупости
Ты же не 3dmax делаешь, даже близко не похожее на него.
Почитай купера, там многие ответы на твои вопросы.

Здравствуйте, gandjustas, Вы писали:

G>А ты webapps не видел? Сделали уже, около 40% функций десктопной реализует. Для аутлука почти 100%.потому что owa появилась в 1996 году, а webapps в 2010.

Outlook не аргумент, почта — примитив по сравнению с редактированием. В сущности, в почтовом десктопном клиенте уже лет 15 по большому счету ничего не меняется, нечего там менять.

G>Причём если бы изначально офис делали для веба, то ситуация получилась бы обратная.

Вряд ли. Во времена DOS, когда Word начался, его просто не могли делать. Да и до Word редакторов хватало, и до Excel электронные таблицы были, так что MS должна была уже тогда как минимум их возможности повторить. А Web тогда был в состоянии статических страниц.

PD>>А вот их, судя по всему, при нынешнем подходе к web-приложениям, просто нельзя сделать. Заметь, я не говорю "вообще нельзя". В принципе ясно, что можно. Только здесь надо заново продумать, что будет делаться на клиенте, а что на сервере, и как они обмениваться данными будут.
G>Да все можно, на сервере надо минимум.

Можно, но именно минимум. А сейчас не минимум.

PD>>Вот есть такой текстовый редактор UltraEdit. Редактирует текстовые файлы любой длины, я с его помощью редактировал csv в сотни Мб. Ясно, что механизм отсылки этого файла на сервер и редактирования там с последующей отсылкой результата на клиент не проходит. Но на клиенте он вполне мог бы редактироваться и в web приложении, если бы web-приложение имело право прямо писать на клиент. А оно не имеет права по известным причинам...
G>Ты про FileApi не в курсе? Твои знания устарели года на 3, почитай что браузеры сейчас умеют, удивишься...

Не был в курсе. Спасибо. Посмотрел. Только вот такой вопрос

http://www.w3.org/TR/FileAPI/

FileReader там есть. А вот FileWriter я не нашел. Его нет ? Если нет, то для редактирования на клиенте это не годится — см. выше мой пример с UltraEdit хотя бы, да и не только.