Форум: "Прочее";
Текущий архив: 2007.11.04;
Скачать: [xml.tar.bz2];
Внизновый проект Найти похожие ветки
← →
tesseract © (2007-10-02 15:02) [40]
> Чего тебе не хватает?
У него PR-хороший.
> MFC тоже )
Акстись от ентой ерунды.
← →
Eraser © (2007-10-02 16:10) [41]
> oxffff © (02.10.07 14:59) [39]
> Чего тебе не хватает?
возможностей языка C# и платформы .net.. того же GC. Да и в MS VS 2008 много вкусностей обещают, и даже MSVS2005 на порядок стабильнее делфей.. хотя бы исправили глюк с автоскролом и русскими буквами, а то 5 лет все никак..
другое дело что многое, что легко напишу на делфи с трудом предствляю, как написать под .net, особенно это касается системных механизмов.. хотя это дело практики конечно.
← →
oxffff © (2007-10-02 16:17) [42]
> возможностей языка C# и платформы .net.. того же GC.
Если не сравнивать среды. А сравнить языки.
Каких конкретно средств языка вам не хватает?
За исключением generics и GC.
Вопрос второй
Уже изучили IL? ;)
← →
evvcom © (2007-10-02 16:18) [43]
> хотя бы исправили глюк с автоскролом и русскими буквами,
> а то 5 лет все никак..
это о чем? С русскими буквами была какая-то беда, но, видимо, я так к этому привык, что уже забыл о ней :)
Склероз вылечить нельзя, зато о нем можно забыть (c) поговорка :-)
← →
Eraser © (2007-10-02 16:38) [44]
> oxffff © (02.10.07 16:17) [42]
> Уже изучили IL?
эт еще зачем? ) лучше заняться куда более полезным делом, поспать к примеру )))
> Каких конкретно средств языка вам не хватает?За исключением
> generics и GC.
остального вполне хватает.
> Если не сравнивать среды.
а почему бы и не сравнить? )
> А сравнить языки.
а что тут сравнивать, что паскаль - лучший ЯП.. но развиваться надо.
> evvcom © (02.10.07 16:18) [43]
> видимо, я так к этому привык, что уже забыл о ней :)
беда в том, что на работе приходиться работать в MSVS2005, поэтому когда сажусь за делфи ну никак не хочет забываться проблема с буковками, особенно когда комментарий написать надо )
← →
Kostafey © (2007-10-04 18:04) [45]> [29] Юрий Зотов © (02.10.07 11:43)
> > Kostafey © (02.10.07 11:40) [28]
>
> Наверное, потому, что о покойнике - либо хорошо, либо ничего...
>
> :о)
Вот иногода Вас не поймешь то ли шутка (но это черный юмор),
толи нет? Но если не шутка то почему?
← →
Юрий Зотов © (2007-10-05 13:22) [46]> Kostafey © (04.10.07 18:04) [45]
Шутка, конечно. Точнее, подколка любителей хоронить Delphi... а то их голословная агрессивность поднадоела уже...
:о)
← →
Nic © (2007-10-05 13:34) [47]
> Юрий Зотов © (05.10.07 13:22) [46]
Это верно. Пока любители хоронить Delphi пытаются сделать это, другие работают и зарабатывают.
← →
Суслик © (2007-10-05 13:37) [48]
> Это верно. Пока любители хоронить Delphi пытаются сделать
> это, другие работают и зарабатывают.
зарабатывают... на java.
шойто я не вижу ни одного профи ПРИШЕДШЕГО в дельфи, зато есть УШЕДШИЕ :)
← →
Nic © (2007-10-05 13:41) [49]
> Суслик © (05.10.07 13:37) [48]
Никто не мешает зарабатывать хоть на каком ЯВУ. Я зарабатываю с помощью Delphi.
← →
Суслик © (2007-10-05 13:43) [50]
> Я зарабатываю с помощью Delphi.
на дельфи вообще сейчас есть очень дорогие вакинсии - мало программистов потому, а поддерживать старые разработки нужно кому-то.
может и ошибаюсь, но можно имхо найти работу тысяц за 90р поддерживать старый проект на дельфи.
← →
Eraser © (2007-10-05 13:44) [51]
> Суслик © (05.10.07 13:43) [50]
можно то можно, там скорее всего в довесок требуется недющенный опыт работы с тем же pl/sql и т.п. .. знанеие предметной области..
← →
Eraser © (2007-10-05 13:46) [52]
> недющенный
недюженный )
← →
kaif © (2007-10-05 15:05) [53]Мне кажется, что выбор верной платформы в основном зависит от того, насколько хорошо спланирована сама задача.
Если я точно знаю (жесткая задача), что именно хочу сделать, то в Delphi я это сделаю легко, больше отдыхая, чем напрягаясь.
Однако если задача размыта, десятки версий сменяют друг друга, пока заказчик, наконец, нащупает те решения, которые его на самом деле устраивают, то в таких ситуациях я замечал преимущество интерпретирующих сред. В чем сила, например, той же 1С? По сути, ведь, это совершеннейший отстой. Но то, что она содержит встроенный интерпретатор, помогает (в условиях разброда и шатаний заказчика вокруг способов решения своих проблем) десятки раз переделывать какие-то вещи, не ломая саму общую конструкцию.
Мне по стечению обстоятельств часто приходится разрабатывать (или дорабатывать) сервлетные проекты JAVA. Это один из видов того, что называют "интранет". То есть клиент-серверные трехзвенки (браузер, серверное приложение в виде обычного web-узла + база данных).
Ознакомившись с ASP.NET, могу сказать, что на мой взгляд ASP.NET на порядок лучше, чем эта технология. Так как в ASP.NET-е не поклоняются ООП, как в JAVA, а реально предлагают серверные "видуальные" компоненты с возможностью их самостоятельной разработки и доработки. То есть в ASP.NET мы имеем не мешанину HTML с серверным кодом, как в JSP, а специальные тэги компонентов, "живущих на сервере". Например, <asp:Button> или <asp:TextBox>. И обработчики событий для этих компонентов подключаются так же просто, как в Delphi, то есть назначением свойств типа "OnClick". То есть программисту очень удобно кликнув по кнопке в дизайнере формы, например, тут же попасть на текст обработчика ее нажатия, написанного на нормальном языке типа C# или том, который он предпочитает (например, VB).
Зачем я об этом пишу?
ИМХО, может стоит подумать в направлении применениия ASP.NET, если проект большой и невнятно спланированный?
Так как если он хорошо спланирован, то я не вижу смысла мучиться выбором платформы. Берите ту, на которой имеете большой опыт проектирования. Delphi - не худший выбор. Так как из всех сред, на мой взгляд, она наиболее комфортна для программиста и позволяет делать простые вещи просто, а сложные не возбраняет делать грамотно.
← →
Interior (2007-10-05 18:26) [54]Хорошо сказал.
+1
← →
Anatoly Podgoretsky © (2007-10-05 18:28) [55]> Суслик (05.10.2007 13:37:48) [48]
Пусть уходят, нам больше останется.
← →
Суслик © (2007-10-05 18:28) [56]
> [54] Interior (05.10.07 18:26)
> Хорошо сказал.
> +1
особенно мне понравилось, что и плохого ничего не сказал про дельфи, а все же отвадил :р
← →
Черный Шаман (2007-10-05 19:06) [57]
> kaif © (05.10.07 15:05) [53]
JSF + JSTL не хуже ASP.NET. Только основную часть бизнес-логики лучше все таки перенести в объекты, а не тупо шарашить в обработчики событий.
Визуальное рисование веб-формочек на том же JSF есть в NetBeans - все как в Delphi - кнопочек накидал на форму.... э-э-э... на станицу и есть корпоративное веб-приложение. Мапинги переходов по событиям между страничками тоже визуально рисуются (конечно их можно прописывать руками в xml файле).
Так что если Web- то только Java, если Desktop, то Дерфи конечно хорош, но QT по функционалу немного лучше.
Хотя сейчас пишу на Delphi, после тщательной обработки напильником под задачу вполне функциональная платформа. А хотелось бы чтобы прямо с коробки... :(
← →
lookin © (2007-10-05 19:09) [58]Интересно, Delphi еще изучают в ВУЗах? А то вот студенты на предложение поработать на Delphi высказались в духе, что Delphi уже слишком устарело. Причем я не понял, они про IDE говорили, или имели в виду Паскаль-язык....
← →
kaif © (2007-10-05 23:35) [59]Черный Шаман (05.10.07 19:06) [57]
> kaif © (05.10.07 15:05) [53]
JSF + JSTL не хуже ASP.NET. Только основную часть бизнес-логики лучше все таки перенести в объекты, а не тупо шарашить в обработчики событий.
Визуальное рисование веб-формочек на том же JSF есть в NetBeans - все как в Delphi - кнопочек накидал на форму.... э-э-э... на станицу и есть корпоративное веб-приложение.
А вот и нет.
JSTL - жалкая попытка заменить конструкции типа <%...%> (jsp-шную мешанину с серверным кодом) на конструкции наподобие <if>...<else>...<foreach>... для якобы отделения дизайна страниц от бизнес-логики. По сути это чистейшее фуфло. И вдохновляет только придурков, свято верящих в то, что xml когда-нибудь станет языком программирования только потому что он универсален.
А вот ASP.NET - тщательно продуманная система. По крайней мере у меня есть хорошая возможность сравнить обе технологии не на уровне разговоров, а в реальности.
Ничего более отвратительного в программинровании, чем сервлеты, я лично в своей жизни не видел. Если у вас иное мнение, помогите мне решить одну проблему. Даже не решить, а хотя бы найти концы, откуда у нее ноги растут. Даже не найти концы, а хотя бы намекнуть на гипотезу, которая (при моем усердном самостоятельном расследовании) позволила бы вырулить на хвост проблемы.
Итак, имеется среда разработки JDeveloper от самого ORACLE.
Из-под нее стартует контейнер сервлетов oc4j.
Имеется настроенный (в точном соответствии с документацией и совпадающий с сотней примеров того, как это следует делать) DataSource.
Ссылку на этот дадасоурс получаем классическим способом (то бишь написав ту абракадабру java:comp/env, какая принята в этой JAVA-сфере JNDI (если я не спутал эту аббревиатуру - в джаве таких аббревиатур больше, чем объектов, которые сборщик мусора в каждом цикле подбирает)):
Context env = (Context) new InitialContext().lookup("java:comp/env");
dataSource = (DataSource)env.lookup("jdbc/OracleDS");
После чего делается следующее:Connection con=null;
Statement stmt=null;
try
{
con = dataSource.getConnection();
stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("неважно что");
while(rs.next())
{
//неважно, что
}
stmt.close();
}
catch(SQLException sqle) {
System.err.println(sqle.getMessage());
}
finally
{
try {if (con != null) con.close();}
catch (SQLException sqle){}
}
Так вот вопрос на засыпку.
Как сделать так, чтобы после запуска подобного сервлета соединение действительно было закрыто?
Дело в том, что даже после рестарта контейнер oc4j сообщает о том, что соединение ТАК И НЕ БЫЛО ЗАКРЫТО.
Если Вы поищете в google, то Вы найдете массу чуваков, которые замучились решить этот вопрос, но так ни к чему и не пришли. Способа искать хвост этой проблемы я не знаю и подозреваю, что никто не знает.
В .NET у разработчика есть возможность закрыть соединение и удалить объект connection принудительно, а не надеяться на сборщик мусора и глюки контейнеров.
← →
Petr V. Abramov © (2007-10-06 00:51) [60]> Итак, имеется среда разработки JDeveloper от самого ORACLE.
если кто-то САМ умеет делать корешки, не факт, что вершки не будут кривыми.
> Из-под нее стартует контейнер сервлетов oc4j.
ты попал :)
← →
Черный Шаман (2007-10-06 01:39) [61]
> kaif © (05.10.07 23:35) [59]
> Так вот вопрос на засыпку.
> Как сделать так, чтобы после запуска подобного сервлета
> соединение действительно было закрыто?
> Дело в том, что даже после рестарта контейнер oc4j сообщает
> о том, что соединение ТАК И НЕ БЫЛО ЗАКРЫТО.
Насколько я знаю, то что вы хотите нарушает философию Java. Так что "закрытием" вы просто говорите сервлет-контейнеру, что данное соединение свободно и он позже его отдаст другому сервлету. Это сделано для кеширования соединений(просто некоторые ORM порождают до сотни соединений/отсоединений в секунду, и чтобы оно не тормозило выполняется кеширование). Вроде бы его можно закрывать, но это нужно указывать в где-то настройках Tomcat, Java к этому отношения не имеет.
В принципе Java написана для Индусов, которые обладают хорошей памятью, но низким интеллектом. Так что нужно это учитывать.
← →
Celades © (2007-10-06 07:49) [62]
> В принципе Java написана для Индусов, которые обладают хорошей
> памятью, но низким интеллектом. Так что нужно это учитывать.
>
>
страшно подумать для кого написан Delphi...
← →
Anatoly Podgoretsky © (2007-10-06 10:34) [63]> Celades (06.10.2007 07:49:02) [62]
Что и с память плохо?
← →
Kostafey © (2007-10-06 11:11) [64]> страшно подумать для кого написан Delphi...
+1 :))
← →
kaif © (2007-10-06 13:10) [65]Черный Шаман (06.10.07 01:39) [61]
Насколько я знаю, то что вы хотите нарушает философию Java. Так что "закрытием" вы просто говорите сервлет-контейнеру, что данное соединение свободно и он позже его отдаст другому сервлету.
Если Вы имеете в виду пул соединений, то я отключил пулирование. Пофиг. Вообще никакой разницы. Кстати, под Tomcat наблюдается та же пса.
Что касается философии, то мне видится дело следующим образом.
Представим себе, что разработчики Delphi поклонялись бы ООП, как богу Вишну. Тогда они вместо того чтобы сделать класс TForm с ресурсом dfm и своей архитектрой обработки сообщений Windows, поступили бы проще.
Они бы инкапсулировали оконную процедуру в класс-оболочку TWindowProc и гордились бы тем, что после регистрации окна в Windows при помощи CreateWindowsEx очередь сообщений Windows направляет не какой-то там голимой процедуре, а настоящему КЛАССУ TwindowsProc. И предложили бы Вам этим ГОРДИТЬСЯ и чувствовать себя причастными к ВЕЛИКОЙ ФИЛОСОФИИ. А очередь сообщений обрабатывать темне менее вручную внутри методов TWindowProc, которых было бы заготовлено сто штук на все случаи жизни. Половина этих методов была бы deprecated (устаревшими и потому нерекомендуемыми для юзания). При этом Ваш код был бы "переносим" между платформами , но только при условии, что вместе с кодом Вам нужно каждый раз переносить на новое место ту же версию джава-машины и ту же версию JDK.
Если же Вы по неопытности при вызове какого-то из методов вдруг напутали бы тип параметра, то Вам всегда еще следовало бы помнить, что философия джавы состоит еще и в том, что если вызвать метод ПоклонисьВишну(int,String) вместо того чтобы вызвать метод ПоклонисьВишну(int,int), то Вы получите вовсе не сообщение "calling existing method with illegal parameters", как ожидает любой нормальный человек, а сообщение "method does not exisit". Хотя при этом конструкция вида print(String + int) сработает без проблем. То есть всегда нужно помнить о том, что в операторах иногда джава умеет конвертировать типы в строку, а вот при вызове методов - дудки - она даже не умеет распознавать методы по имени. Особенно это по-философски удобно, если юзается пакет стороннего производителя, где в какой-то версии действительно нет метода с таким именем, а в какой-то иной версии такой метод есть, но сигнатура у него иная.
Что касается jsp и сервлетов, то там архитектура - вся наподобие той, что я описал, говоря о TWindowsProc. То есть НИКАКОЙ АРХИТЕКТУРЫ. Сервлет - это просто класс HttpServlet, имеющий метод service, который ничего иного не делает, кроме как умеет помещать командой принт строки в буфер ответа, который сервер отошлет клиенту. Текст файла JSP парсится и просто вставляется внутрь тела этого метода service. Все строки JSP, в которых найдены конструкции <% ... %> грубо переписываются без этих скобок, а все остальное (HTML-тэги) запихиваются в print. Так действует Tomcat. Светлой мысли в этом не больше, чем в любом парсере, который парсит что-нибудь и просит JDK откомпилировать резулбтат.
И это не имеет ничего общего с aspx-технологией, где вместо текста для неинтеллектуально парсинга и вставки в метод service имеется ресурс с серверными компонентами, имеющими события и свойства, записанные в атрибутах тэгов с ясными именами, а не мешанина из HTML и голимого кода.
Вот знаете, что сообщит компилятор, если на JSP-странице упустить одну скобку в выражении a = e - ((b+c)/d) или одну операторную скобку?
Он сообщит, что метод try не имеет завершения catch.
Вот уж философия!
← →
Celades © (2007-10-06 21:09) [66]
> Что и с память плохо?
"официальные" версии не верны на сегодняшний момент.
← →
имя (2007-10-07 22:09) [67]Удалено модератором
← →
имя (2007-10-07 22:25) [68]Удалено модератором
Страницы: 1 2 вся ветка
Форум: "Прочее";
Текущий архив: 2007.11.04;
Скачать: [xml.tar.bz2];
Память: 0.61 MB
Время: 0.05 c