Комментарии 57
Что-то на сайте ни один пример не заработал.
все три примера рабочие. Проверено в chrome, ff, opera
Они просто ооооочень долго грузятся.
Это точно. Оптимизация еще предстоит
Эх, уже в третий раз за пол года haxe клонируют… Кто следующий?
дико извиняюсь, что такого языка не знал. А на haxe можно desktop приложение написать? И если можно, то как нас это продвинет к идее перевода pascal->js?
Да, haxe поддерживает компиляцию в cpp, который компилируетс в exe. Также есть проект nekonme который эмулирует практически полное flash 9 api для всех платформ, даже для мобильных телефонов(смартфонов). Чтобы особо не пиарить малоизвестную бесплатную платформу кидаю ссылочку haxe.ru
Цель — безболезненное портирование существующего млн строк дельфей, а не создание нового на хаксе.
Ну учитывая платность ext.js не каждый программист сможет себе это позволить в коммерческих целях. Я лишь привел бесплатную альтернативу. Лучше б они qooxdoo за основу взяли.
Или SproutCore
Выглядит круто. Видно, что работа проделана огромная. Этот инструмент может стать востребованным, ведь сейчас есть тенденция переносить приложения в браузер, а программ, написанных на Delphi, всё еще много.
А элементы позиционируются в окне абсолютно? Или layout-ы тоже поддерживаются? (Честно говоря, не знаю, есть ли в Delphi layout-ы.)
А элементы позиционируются в окне абсолютно? Или layout-ы тоже поддерживаются? (Честно говоря, не знаю, есть ли в Delphi layout-ы.)
НЛО прилетело и опубликовало эту надпись здесь
Как насчет лицензирования? на сайте ExtJS указано что построители приложений лицензируются особо и сумма рассчитывается отдельно для каждого случая.
Любопытно. А как быть со сторонними VCL компонентами например такими монстрами как QuantumGrid от DevExpress?
А вы подготовили свой сайт у хабраэффекту, ведь мы зайдем к вам!? (с)
Сейчас занимаюсь переводом одного крупного проекта на веб морду. И тоже delphi, и тоже ExtJS.
По сути, я пошел путём преобразования одного клиента — в 1 сессию веб-сервера. Сам веб-сервер — обертка вокруг сессий. JS — только отображение, и немножко бизнес-логики. Уже всё почти работает).
И вот что я скажу:
1. Графику перевести можно, не беда, хоть и мороки много. Может даже получится перенести бизнес-логику, но спец. фичи с участием WinAPI — никогда. Например, потоки, select, mutex… Можно сделать аналоги, но работать так же оно не будет, а вносить изменение в транслированный код — чревато последствиями. Вот еще Midas, всякие сетевые датасеты. Печаль.
2. Рефакторинг модальных окон. Из-за модальных окон, в своем проекте я отказался от ExtPasal, запилил собственный веб-сервер и собственную логику потоков, сокетов, прочего. И в итоге модальность оставил. То, что вы сделали на js — «Браво!», жаль на самом Delphi так делать нельзя.
3. Я думаю, что нужно будет скоро заниматься трансляцией в JS внутреннего скриптового языка, но уж явно не самого Delphi кода, это просто невозможно в полной мере.
4. ExtJS – что-то, что любит плодить DOM элементы. Мы в своем проекте очень аккуратно относимся к их количеству. А вы не можете, потому что не контролируете код javascript. Более того, код js нуждается в дополнительных обработках (чтоб окно за пределы родительского окна нельзя было выпилить; чтоб CSS классы не перемешивались от чрезмерного указывания кто кому предок), и код js в большинстве случаев не нуждается в приколах delphi. По сути, я уверен, что после генерации получается куча мусора и куча недоработок, из-за чего оно работает медленно и не правильно.
Я понимаю сложность работы, снимаю шляпу перед разработчиками, и при этом не рискну подпустить эту штуку к своему проекту.
По сути, я пошел путём преобразования одного клиента — в 1 сессию веб-сервера. Сам веб-сервер — обертка вокруг сессий. JS — только отображение, и немножко бизнес-логики. Уже всё почти работает).
И вот что я скажу:
1. Графику перевести можно, не беда, хоть и мороки много. Может даже получится перенести бизнес-логику, но спец. фичи с участием WinAPI — никогда. Например, потоки, select, mutex… Можно сделать аналоги, но работать так же оно не будет, а вносить изменение в транслированный код — чревато последствиями. Вот еще Midas, всякие сетевые датасеты. Печаль.
2. Рефакторинг модальных окон. Из-за модальных окон, в своем проекте я отказался от ExtPasal, запилил собственный веб-сервер и собственную логику потоков, сокетов, прочего. И в итоге модальность оставил. То, что вы сделали на js — «Браво!», жаль на самом Delphi так делать нельзя.
3. Я думаю, что нужно будет скоро заниматься трансляцией в JS внутреннего скриптового языка, но уж явно не самого Delphi кода, это просто невозможно в полной мере.
4. ExtJS – что-то, что любит плодить DOM элементы. Мы в своем проекте очень аккуратно относимся к их количеству. А вы не можете, потому что не контролируете код javascript. Более того, код js нуждается в дополнительных обработках (чтоб окно за пределы родительского окна нельзя было выпилить; чтоб CSS классы не перемешивались от чрезмерного указывания кто кому предок), и код js в большинстве случаев не нуждается в приколах delphi. По сути, я уверен, что после генерации получается куча мусора и куча недоработок, из-за чего оно работает медленно и не правильно.
Я понимаю сложность работы, снимаю шляпу перед разработчиками, и при этом не рискну подпустить эту штуку к своему проекту.
Мы четко разделяем компоненты и приложения, которые из этих компонентов состоят. Для библиотек мы делаем js-обертки ручками, поэтому работаем с Ext не напрямую (так как, согласен, Sencha — любители dom). Сами приложения у нас «тупенькие». Никакой многопоточности, сокетов, win api и др. изысков. Единственная заморока — модальные диалоги. Над ними долго трудились.
С датасетами все отлично. Просто у нас собственный сервер приложений, который обеспечивает доступ к данным. С ClientDataSet тоже хорошо получилось. Сделали на js — скорость неплохая (сами удивились).
>жаль на самом Delphi так делать нельзя.
Над этим не думал. Поразмышляю на досуге
>Delphi кода, это просто невозможно в полной мере.
Да все прекрасно работает, не сомневайтесь. И dfm мы разбираем и var|оut аргументы. И события и все все…
Вы, наверное, путаете синтаксис языка и runtime library? Синтаксис поддерживается в полной мере.
>и код js в большинстве случаев не нуждается в приколах delphi.
Вы абсолютно точно это подметили, но на уровне прикладных программ приколов delphi и не нужно. По крайней мере в наших задачах.
С датасетами все отлично. Просто у нас собственный сервер приложений, который обеспечивает доступ к данным. С ClientDataSet тоже хорошо получилось. Сделали на js — скорость неплохая (сами удивились).
>жаль на самом Delphi так делать нельзя.
Над этим не думал. Поразмышляю на досуге
>Delphi кода, это просто невозможно в полной мере.
Да все прекрасно работает, не сомневайтесь. И dfm мы разбираем и var|оut аргументы. И события и все все…
Вы, наверное, путаете синтаксис языка и runtime library? Синтаксис поддерживается в полной мере.
>и код js в большинстве случаев не нуждается в приколах delphi.
Вы абсолютно точно это подметили, но на уровне прикладных программ приколов delphi и не нужно. По крайней мере в наших задачах.
Можно поинтересоваться? А вот delphi вроде как отходит на второй план и потихоньку загибается. стоит ли для него такие проекты писать?
Безусловно интересно как тут происходит работа с базой данных и прочими вещами как это разносится на клиентскую и серверную части.
И конечно хочется тестов производиельности ))
А нет ли смысла перейти с delphi на java а там и GWT есть, который уже себя зарекомендовал?
Безусловно интересно как тут происходит работа с базой данных и прочими вещами как это разносится на клиентскую и серверную части.
И конечно хочется тестов производиельности ))
А нет ли смысла перейти с delphi на java а там и GWT есть, который уже себя зарекомендовал?
Промышленные программные продукты не создаются, а «прорастают». Они растут годами, под влиянием множества программистов, разной квалификации. Ну и в какой-то момент может возникнуть идея — а что если все это выбросить и начать заново. Например, на каком-нибудь современном продвинутом языке. Сколько таких попыток видел — все неудачные. Почему? Да фиг знает. Медицинский факт. Наверное, потому что бизнес-логика никуда при этом не девается, а заменятся но новый вариант с новыми багами, после чего дерево нужно опять начинать растить.
>интересно как тут происходит работа с базой данных
сервер приложений принимает soap-запросы в которых передается sql или ХП с параметрами. Обратно возвращается ответ сериализованный в json. Такой вот сетевой аналог JDBC.
>И конечно хочется тестов производиельности
Пока плохо
>А нет ли смысла перейти с delphi на java а там и GWT есть,
может когда-нибудь?
>интересно как тут происходит работа с базой данных
сервер приложений принимает soap-запросы в которых передается sql или ХП с параметрами. Обратно возвращается ответ сериализованный в json. Такой вот сетевой аналог JDBC.
>И конечно хочется тестов производиельности
Пока плохо
>А нет ли смысла перейти с delphi на java а там и GWT есть,
может когда-нибудь?
А Вы случайно не пробовали использовать Node JS, а не просто JavaScript на стороне клиента?
Маленький баг — tooltip Свернуть, Развернуть, Закрыть отображаются за окнами.
Chrome 16.0.889
Chrome 16.0.889
> А можно транслировать и иметь решение на обеих платформах.
Если вопрос стоял именно о поддержке других платформ, а не запуска в браузере, то не проще ли было заюзать Lazarus?
Если вопрос стоял именно о поддержке других платформ, а не запуска в браузере, то не проще ли было заюзать Lazarus?
Вариант рассматривался. Но решение в браузере имеет еще кучу всяких плюсов, не правда ли?
Да, но в реализации сложнее. Впрочем вам виднее.
Кстати, а проекты lazarus я так понял не поддерживаются? Я попробовал загрузить свою поделку, как раз сейчас курсач на нем пишу, не получилось.
Кстати, а проекты lazarus я так понял не поддерживаются? Я попробовал загрузить свою поделку, как раз сейчас курсач на нем пишу, не получилось.
Lazarus просто не пробовали. Вышлите проект, если это возможно. Я обещаю попробовать
Конкретно мой проект пробовать нет смысла, так как это GUI к sipcalc, которого на вашей машине может не оказатся. Впрочем пустой проект тоже не транслировался. db.tt/1q8Jr47h
Совет: раз уж вы парсите Delphi — генерите байт-код, а на JavaScript напишите VM для этого байт-кода.
а как же работа в браузере?
JS и выполняет этот байткод в браузере.
На этом принципе куча браузерных эмуляторов построено вроде NES.
shambho предлагает вместо трансляции производить эмуляцию.
На этом принципе куча браузерных эмуляторов построено вроде NES.
shambho предлагает вместо трансляции производить эмуляцию.
Это интересно. Сразу идею shambho не понял. Спасибо
НЛО прилетело и опубликовало эту надпись здесь
Только по-видимому команды в VM должны быть достаточно высокоуровневыми, объектными, как в Java или .NET.
В качестве учебника порекомендовал бы Свердлова — «Языки программирования и методы трансляции», в книге приведены исходники компилятора Oberon-0 (подмножества Oberon — наследника Pascal-а от того же Вирта) на нескольких языках (Java, Delphi, C++, C#). Реализуется стековая VM похожая на Forth.
В качестве учебника порекомендовал бы Свердлова — «Языки программирования и методы трансляции», в книге приведены исходники компилятора Oberon-0 (подмножества Oberon — наследника Pascal-а от того же Вирта) на нескольких языках (Java, Delphi, C++, C#). Реализуется стековая VM похожая на Forth.
Спорная работа с точки зрения качества и целесообразности, но явно сильная и интересная. А плюсиков маловато, мало кто осилил. Кончилось время технарей, набегает школота, дизайнеры, управленцы, бездари, выродки, глупцы… обидно даже как-то.
Весьма оригинальная вещь, но также весьма бесполезная. Она позволяет транслировать в JS/HTMl только часть кода программы, связанной с обработкой событий оконного интерфейса. Если у вас в проекте эта логика щедро переплетена с работой с файлами, вызовами винапи, собственными компонентами, то вам приличную часть кода придется как-то переписывать.
Все дело в правильном конструировании программ. Вот у нас в бизнес-приложениях ни одного обращения к win api не встретишь. Это слишком низкий уровень абстрагирования для прикладных программ. Поэтому они переводятся вообще без проблем. Все, что Вы имеете ввиду располагается в компонентах, которые переписываются ручками, с сохранением интерфейса.
Ну конечно, если у Вас
>логика щедро переплетена
то будет сложно. Хотелось бы отметить, что и в обычной жизни Вам не просто.
Приведу пример. Казалось бы вот есть системный реестр. С ним то что делать? А сделали так. Есть js объект в котором хранятся только те значения ключей системного реестра, которые или запрашивались или устанавливались. Этот объект в определенные моменты времени (асинхронно) сериализует ключи и отправляет их на сервер. Там все хранится в БД. С точки зрения прикладной программы ничего не меняется. Она обращается к знакомым методам. Тем временем реализация подменена. Вот что инкапсуляция животворящая делает :)
Ну конечно, если у Вас
>логика щедро переплетена
то будет сложно. Хотелось бы отметить, что и в обычной жизни Вам не просто.
Приведу пример. Казалось бы вот есть системный реестр. С ним то что делать? А сделали так. Есть js объект в котором хранятся только те значения ключей системного реестра, которые или запрашивались или устанавливались. Этот объект в определенные моменты времени (асинхронно) сериализует ключи и отправляет их на сервер. Там все хранится в БД. С точки зрения прикладной программы ничего не меняется. Она обращается к знакомым методам. Тем временем реализация подменена. Вот что инкапсуляция животворящая делает :)
Некоторые из вас такие приколисты. Отправляют нам программы которые пытаются с диском поработать или системным реестром с враждебными намерениями. Еще раз для тех кто на бронепоезде — «компилируем на Сервере, исполняем на Клиенте»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Транслятор из Delphi в javascript