LINUX.ORG.RU

JXHTMLedit


0

0

WYSIWYG редактор HTML с открытым исходным кодом. Использует J2SE 1.4, работает в окне браузера, в ОС Linux, Windows, MacOS X, Solaris etc

"Ни дня без чашечки кофе"

>>> Подробности

anonymous

Проверено: anonymous_incognito ()

Ответ на: комментарий от anonymous

>Тормоз, который по всем тестам работает со скоростью C, asm, C++?

ой бля. ссылочку можно, где жаба асм и си обгоняет. Очень прошу

>Потому что мы не умеем его правильно готовить и не знаем об UML, OMG, OOAD etc?

потому что ООП потворстувет созданию фальшивых аналогий реальным объектам в программном коде

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

>Тогда WinFX что будет по-твоему?

а что это? =)

>Java-апплеты были классной идеей.

классной идеей - безусловно. Вот только почему-то нишу, которую сан забивала для апплетов занял напрочь закрытый flash. Ничем другим, кроме как хроническим маразмом сантехников это объяснить нельзя. Далее можно порассуждать - стоит ли связываться с продуктами и технологиями компании, у руля которой стоят маразматики? ответ, по крайней мере для меня, очевиден.

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

>>>> потому что ООП потворстувет созданию фальшивых аналогий реальным объектам в программном коде

а какой метод программирования потворствует созданию реальных аналогий реальным объектам в программном коде?

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

>а какой метод программирования потворствует созданию реальных аналогий реальным объектам в программном коде?

метод использования моска =)

ООП хорош там, где можно _всё_ представить в виде объектов. Т.е. вообще без использования процедурного подхода. Если вас это утешит, то та же жаба как ООП язык программирования на голову выше C++ ;)

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

Flash занял нишу анимации от которой все охренев начали делать конфетно-глазовые интерфейсы, как вобщем и в случае с html. А апплеты на яве весьма неплохо работают там где это надо, вопрос только в том имеет ли смысл грузить сложное приложение которым часто пользуешься по сети или проще его отдельно поставить... Да и вобщемто из любого swingoвого приложения апплет сделать можно, подписанные аплеты щас много че делать умеют.

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

> А может лучше сразу из Фотошопа или из Оракла в сайт вставляеть? А из кофемолки они в кофеварку руками порошок вставляют? Или ты им программу пишешь?

Я пишу программу, которая удовлетворяет потребности пользователей и получаю за неё деньги, а снобы идут лесом и работают в сфере обслуживания или в `органах'.

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

Сановцев тоже порою не понимаю. Здесь согласен.

> Вот только почему-то нишу, которую сан забивала для апплетов занял напрочь закрытый flash.

XAML из WinFX вполне может оказаться себе HTML- и flash-killer. Флешки порою бывают ужасно тормозные. Тоже самое самое можно сказать о JavaScript. HTML - уж очень скуден, даже вместе c DOM и CSS. Поэтому у java-апплетоподобной технологии, какой в сущности и является дотнетовский XAML, есть хорошие шансы вытурить многих с этого рынка ;)

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

>Поэтому у java-апплетоподобной технологии, какой в сущности и является дотнетовский XAML, есть хорошие шансы вытурить многих с этого рынка ;)

шансов не более чем у SVG+JS

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

> ООП хорош там, где можно _всё_ представить в виде объектов. Т.е. вообще без использования процедурного подхода. Если вас это утешит, то та же жаба как ООП язык программирования на голову выше C++ ;)

А вот этого не понял. Что мешает использовать процедурный подход в Java (через static методы)? Таким образом написанный код действительно может сравнятся по скорости с C/C++ (благодря JIT). Вопрос только в том, для любой ли задачи годится такой подход. Точнее, любую ли задачу можно представить без объектов (а также структур/записей).

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

>А вот этого не понял. Что мешает использовать процедурный подход в Java (через static методы)?

ничто не мешает. Но нарушается концепция, возникает путаница из объектов и не-объектов и модель летит к черту.

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

> шансов не более чем у SVG+JS

Разве не в курсе? "Они" даже свою студию готовят по примеру Macromedia. Хотят переманить дизайнеров.

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

>"Они" даже свою студию готовят по примеру Macromedia. Хотят переманить дизайнеров.

"Они" могут хоть лезгинку танцевать. Закрытые, непереносимые и проприетарные поделия рынок уже не примет. Научен горьким опытом.

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

> ничто не мешает. Но нарушается концепция, возникает путаница из объектов и не-объектов и модель летит к черту.

Узнаю птицу по полету ;) Если программа выходит далеко за пределы "Hello World", то не бывает одной единой концепции. Задачу нужно решать методами под стать. Нужен ООП - следует использовать ООП. Если будет лучшим процедурный подход, тогда код пишется в стиле старого доброго С. Просто нужно правильно разбивать большую задачу на множество более мелких подзадач. Кстати, Java хороша тем, что можно сочетать в одной программе разные стили и подходы.

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

>Если программа выходит далеко за пределы "Hello World", то не бывает одной единой концепции

это неизбежно. Другое дело что многие "кодеры" такой винигрет делают...что диву даешься

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

> это неизбежно. Другое дело что многие "кодеры" такой винигрет делают...что диву даешься

Обычно это неизбежно в силу самой природы задачи. Ничего тут не попишешь...

Что касается винигрета, то да, есть такое дело... Между прочим, один из принципов дизайна Java - чтобы дублирующих конструкций в языке не было. Поэтому и код получается более-менее удобо-читаемым. Чего не скажешь о проектах на C++. В последнем случае мощь языка, которая безусловно свойственна C++, может обернуться против самих же "кодеров".

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

>потому что ООП потворстувет созданию фальшивых аналогий реальным объектам в программном коде

А никто тебя и не заставляет в программах создавать фальшивые аналогии реальным объектам. Ведь если математике обучают на яблоках, то в дальнейшем обучаемые уже не нуждаются в таких плоских аналогиях. Так и в ООП. Начинают обучение с реальных объектов, никто не виноват, если ты не можешь от них абстрагироваться

>классной идеей - безусловно. Вот только почему-то нишу, которую сан забивала для апплетов занял напрочь закрытый flash.

Sun забивал нишу Online Rich Media Content, то, что сейчас называют AJAX, и Flash в этой нише никогда не был. Его удел - баннеры на статических страницах, ниша, в которую Sun никогда апплеты не позиционировал

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

Далее, флеш занял свою нишу благодаря наличию Cool IDE в которой нажатием трех кнопок можно было слабать "анимированный" баннер, не зная абсолютно ничего о программировании. Но дальше баннеров из трех действий продвигаются единицы флешеров. А уж о создании сайтов а-ля maps.google.com с помощью флеша даже речи нет - нереальная это для флешевиков задача.

Sun же свою жаву для создания мигающих баннеров никогда не позиционировал, а там, где апплеты были нужны, они нормально используются. Например, даже сегодня на каком-то русском сайте, который отдает бесплатные mp3, ссылки генерятся в браузере на клиенте с помощью жаба-апплета. Попробуйте, взломайте, получите возможность скачивать качественные mp3 без лимита. Почему же это сделали не на флешке?

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

>Поэтому у java-апплетоподобной технологии, какой в сущности и является дотнетовский XAML, есть хорошие шансы вытурить многих с этого рынка ;)

С какого рынка? Для начала его еще нужно создать. HTML бесплатен и поэтому популярен, а качать VS .NET чтобы слепить страничку или сайтик, никто не будет

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

> HTML бесплатен и поэтому популярен, а качать VS .NET чтобы слепить страничку или сайтик, никто не будет

А зачем качать VS.NET?? :) Для "слепить страничку" у них есть Sparkle по типу студий Macromedia.

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