LINUX.ORG.RU
ФорумTalks

XULRunner: с чем подавать лучше?


0

0

Как считаете, что перспективнее для создания корпоративных бизнес-ориентированных аппликух: просто XULRunner с Javascript или XULRunner + PyXPCOM + PyDOM (это когда вообще все на питоне можно заскриптовать, <script type=«text/python»> и все дела)?

★★★★★

Думаю JS+CPP для критичных компонентов. Очень по ынтерпрайзному. Всё таки js+xml проще дизигнерам и не кодерам осваивать. А сильноработающий код всё же лучше писать не на питоне, а на С++, ну по крайней мере пока не появится мифический компилятор питона для llvm.

ixrws ★★★
()
Ответ на: комментарий от ixrws

Если питон на llvm и появится, то его кроссплатформенности надо будет ждать ой как долго...

shimon ★★★★★
() автор топика

>PyDOM

даже одно название уже внушает. Как представлю как это на презентации будет звучать...

nu11 ★★★★★
()
Ответ на: комментарий от ixrws

Преимущества подхода xul+html+js - это возможность клепать из одного и того же кода как нативные интерфейсы, так и вебинтерфейсы. Не надо особо на этот счёт заморачиваться. Просто для вебинтерфейса вместо xul ипользуется какой-нибудь новомодный JS фреймворк, а прямое взаимодействие по сокетам заменяется на AJAX, а может и изначально юзается только AJAX. А с питоном оно уже получается более сильно завязанным на мозиллу.

ixrws ★★★
()
Ответ на: комментарий от ixrws

> А сильноработающий код всё же лучше писать не на питоне, а на С++

В ынтерпрайзах обычно все завязано на без того медленный ввод-вывод, причем половина этого ввода-вывода взаимодействует с юзером — не критично поэтому.

А вот то, что легкого пути для написания XPCOM-оберток для уже плавающих в природе библиотек не существует, это печально, да.

shimon ★★★★★
() автор топика
Ответ на: комментарий от shimon

О том собственно и речь, именно поэтому я и назвал его мифическим. А XPCOM компоненты на CPP писать можно уже сейчас и работают они везде, где работает мозилла, а это совсем везде:)

ixrws ★★★
()
Ответ на: комментарий от ixrws

> А с питоном оно уже получается более сильно завязанным на мозиллу.

А так и предполагается — завязать на мозиллу. Мне кажется, что мозилловцы сделали плохой ход, позиционируя себя именно в качестве разработчиков некоего браузера и ничего больше. На B2B бабло можно косить глобальнее и надежнее, чем на хомячках и рекламодятелах, которым надо попу то и дело подставлять.

shimon ★★★★★
() автор топика
Ответ на: комментарий от shimon

>А вот то, что легкого пути для написания XPCOM-оберток для уже плавающих в природе библиотек не существует, это печально, да.

Мне почему-то кажется это очень неверным, делать обёртки. Вы хотите заюзать какой-нибудь enca прямо из JS ? Прикинули надеюсь оверхед? Это плохо бай дизайн. А юзать нативные библиотеки из C++ компонентов можно легко. То есть вам просто лучше делать компоненты, которые выполняют какую-то работу, подключая при этом нативные библиотеки и отдают результат компонентам на JS. Прямая трансляция это конечно жестоко:)

ixrws ★★★
()
Ответ на: комментарий от shimon

Согласен, Qt только сейчас стремится к тому, что мозилле более 10 лет как есть:) Ну что поделаешь, управляющие они такие управляющие, не понимают, что написав хорошие доки по xulrunner можно рубить бабке на корпоративщиках с помощью поддержки.
Ну а что до завязки на мозиллу, ну если так, то конечно выбор только в том, что удобнее для разработчиков. Если разработчики питоновцы, то это будет оправдано.

ixrws ★★★
()
Ответ на: комментарий от ixrws

> Мне почему-то кажется это очень неверным, делать обёртки.

Ну почему. Например, реализовать nsIScriptable-интерфейс для абстракции RDBMS с асинхроном и прочими плюшками, а потом привязываем его с другого конца к оберткам для оракля, мускуля и постгрескуля.

Писать код, который собственно с БД взаимодействует, на CPP — оверкилл, если JS намного удобнее.

Я, можбыть, неправильно выразился, я имел в виду, что написание компонентов для XPCOM не такая тривиальная задача.

shimon ★★★★★
() автор топика
Ответ на: комментарий от ixrws

> Ну что поделаешь, управляющие они такие управляющие, не понимают, что написав хорошие доки по xulrunner можно рубить бабке на корпоративщиках с помощью поддержки.

Зато у других есть шанс занять нишку. Лично я, если лень и обстоятельства не слишком помешают, хочу попытаться.

Ну и все-таки XULRunner — это не PyGTK и не PyQt даже, оно с полпинка работает, причем везде. При этом даже если запаковать все зависимости в одну кучку, то результат не будет таким чтобы аж очень ужасающе огромным.

shimon ★★★★★
() автор топика
Ответ на: комментарий от ixrws

> Всё таки js+xml проще дизигнерам и не кодерам осваивать.

Ага, конечно. Особенно современный JScript с прототипами, замыканиями и т.п. вещами )))

Alesh
()

> это когда вообще все на питоне можно заскриптовать, <script type=«text/python»> и все дела

ОМГ, Доделали наконец? Когда-то (5 лет назад, тогда о ней начали писать и даже уже можно было потестить, что-то) я большие надежды возлагал на эту связка, как раз делать «корпоративных бизнес-ориентированных аппликух». Но не дождался (

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

Alesh
()
Ответ на: комментарий от Alesh

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

Дык, уже.

http://pyxpcomext.mozdev.org/

Только PyDOM в самом-самом последнем релизе еще не работает, у автора трудности с прикручиванием Python 2.6.4 какие-то. Брать можно предпоследний, там все работает.

На той же венде ничего не надо доустанавливать, питон в коробке.

shimon ★★★★★
() автор топика
Ответ на: комментарий от Reset

Это вы не мне объясняйте, а гуглю. Они это придумали, они пусть и расхлёбывают свой новомодный компиллер.
Я лишь хотел сказать, что смысла юзать python сейчас в рамках xul не вижу никакого, если конечно кодеры не питонщики, тогда да. Но обычно те, кто занимается воянием морд не являются такими уж крутыми-раскрутыми программистами, которым бы питон очень был нужен, а JS для них был бы уныл.

ixrws ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.