Здравствуйте, adontz, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>Осталось дело за малым. Построить CSS процессор.
A>Жжёшь!
Да ну, это действительно несложно.
Проблема в другом: DOM должен быть CSS friendly.
Скажем button[type="menu"] подразумевает то что CSS процессор имеет
возможность быстро вытащить значение атрибута type. Reflection тут "не канает" скажем так.
Здравствуйте, c-smile, Вы писали:
CS>Проблема в другом: DOM должен быть CSS friendly. CS>Скажем button[type="menu"] подразумевает то что CSS процессор имеет CS>возможность быстро вытащить значение атрибута type. Reflection тут "не канает" скажем так.
Генерация байт-кода и кэширование?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, c-smile, Вы писали:
CS>>Проблема в другом: DOM должен быть CSS friendly. CS>>Скажем button[type="menu"] подразумевает то что CSS процессор имеет CS>>возможность быстро вытащить значение атрибута type. Reflection тут "не канает" скажем так.
C>Генерация байт-кода и кэширование?
кэширвание чего? значения атрибута? или нагенерирванного байткода?
Здравствуйте, 8bit, Вы писали:
8>Здравствуйте, c-smile, Вы писали:
8>>>Есть виджет для тикля , который проходит даже ACID тест. CS>>"тикля" это чего у нас такое будет?
8>TCL.TK
Ага, понятно.
Смотря для чего там html позиционируется.
Если на просто help показать то для этого ACID не нужен.
Если для нужд UI на экране то фич CSS21 явно недостаточно.
8>http://tkhtml.tcl.tk/index.html
( прикольно, но тяжко такие штуки на голимом C писать )
Здравствуйте, work69, Вы писали:
A>>Очень хочется HTMLayout для .Net (2.0) — т.е. без Native C++. Если этого не будет, то WPF — победит (когда не будет W2k/win9x) W>Когда не будет W2k/win9x — .NET уже тоже не будет . Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет, W>все уходит потом в треш и начинаются очередные маркетинговые крики — "наш аппроуч А был фиговым, в мусор его. W>Вот сейчас мы придумали аппроуч B! Который наконец таки решит ваши проблемы!"
Все правильно, .NET такой же движетель рынка как был/есть COM.
Кстати ничего плохого в .NET нет. Есть попытка засунуть его во все возможные отверстия
квадратно гнездовым методом. Что и получилось с COM.
Употребленный массивно, очень часто не к месту и не квалифицировано создал кучу проблем.
Как бы .NET не постигла та же участь.
Здравствуйте, c-smile, Вы писали:
C>>Генерация байт-кода и кэширование? CS>кэширвание чего? значения атрибута? или нагенерирванного байткода?
Да, кэширование атрибута. У меня есть подобная задача — выбирать объекты из графа по осям (наподобии XPath), у меня получается кэшировать атрибуты на время выполнения выражения.
Кстати, хотел спросить — а для Java в HTMLayout еще никто адаптерами не занимался?
Здравствуйте, work69, Вы писали:
W>Когда не будет W2k/win9x — .NET уже тоже не будет . Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет,
.Net живет уже 5 лет (первая студия с C# появилась в 2002 году)
COM — 14 лет (он появился в 1993 году). Я не могу согласиться с тем, что COM отправлен на свалку. Просто в своем развитии эта технология достигла максимума, трудно себе представить, что там можно реально улучшить, на написав попутно новый .Net. Масса программ использует и будет продолжать использовать COM. И его поддержка будет всегда существовать в ОС Windows.
W>все уходит потом в треш и начинаются очередные маркетинговые крики — "наш аппроуч А был фиговым, в мусор его. W>Вот сейчас мы придумали аппроуч B! Который наконец таки решит ваши проблемы!"
А вот интересно, люди говорящие подобные вещи вообще понимают, почему в начале появилась технология COM (ее недостатки были понятны практически сразу), и только теперь можно переходить на более удобый, гибкий и безопасный .Net? Если нет, то могу объяснить — COM в 1993 году мог работать на компютере IBM PC AT с 1-м мегабайтом памяти и процессором Intel 20286 c частотой (точно не помню, но типа мегагерц 20-30). При этом работал не просто "абстрактный COM", а MS Excel рисовало табличку в MS Word, т.е. взаимодействовало два солидных приложения. Все это жило в Windows 3.1. Теперь, когда машины стали помощьнее, и технологии стали более сложными. При этом COM и .Net весьма не плохо совмещаются.
Здравствуйте, aloch, Вы писали:
>> COM .. употребленный массивно, очень часто не к месту и не квалифицировано создал кучу проблем. A>А примеры?
IE с его утечками памяти в JavaScript'е...
A>А вот интересно, люди говорящие подобные вещи вообще понимают, почему в начале появилась технология COM (ее недостатки были понятны практически сразу), и только теперь можно переходить на более удобый, гибкий и безопасный .Net?
На мой вгляд .НЕТ хоть и даёт удобство,гибкость и безопасность. Всё идёт к удешевлению труда специалистов. Я сталкивался с тем что написанием программ на .НЕТ причём в коммерческих целях занимались люди имеющих довольно скудное представление об ООП. В начале появился ком который избавил от ада dll щас .NET. Причём сам по себе .НЕТ даже для БД в сыром виде не используется. А распространены ОО Обёртки над ним, такие как NHibernate ,и\или собственного написания. Причём зачастую даже там где требуется скорость, где бы необходимо написать используя DataReader и пр. Всёравно используются высокоуровневые обёртки . Мотивируя это тем что код мегауниверсален и маштабируем. А получаем что получаем. "тормозность", но удобство, красивое IDE,хорошо организованая идеалогия ООП, делают своё дело и технология успешно продвигается. скоро популярность спадёт и после какого нибудь .NET 7.0 отправится на полку. А все будут поклонятся новой обёртке над WinApi.
A>При этом COM и .Net весьма не плохо совмещаются.
Но и не весьма хорошо. MIDL и CLR не одно и тоже и каждый раз конвертить типы приходится. разве это удобство?
Здравствуйте, aloch, Вы писали:
A>А вот интересно, люди говорящие подобные вещи вообще понимают, почему в начале появилась технология COM (ее недостатки были понятны практически сразу), и только теперь можно переходить на более удобый, гибкий и безопасный .Net?
Я, глядя на последнии технологии мелкомягких, склоняюсь к мысли,
что они таки научат обезьян "программировать",
и наступит хаос и тьма спустится на землю обетованную.
Здравствуйте, c-smile, Вы писали:
CS>Проблема в другом: DOM должен быть CSS friendly. CS>Скажем button[type="menu"] подразумевает то что CSS процессор имеет CS>возможность быстро вытащить значение атрибута type. Reflection тут "не канает" скажем так.
CS>Здравствуйте, Cyberax, Вы писали: C>>Генерация байт-кода и кэширование? CS>кэширвание чего? значения атрибута? или нагенерирванного байткода?
И нагенерированный байткод тоже кэшировать можно.
Здравствуйте, work69, Вы писали:
W>Здравствуйте, dimzon, Вы писали: CS>>>И вообще про "наступает время managed code" — в "священные войны". D>>Насчёт войн — спорить не буду но рекомендую посмотреть статистику по СЕРЬЁЗНЫМ проектам уровня предприятия. Все сервера приложений — 90% либо J2EE либо .NET. Бизнес-код в основном пишут на Managed. Тот же самый 1С — там тоже Managed. W>1) Вам сколько лет? W>2) А что на "проектах уровня предприятия" свет клином сошелся? Или вы думаете что круче их ничего нет?
1) А какая ВАМ разница? Достаточно.
2) Будем "пиписьками" мерятся?
Здравствуйте, aloch, Вы писали:
A>А вот интересно, люди говорящие подобные вещи вообще понимают, почему в начале появилась технология COM (ее недостатки были понятны практически сразу), и только теперь можно переходить на более удобый, гибкий и безопасный .Net?
Java? Издавна есть на телефонах и как-то никто не горевал что мощности мало.
Ядро .Net не требует каких-то особых ресурсов, тем более по сравнению с СОМ.
Здравствуйте, adontz, Вы писали:
A>Java? Издавна есть на телефонах и как-то никто не горевал что мощности мало.
Это, мягко говоря, немного другая Java, чем та, что ставиться на PC. Кроме того, современный телефон (или PDA) будет помошьнее персонального компьютера конца 90-х. Например, я на моем PDA могу играть в Doom, а вот на моей IBM PC AT c Intel 80286 и 1 мегабайтом памяти (а именно про такую машину я говорил) я этого не мог. Но на этой машине работала Windows 3.1 и COM.
A>Ядро .Net не требует каких-то особых ресурсов, тем более по сравнению с СОМ.
Угу. Ты урежь себе память мегабайтов до 16-ти и запусти прораммку на .Net, которая рисует на экране окошко с текстом Hello, World и кнопкой. Окошко на экране появиться минут через 10.
Здравствуйте, aloch, Вы писали:
A>Здравствуйте, work69, Вы писали:
W>>Когда не будет W2k/win9x — .NET уже тоже не будет . Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет,
A>.Net живет уже 5 лет (первая студия с C# появилась в 2002 году)
A>COM — 14 лет (он появился в 1993 году). Я не могу согласиться с тем, что COM отправлен на свалку. Просто в своем развитии эта технология достигла максимума, трудно себе представить, что там можно реально улучшить, на написав попутно новый .Net. Масса программ использует и будет продолжать использовать COM. И его поддержка будет всегда существовать в ОС Windows.
И это нам говорит "сертифицированный специалист Microsoft"
Ничего подобного. Небыло COM в 1993 году.
В 1993 году у MS был OLE1.0 — технолгия не имеющая практически НИЧЕГО общего с COM, она строилась поверх DDE.
В 1995 году вместе с Win95 вышел OLE2.0 который ничего кроме первых 3 букв в названии не имеел с OLE1.0.
Так вот эта OLE2.0 базировалась на COM. Причем если мне не изменяет память, то время в COM — MIDL'а еще не было
был ODL. До MIDL'а MS доросла году в 96-98м. А сколько раз они переливали из пустого в порожнее называя весь этот стафф
то OLE, то COM, то ActiveX в разных сочетаниях, к 2000 году я думаю даже в самой MS врядли кто-нить мог внятно объяснить
что именно они называют технологией ActiveX
W>>все уходит потом в треш и начинаются очередные маркетинговые крики — "наш аппроуч А был фиговым, в мусор его. W>>Вот сейчас мы придумали аппроуч B! Который наконец таки решит ваши проблемы!"
A>А вот интересно, люди говорящие подобные вещи вообще понимают, почему в начале появилась технология COM (ее недостатки были понятны практически сразу), и только теперь можно переходить на более удобый, гибкий и безопасный .Net? Если нет, то могу объяснить — COM в 1993 году мог работать на компютере IBM PC AT с 1-м мегабайтом памяти и процессором Intel 20286 c частотой (точно не помню, но типа мегагерц 20-30). При этом работал не просто "абстрактный COM", а MS Excel рисовало табличку в MS Word, т.е. взаимодействовало два солидных приложения. Все это жило в Windows 3.1. Теперь, когда машины стали помощьнее, и технологии стали более сложными. При этом COM и .Net весьма не плохо совмещаются.
Повторяю — не было тогда COM, см. выше
Здравствуйте, aloch, Вы писали:
A>>Ядро .Net не требует каких-то особых ресурсов, тем более по сравнению с СОМ.
A>Угу. Ты урежь себе память мегабайтов до 16-ти и запусти прораммку на .Net, которая рисует на экране окошко с текстом Hello, World и кнопкой. Окошко на экране появиться минут через 10.
Здравствуйте, adontz, Вы писали:
A>Окошко это не ядро. Учи матчасть.
Ядро само по себе никому не нужно, если оно не будет окошки рисовать, файлы открывать и еще что-нибудь такое делать, ради чего вообще программы пишутся. И вот когда я рисую окошко "через ядро .Net" (а не напрямую, через WinAPI), я получаю внушительный расход памяти. Я, в принципе, не против и даже понимаю куда и зачем она использовалась.
А вот для COM приктически ничего не нужно — IUnknown, вот и все его "ядро".
W>И это нам говорит "сертифицированный специалист Microsoft" W>Ничего подобного. Небыло COM в 1993 году. W>В 1993 году у MS был OLE1.0 — технолгия не имеющая практически НИЧЕГО общего с COM, она строилась поверх DDE.....
OLE 2 (в основе которой лежал COM) появилась в 1993 году в Windows 3.1 — ее использовали и Word 6.0 и Excel 5.0 (в котором появился VBA http://en.wikipedia.org/wiki/Microsoft_Excel — Since 1993, Excel has included Visual Basic for Applications (VBA)...), я в то время лично при помощи Visual C++ 1.5 (http://support.microsoft.com/kb/145669 — New Features: ... OLE 2.0 SDK) и Visual Basic 4 писал и использовал объекты OLE Automation.
, который проходит даже ACID тест.
. Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет, 
.jpg)
