правильный проходящий.... и к базам данных, в общем, и к фоксу, в частности, не имеет никакого отношения?
Согласен с Вами на все 100%

Но если надо на спор используя только FoxPro и IIS можно вполне сделать то, что хочет автор. FoxPro - как COM object будет генерировать HTML code, который будет иметь два поля и button. Post Back будет снова обрабатываться FoxPro COM object... Но практической пользы от этого упражнения, увы, никакой...

alboro73Sergey Ch, от Вас я ожидал сравнительную характеристику на чем эффективней реализовать проект с учетом Вашего опыта. Не хочется делать лишних телодвижений для реализации проекта. Но не судьба. Будем вчитываться сравнивать, реализовывать.
Вы же сами уже ответили на свой вопрос - Windows server + IIS + ASP.NET + Visual FoxPro OleDbProvider (лучшее решение).

На практике же я использую MS Windows server + IIS + ASP.NET + C# .NET + MS SQL Server (если Вам интересно то, что я использую в реальной жизни). Код можно писать в NotePad но есть бесплатные легальные версии MS Visual Studio and MS SQL Server. Но как правильно было замечено выше - FoxPro тут ни причём и не надо обижаться. FoxPro был создан для решения других задач...

Good luck!

alboro73Sergey Ch, Спасибо. А по остальным пунктам, хоть кратко.

2.Web Services

-- в принципе рабочий вариант - просто "источник данных" в этом случае для Вашего FoxPro приложения будет web service. Главный недостаток - Ваши клиенты должны иметь "fat clients" в виде Вашего FoxPro приложения.

3. AFP(ActiveFoxproPages)

-- дорого, громоздко, неудобно и медленно. Авторы проекта отказались от его поддержки. Перспектив никаких в изучении того, что они "навояли" в своей "bedroom".

4.VAFP

-- не слышал

5.vfpcgi.dll

-- CGI approach на мой взгляд - "путь в никуда". Вам всё так-же будет нужен windows в котором уже будет IIS. Зачем "извращаться" когда Вам "прямо из коробки" уже даётся ASP или что ещё лучше ASP.NET.

6.foxisapi.dll

-- ещё один суррогат от MS в эпоху преддверия .NET. Я делал пару пректов, но мы потом быстро переключились на .NET так как MS рекомендовал. Кроме того Microsoft больше не поддерживает и не развивает эту технологию - в Вашем случае это будет нелогично использовать заведомо мёртвый продукт с самого начал...


Кстати, Вы не сказали - это для курсовой или это коммерческий проект?

Сергей, все хотел спросить. Неоднократно проскакивало, что на ASP.NET вы
приверженец веб- форм.

-- просто в этом случае Microsoft даёт Вам "из коробки" очень удобный инструмент для создания web приложения. Я так-же сделал несколько проектов на MVC и с использованием Web Api. Мне не очень понравилось так-как я не люблю тартить время на то, что уже в web forms уже есть. "Простота HTML" разметки может быть достигнута и другими способами.

-- сегодня вообще уже другая мода - почти весь UI пишется на Java Script с использованием большого количества "frameworks". Мне этот подход тоже не нравится, так как я считаю что весь HTML код должен генерировать сервер а browser просто корректно отображать.

-- другая проблема сегодня с web - это зоопарк browsers и устройств, использующих Ваше web application. До 90% времени народ трати на то, чтобы всё "смортрелось хорошо" на этом зоопарке.

Расскажите, если не сложно, какой технологией работаете с данными?

-- ADO 2.0 - я люблю контроль и ты всегла сам можешь сделать лучше чем чей-то сделанный в bedroom framework "заточенный" под все случаи жизни. .NET очень хороший инструмент для написания своего кода.

Используете ли Entity Framework?

-- делал несколько проектов, чтобы понять идеологию. Не понравилось. Это примерно как wizrd в FoxPro - a "black box" который не всегда делает то, что тебе надо. Отказался использовать в реальных проектах - при этом выигрыша времени от использования EF никакого. Но Вы должны знать как его использовать для прохождения work interview так это "fashionable trend" today...

Почему спрашиваю? Есть у меня несколько проектиков- сделано примитивно на SQlDataSource ( при этом все операции с данными в SP)

-- хороший подход. Я тоже всё оформляю в виде SP.

Так вот хотел бы узнать, как добрые люди делают...

-- у каждого свой подход.

Good luck!

Березовскийпро ClientMode для id элементов знаю. Чем еще можно "рулить" ?
На эту тему много статей и блогов написано.
Всё зависит от количество одновременных connections.

Самое главное - это хранить на сервере ViewState. Я его храню на диске File Share для маленьких сайтов. Если в день более 10 миллионов clicks то в кластерном кэше.

Березовский можете поделиться рецептом(ами)?
Использую мастер страницы у себя, да- удобно. Но мусору в html разметке от них просто избыток.
Трудно сказать - может быть пару hidden properties и всё... Всё остально зависит от Вас - что Вы поместите на Master page и будете "таскать" по всему сайту...

Если бы Вы показали Ваш проблемный сайт то можно было бы более предметно поговорить...

Да, кстати, в ASP.NET 5.0 вроде бы всё "в кучу" Microsoft "сведёт" MVC, WEB API & WEB form (они теперь их зовут по модному "Web pages")...

БерезовскийавторЕсли бы Вы показали Ваш проблемный сайт то можно было бы более предметно поговорить..
Да нет- проблем в общем то нет, просто имена и ID элементов в HTML разметке
немного напрягают при использовании мастер страниц, когда в производных страницах
элемент имеет


Я никогда не использую эти ID напрямую. Есть функция, котораая возвращает этот ID если Вам нужно манипулировать этим control. Хотя если разобраться - MS довольно creative & logically подошёл к вопросу создания unique id элементов. Всё это можно отключить начиная с .NET 4.0.

На мой взгляд надо просто не "перегружать" форму большим количеством элементов и "всё будет хорошо"... То есть как и в FoxPro подходить вдумчиво к созданию UI для конечного пользователя...