Повторное использование кода, это основа основ профессионального программирования. Не думаю, что только вы сумели добиться его с помощью UI-компонент.
Давайте отделим мясные продукты от насекомых. Что вы делаете?
Серверный фреймворк?
Или клиентский интерфейс?
PS. К сожалению, на моём горьком опыте, любая попытка программистов облегчить жизнь дизайнерам-верстальщикам, не узнав их мнения, заканчивалась плачевно.
Сгладить полностью нюансы HTTP и кроссбраузерности сможет только кардинальная переработка HTTP и захват 90% рынка браузеров одним.
Попытки построить над всем этим какую-то абстракцию предпринимались не раз и не только питерскими дизайн-студиями, но и, например, корпорацией MicroSoft.
Некоторые продукты довольно забавны — позволяют слобоквалифицированному программисту собрать готовый сайт из стандартных компонент.
Но при сложном программировании отрешение от самих основ архитектуры ни к чему хорошему не ведет.
Данная статья и комментарии к ней совершенно четко иллюстрирует отношение большинства программистов к БД.
Для одних, это что-то страшное. Они лучше будут извращаться с файлами, чем потратят день на изучение основ SQL. Разобравшись через некоторое время, чем отличается веб-приложение от обычного, они будут извращаться с блокировками файлов, но не будут разбираться с БД.
Другим кто-то сказал, что БД лучше всех альтернатив по всем параметрам. И они в это свято верят. Когда им говоришь, что запись и чтение из файла может быть быстрее, чем запрос к базе, они смотрят на тебя широко распахнутыми глазами, как на психа с которым и разговаривать нечего.
Вобще-то MVC как раз для того и используется, чтобы программист не верстал HTML.
Верстать должен верстальщик. А сам движок не должен изображать из себя верстальщика — ничего хорошего из этого не выйдет.
Отслеживанием же положения мыши занимается ОС клиента и движок его браузера. Вашего ответа я не понял. Я обратил внимание на то, что вы пытаетесь делать то, что вам не понравилось в MVC.
Создание же страницы из стандартных элементов, со стандартным поведением, это, скорее всего, JS-UI-библиотека, возможно, с некоторой серверной PHP-прослойкой.
То же, что называется "фреймворк", "движок" и т.п. должно работать в другой области — в хранении, преобразовании и выдаче данных, разделении привилегий, отслеживании сеансов, формировании вывода.
У PHP не должно быть никаких кнопок, контроллов и т.п. У него есть запрос, он должен отдать ответ и всё.
Если в этом самом конечном ответе будет задействован тот же JS-UI-немногоPHP-фреймворк, пожалуйста.
Смотря в чем.
В распространенности, удобстве и т.п? Хз. я не об этом.
Догнал, не догнал, он основан по прежнему на клиент-серверной архитектуре и протоколе HTTP.
С одной стороны, наконец, кто-то не побоялся сказать страшную вещь: "Классические реализации MVC, не лучшим образом подходят для предметной области PHP". Потому что разработаны они изначально для десктопных графических приложений.
С другой, отказавшись от MVC, начали заниматься тем же самым — попыткой подогнать веб-систему под тот же десктоп.
Можно еще картинки подгружать, а данные кодировать в их ширине/высоте.
Сам трюк древний, ознакомьтесь с JSON.
document.getElementsByTagName('head')[0].appendChild(script)
до полной загрузки HEAD некоторые браузеры могут сглючить. Лучше insertBefore перед firstChildом HEAD.
А еще желательно знать, что PHP может быть установлен, как модули или как CGI, а в CGI нельзя устанавливать код ответа — нужно посылать "Status: 404 Not Found", чтобы апач сам с ним разбирался.
Что такое HTTP и его код ответа, какой код ответа указывает отсутствие документа и как HTTP-заголовки устанавливаются в PHP веб-программист знать обязан.
Не должны. Особенно с учетом того, что утечки происходят не у них, а у пользователей, которые, кстати, просто загрузили html-страницу и не заказывали никаких сценариев.
То есть, конечно, с учетом того, что утечки есть, вменяемые разработчики должны знать приемы борьбы, но это не снимает ответственности с создателей движка.
И не вижу разницы между отслеживанием десяти объектов и тысячи.
Давайте отделим мясные продукты от насекомых. Что вы делаете?
Серверный фреймворк?
Или клиентский интерфейс?
PS. К сожалению, на моём горьком опыте, любая попытка программистов облегчить жизнь дизайнерам-верстальщикам, не узнав их мнения, заканчивалась плачевно.
Попытки построить над всем этим какую-то абстракцию предпринимались не раз и не только питерскими дизайн-студиями, но и, например, корпорацией MicroSoft.
Некоторые продукты довольно забавны — позволяют слобоквалифицированному программисту собрать готовый сайт из стандартных компонент.
Но при сложном программировании отрешение от самих основ архитектуры ни к чему хорошему не ведет.
Для одних, это что-то страшное. Они лучше будут извращаться с файлами, чем потратят день на изучение основ SQL. Разобравшись через некоторое время, чем отличается веб-приложение от обычного, они будут извращаться с блокировками файлов, но не будут разбираться с БД.
Другим кто-то сказал, что БД лучше всех альтернатив по всем параметрам. И они в это свято верят. Когда им говоришь, что запись и чтение из файла может быть быстрее, чем запрос к базе, они смотрят на тебя широко распахнутыми глазами, как на психа с которым и разговаривать нечего.
Верстать должен верстальщик. А сам движок не должен изображать из себя верстальщика — ничего хорошего из этого не выйдет.
Отслеживанием же положения мыши занимается ОС клиента и движок его браузера. Вашего ответа я не понял. Я обратил внимание на то, что вы пытаетесь делать то, что вам не понравилось в MVC.
Создание же страницы из стандартных элементов, со стандартным поведением, это, скорее всего, JS-UI-библиотека, возможно, с некоторой серверной PHP-прослойкой.
То же, что называется "фреймворк", "движок" и т.п. должно работать в другой области — в хранении, преобразовании и выдаче данных, разделении привилегий, отслеживании сеансов, формировании вывода.
У PHP не должно быть никаких кнопок, контроллов и т.п. У него есть запрос, он должен отдать ответ и всё.
Если в этом самом конечном ответе будет задействован тот же JS-UI-немногоPHP-фреймворк, пожалуйста.
В распространенности, удобстве и т.п? Хз. я не об этом.
Догнал, не догнал, он основан по прежнему на клиент-серверной архитектуре и протоколе HTTP.
С другой, отказавшись от MVC, начали заниматься тем же самым — попыткой подогнать веб-систему под тот же десктоп.
Сам трюк древний, ознакомьтесь с JSON.
document.getElementsByTagName('head')[0].appendChild(script)
до полной загрузки HEAD некоторые браузеры могут сглючить. Лучше insertBefore перед firstChildом HEAD.
Программисты или интерпретаторы?
Вам нужно конкретно сформулировать вопрос и обратиться на специализированный форум.
И правильно. Кстати, JS и куки тоже можно отключить, а браузер закрыть.
То есть, конечно, с учетом того, что утечки есть, вменяемые разработчики должны знать приемы борьбы, но это не снимает ответственности с создателей движка.
И не вижу разницы между отслеживанием десяти объектов и тысячи.