"Дядя, что я сделал неправильно?" aka порка кода

[berkut]

trigger_error

а что, исключения делают триггер_еррор вообще бессмысленным? это просто вопрос.

Конструктор. Значение параметра по умолчанию null, но при null происходит вытаскивание параметра из $_SERVER['REQUEST_URI']. Не проще ли написать в значении по умолчанию?

а куда по умолчанию? подходит только

public function __construct($url_str = $_SERVER['REQUEST_URI'])

но это-же parse error. поясни, куда его ещё по умолчанию воткнуть.

параметр строковый проверки тоже нет.

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

buildURL. Закладывание на схему mailto. Зачем, если это абстрактный класс?

ну внём есть определённые методы. маилто должен обрабатываться везде - ибо главное предназначение класса - работа с УРЛ, но не с html ссылками. обработка mailto помоему не помеха + к этому, не нужно повторять по сути одинаковый функционал в потомках, даже если этот потомок не расчитан на работу с html ссылками.

Еще, нет метода isInternal чтобы в разные цвета ссылки красить.

а класс вообще не расчитан на сборку html ссылок(<a href>)

И зачем нужна иерархия? Какие еще классы кроме URL планировались?

ну типо что-бы можно было работать с нестандартными uri, типо /news/2007/12/31 или с каким-нибудь извратом типа /news.php/year-2007,month-12 - чтоб из них можно было выдирать параметры и работать спокойно с ними и собирать их обратно. можно было реализовать сразу универсальную обработку и разделитили параметров и т.д. устанавливать в свойствах - но зачем таскать лишний код там, где он не нужен, к тому-же это палюбас медленее parse_url() + parse_str() + http_build_query()
поэтому и иерархия

 

[StUV]

а что, исключения делают триггер_еррор вообще бессмысленным?

исключения удобнее
больше функциональных возможностей
триггер_еррор - вполне подходит для "скрипта за 10баксов, написанного в курилке за 5 мин."

-~{}~ 29.01.08 14:19:

но впихивать везде где только можно проверки - помоему не очень хорошо - код засоряется

в обратном случае увеличивается время дебага

 

[berkut]

исключения удобнее
больше функциональных возможностей

больше-то да, но они не заменяют функционал trigger_error()
ибо

set_exception_handler ( callback exception_handler )
Sets the default exception handler if an exception is not caught within a try/catch block. Execution will stop after the exception_handler is called.

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

 

[StUV]

мне обязательно надо везде ловить исключение иначе скрипт сдохнет на исключении

это проблема проектирования, но не использования
или косяк из разряда "забыл/поленился"...

throw без catch с последующим падением скрипта закладывается в архитектуру и не должен перехватываться "магически"

 

[berkut]

throw без catch с последующим падением скрипта закладывается в архитектуру

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

 

[CatManZero]

Автор оригинала: berkut
больше-то да, но они не заменяют функционал trigger_error()
ибо
а если ошибка так се, я хочу бросить E_USER_NOTICE шоб просто в логе было, то мне обязательно надо везде ловить исключение иначе скрипт сдохнет на исключении

Такие ситуации можно разруливать глобальным try-catch-ем
Что-то вроде этого можно сделать:

try {
  run();
}
catch(CriticalException $e)
{
  trigger_error(...)
}
catch(NotCriticalException $e)
{
  throw $e;
}

 

[StUV]

catch (Exception ...) на верхнем уровне

такое ощущение просто складывается

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

за собаки, магичекий перехват нотайсов/варнингов, и тп... - нужно руки отрывать

 

[atv]

которые не должны вызывать смерть скрипта, но о которых не плохо-бы, так на всякий, в лог написать

Для таких случаев ставиться глобальный перехватчик исключений try {} catch, который будет перехватывать неотловленные исключения, и делай с ними что хочеш.

 

[tf]

вот блин моя бодяга
http://phpclub.ru/paste/index.php?show=1975

 

[berkut]

atv а зачем городить такой огород, запихивать весь код в глобальный try catch? а во вторых, после throw код до блока catch не будет выполнен - поэтому это не замена trigger_error(). Может всё-таки исключения и trigger_error предназначены для несколько разных вещей и они друг-друга не исключают, а?

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

StUV а может все эти магические вещи и делают эти языки столь популярными, и поэтому даже ты, ярый сторонник строгой типизации и прочего сидишь на форуме ненавистного и глючного пЭхЭпЭ, а не Java к примеру

 

[StUV]

tf
перым делом бросается в глаза куча хтмл-я =)

-~{}~ 29.01.08 15:27:

ненавистного и глючного пЭхЭпЭ

я этого не говорил
глючность как-раз в него привносят фичи типа

после throw код до блока catch не будет выполнен

т.е. ты просто на стадии проектирования закладываешься на некоторый % кривизны собственного кода
но вместо того, чтобы в этом себе признаться - расхваливаешь преимущества использования trigger_error

-~{}~ 29.01.08 15:30:

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

 

[tf]

StUV, ты предлогаеш для каждого куска вывода html сделать отдельные функции или мини шаблоны?
это самый верхний уровень у меня который работает с шаблонами

 

[StUV]

tf
хм
в крайнем случае я бы сделал прослойку view-классов с "унифицированным" интерфейсом - чтобы в "случае чего" его можно было подменить/расширить
но из класса обрабатывающего данные "хтмл убрать однозначно" =)

 

[tf]

прослойку view-классов

хорошо, можно и так
еще один http://phpclub.ru/paste/index.php?show=1976

 

[atv]

т.е. ты просто на стадии проектирования закладываешься на некоторый % кривизны собственного кода

+1

Может всё-таки исключения и trigger_error предназначены для несколько разных вещей и они друг-друга не исключают, а?

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

 

[StUV]

tf
многа кода - ниасилил
по существу - что делает метод getJsSetData в классе abstract_object_edit ?..

 

[tf]

StUV, отдает js код, который обновляет содержимое формы + js код который показывает ошибки в заполнении формы (при наличии оных)

 

[StUV]

tf
я не про "что делает метод?" - а как он вообще попал в класс object_edit, да еще и абстрактный ? =)

 

[tf]

StUV
у abstract_modul_edit есть набор классов типа abstract_object_edit, у того есть класс формы
только modul_edit умеет отдавать аяксовый ответ клиенту, поэтому у каждого object_edit он забирает js код для отдачи клиенту - так и появился
никак не предлогалось что modul_edit будет как-то оперировать самой формой, ей занимается только object_edit

 

[kode]

мои мессаги игноред...

эназер:
http://phpclub.ru/paste/index.php?show=1977