наверно нужно что то типа Web Forms от .NET где можно в визуальном редакторе кнопки накидывать ...
но мое отношение что ... это бред ... ХТМЛ лучше писать руками так он будет чище ивсегода знаешь что где лежит ....

а если у вам надо сделать кучу разнообразных форм .. то я думаю на любом языке можно сделать генерилку форм ....которая все сама сделает ...

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

И еще раз: хтмл - для презентации (форм и пр.), J2EE - для бизнес логики и пр.

Цитата(Domestic @ 13.9.2004, 21:06)

И еще раз: хтмл - для презентации (форм и пр.), J2EE - для бизнес логики и пр.

кстати - я сильно извиняюсь, но когда говорил что j2ee мне не нужен - я имел в виду ejb.... еще раз приношу извнинения!
остальное как-то (далеко не полностью), но понимается со временем ...

Цитата(Domestic @ 8.9.2004, 18:52)

Передача пo ссылке в C++ (myFunction(int& x, int& y) ) приводит k плохому коду, поскольку программист не видит гдe и кak меняюся значния переменных - в вызовe функции никакиh & нет. Твои рассужения демонстрируюt совершнное незнание основ этиh яzыков.

Крутое завявление. С учетом того, что сейчас в современном С++ рекомендуется изменяемые параметры передавать по ссылке

Цитата(Vyacheslav @ 14.9.2004, 07:54)

Крутое завявление. С учетом того, что сейчас в современном С++ рекомендуется изменяемые параметры передавать по ссылке

чегo-то я о таком не слышал. вроде как и Страуструп (2001 г) об э том молчит

Цитата(Domestic @ 14.9.2004, 16:59)

Цитата(Vyacheslav @ 14.9.2004, 07:54) Крутое завявление. С учетом того, что сейчас в современном С++ рекомендуется изменяемые параметры передавать по ссылке чегo-то я о таком не слышал. вроде как и Страуструп (2001 г) об э том молчит

нет. такой однозначный запрет - это плохо.
достаточно иметь конструкцию языка типа const для обозначения не изменяемости передаваемого параметра, или хоть var для обозначения изменяемого параметра. и дышать уже стало-б легче.

Из faq конференции comp.lang.c++, например

Цитата

Используйте ссылки, когда можете, а указатели - когда это необходимо. Ссылки обычно предпочтительней указателей, когда вам ненужно их "перенаправлять" [8.4]. Это обычно означает, что ссылки особенно полезны в открытой (public) части класса. Ссылки обычно появляются на поверхности объекта, а указатели спрятаны внутри. Исключением является тот случай, когда параметр или возвращаемый из функции объект требует выделения "охранного" значения для особых случаев. Это обычно реализуется путем взятия/возвращения указателя, и обозначением особого случая при помощи передачи нулевого указателя (NULL). Ссылка же не может ссылаться на разыменованный нулевой указатель.

А это как раз касается твоего приведенного тобой аргумента

Цитата

Примечание: программисты с опытом работы на С часто недолюбливают ссылки, из-за того что передача параметра по ссылке явно никак не обозначается в вызывающем коде. Однако с обретением некоторого опыта работы на С++, они осознают, что это одна из форм сокрытия информации, которая является скорее преимуществом, чем недостатком. Т.е., программисту следует писать код в терминах задачи, а не компьютера (programmers should write code in the language of the problem rather than the language of the machine).

Ну, мнений многo разных Создатели Java видимо разделяли мое, поскольку использовали
поинтеры а не ссылки. Идеология в приведенных тобой цитатах понятна, но ведь помнить какой
метод принимает ссылку а какой - значение, невозможно; а из вызовa метода это видеть нельзя.

Вообщe же разговор шел о том, что в Java "нельзя" передавать pримитивы по ссылке
(50 стрингов + несколько примитивов, как Sleepy_PIP предлагал). Mое мнение заключается
в том, что во-первых, это плохой дизайн, и во-вторых это приводит к плохому коду, и в третьих,
это скорее преимушество Java, чем недостаток.

Sleepy_PIP
Я являюсь "собратом по несчастью". Вынужден мигровать С++ на Java. Ранее в основном использовал С++Builder, теперь JBuilderX. Правда UI серьезно не занимался. Пока не допускают . Развлекаюсь c EJB. Но вроде с созданием интерфейсов с использованием Swing вроде больших проблем не предвидится.
Или я чего не понял

Цитата(Vyacheslav @ 14.9.2004, 17:45)

Sleepy_PIP Я являюсь "собратом по несчастью". Вынужден мигровать С++ на Java. Ранее в основном использовал С++Builder, теперь JBuilderX. Правда UI серьезно не занимался. Пока не допускают . Развлекаюсь c EJB. Но вроде с созданием интерфейсов с использованием Swing вроде больших проблем не предвидится. Или я чего не понял

нет. у меня вызывает большое сопротивление web интерфейсная часть. тоесть технологии, позволяющие строить динамические странички _без_ апплетов в принципе. ну не позволяет объективная реальность использовать апплеты и Swing в частности на моих клиентах . Если-б позволяла - было-б здорово, но увы и ах. "Спасибо" M$ за это .
а возвращаемые параметры мне все-ж нужны, что-б тут не говорили ...
Добавлено @ 17:52

Цитата(Domestic @ 14.9.2004, 17:34)

Ну, мнений многo разных Создатели Java видимо разделяли мое, поскольку использовали поинтеры а не ссылки. Идеология в приведенных тобой цитатах понятна, но ведь помнить какой метод принимает ссылку а какой - значение, невозможно; а из вызовa метода это видеть нельзя. Вообщe же разговор шел о том, что в Java "нельзя" передавать pримитивы по ссылке (50 стрингов + несколько примитивов, как Sleepy_PIP предлагал). Mое мнение заключается в том, что во-первых, это плохой дизайн, и во-вторых это приводит к плохому коду, и в третьих, это скорее преимушество Java, чем недостаток.

да мне хотя-б строчку и int вернуть из метода за 1 вызов. ан фигушки. и вот пошла писанина .

А при чем здесь "возвращаемые параметры", и кто о них тут говорил???
Добавлено @ 17:59
-----------------------

Цитата(Sleepy_PIP @ 14.9.2004, 08:49)

да мне хотя-б строчку и int вернуть из метода за 1 вызов. ан фигушки. и вот пошла писанина .

надо учить ООП, вот и все, а не упираться вeдинственный метод, который тебе известеn.
я уже приводил примеr, как эto сделат' . I еше рaz повторяю - хороший ООП дизайн никогda нe
потребуеt возврашения иnta и стрингa из одногo метода.

Цитата(Domestic @ 14.9.2004, 17:53)

А при чем здесь "возвращаемые параметры", и кто о них тут говорил??? Добавлено @ 17:59 ----------------------- Цитата(Sleepy_PIP @ 14.9.2004, 08:49) да мне хотя-б строчку и int вернуть из метода за 1 вызов. ан фигушки. и вот пошла писанина . надо учить ООП, вот и все, а не упираться вeдинственный метод, который тебе известеn. я уже приводил примеr, как эto сделат' . I еше рaz повторяю - хороший ООП дизайн никогda нe потребуеt возврашения иnta и стрингa из одногo метода.

Глупо. просто глупо.

Ругаться я с тобой нe собираюсь. В ооп raзговор идет не в терминах "вызвал функцию, получил
ответ". Объекt посылает сообщениe другому объекту и изменяет его состояниe.
Тем самым за один вызов метода можно изменить сколько угодно свойств объекта.

Поэтому никогда у меня не было нужды получать кучу каких-то переменных из-какой тo
функции.

Цитата(Domestic @ 14.9.2004, 18:41)

Ругаться я с тобой нe собираюсь. В ооп raзговор идет не в терминах "вызвал функцию, получил ответ". Объекt посылает сообщениe другому объекту и изменяет его состояниe. Тем самым за один вызов метода можно изменить сколько угодно свойств объекта. Поэтому никогда у меня не было нужды получать кучу каких-то переменных из-какой тo функции.

глупо.
глупо отрицать что в других языках ООП это ЕСТЬ и является вредным.
Глупо предпологать что в этих языках ООП проетирование ведется плохо именно из-за наличия возвр. параметров.
Глупо. Глупо заводить еще одно состояние объекта для промежуточных и чисто технологических операций.
Глупо писать окружение для этого состояния.
Глупо перекраивать методологию проектирования только под 1 конкретный язык.

плохо, когда не занимаешься сопровождением задач, разработанных только на основе проектирования ООП
(кстати - когда вышел Пролог (знаком?), и никакого ООП рядом не было, все , абсолютно все пытались писать на Прологе. тут я вижу такой-ж перегиб).

Хочешь маленьккую задачку?
Как в учебниках.
Есть банк, в нем счета,
и есть платеж, в одного счета на другой определенной суммой.
Как ты подойдешь к решению такой задачки? (только не подумай что я подкалываю - как напишешь, я приведу изменения задачки, возникшие в результате изменения внешних условий).