Здравствуйте.
Есть задача спроектировать интерфейс некой системы для внутренних целей компании.
Клиентом является IE соответственно web интерфейс.
По структуре все укладывается в интерфейс с тремя фреймами (левый-меню, и два других с информацией),
как и на RSDN.RU.
Но интересно можно ли обойти фреймовую структуру, и насколько это нужно.
Скорее насколько это правильнее с точки зрения удобства (про back и refresh все ясно).
В ASP.NET 2 появились masterpage соответственно на их основе все делается без фреймов.
Нужно ли отказываться от фреймов?

Спасибо.

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

А>Здравствуйте.
А>Есть задача спроектировать интерфейс некой системы для внутренних целей компании.
А>Клиентом является IE соответственно web интерфейс.
[SKIPPED]
А>Нужно ли отказываться от фреймов?

Для внутренних целей ИМХО не нужно, потому что фрэймы штука достаточно удобная, если содержимое одного фрэйма не требуется изменять в процессе перезагрузки информации в другом фрэйме. Например, когда в одном месте стоит общее меню, а в другом, собственно, приложение.

От фрэймов стоит отказываться, если для этого есть какие-то нефункциональные требования, например, когда в инете нужно подстраиваться под поисковики, или когда содержимое, планируемое для размещения во фрэймы, сильно зависит друг от друга и должно одновременно перегенерироваться одним приложением.

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

S>От фрэймов стоит отказываться, если для этого есть какие-то нефункциональные требования, например, когда в инете нужно подстраиваться под поисковики, или когда содержимое, планируемое для размещения во фрэймы, сильно зависит друг от друга и должно одновременно перегенерироваться одним приложением.

А Ajax на что? Тем более, что IE...

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

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

S>>От фрэймов стоит отказываться, если для этого есть какие-то нефункциональные требования, например, когда в инете нужно подстраиваться под поисковики, или когда содержимое, планируемое для размещения во фрэймы, сильно зависит друг от друга и должно одновременно перегенерироваться одним приложением.

С>А Ajax на что? Тем более, что IE...

Ajax, конечно можно использовать, но необходимости в нём не вижу, поскольку:

— что касается поисковиков, то Ajax, по ходу — зло, поскольку не ловится роботами (могу заблуждаться, конечно, но очень на то похоже из общих соображений, так что оставляю вопрос открытым);

— для использования Ajax требуется дополнительный напряг, как то: библиотеки, специфический подход к разработке, который не очень то поддерживается в существующих средствах разработки и т.п., не говоря уже о необходимости более точного архитектурного моделирования приложения);

— скорости загрузки на локальной сети (а внутренние сети компании как правило таковыми и являются, если это не глобальная компания) хватает для быстрой перезагрузки;

— исходя из предыдущего замечания предполагается, что при использовании Ajax instead традиционные методы бюджет проекта увеличится, а на внутренние разработки он, как правило, и так минимизируется, что чревато...

В общем, не нужен здесь Ajax, если он не требуется специально для специфических requirements приложения или подцелью проекта не является его изучение.

Вот )

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

S>В общем, не нужен здесь Ajax, если он не требуется специально для специфических requirements приложения или подцелью проекта не является его изучение.

Тоже верно, но если необходимые средства есть, имхо лучше им. С фреймами тож гемороя полно.

S>>>От фрэймов стоит отказываться, если для этого есть какие-то нефункциональные требования, например, когда в инете нужно подстраиваться под поисковики, или когда содержимое, планируемое для размещения во фрэймы, сильно зависит друг от друга и должно одновременно перегенерироваться одним приложением.

С>>А Ajax на что? Тем более, что IE...

S>Ajax, конечно можно использовать, но необходимости в нём не вижу, поскольку:

S>- что касается поисковиков, то Ajax, по ходу — зло, поскольку не ловится роботами (могу заблуждаться, конечно, но очень на то похоже из общих соображений, так что оставляю вопрос открытым);

Такое утверждение верно в общем случае, когда Аяксовые вызовы выглядят примерно так:

<a href="#" onclick="performAjaxAction();">Ссылка</a>

При определенной сноровке/опыте/фреймворке можно все ссылки сделать читаемыми и индексируемыми:

<script>
function performAjaxAction()
{
    //
    // ...
    //
    
    return false();
}
</script>

<a href="path/to/action/" onclick="performAjaxAction();">Ссылка</a>

Второй подход используется, например в Ruby on Rails. В таком случае надо немного поднапрячься для создания, собственно, двух версий сайта — одну Аяксовую (возвращающую по запросу JSON или там XML), и одну — полностью генерирующую все содерживмое в виде HTML

S>- для использования Ajax требуется дополнительный напряг, как то: библиотеки, специфический подход к разработке, который не очень то поддерживается в существующих средствах разработки и т.п., не говоря уже о необходимости более точного архитектурного моделирования приложения);

+1