Здравствуйте, gaidar, Вы писали:
спасибо. содержательно. днем в гугле тоже самое нашел. только к сожалению после того как пост написал.
а вообще такого убожества как ASP.NET не встречал.
по работе столкнулся с ним хотелось сделать все граммотно поимел гемора на неделю работы, писец. проштудировал несколько книжек,
такое чувство что их пишут для полнейших идиотов. три года писал под веб на всем php, perl, модули апача, jsp, servlets, итд — нигде проблем не испытал.
НО БЛИН ЖИЗНЬ НАУЧИТ ПИРОЖКИ ЕСТЬ

(и жаль что сейчас ем пирожки от мелкомягких)
долбанная студия, котора как мелкомягкие обещают должна облегчить жизнь программисту, воспротивилась опозновать мой код и на Load я поимел ЙУХ.
в результате все получилось наоборот жизнь мне только усложнили.
а на счет ASP.NET меня добила взаимодействие с дизайнером(в текущем конттексте, человек который рисует и верстает, как правило, это два человека или полтора, один плюс его верстальщик взаимодействуют как одно целое, а чтобы права людей не ущемлять, скажем полтора. Но я отвлекся когда этому человеку поставили хрень на 2гига и сказали надо, человек взвыл

и я его понял) человек всю жизнь работал в блокноте, а за последнюю неделю поимел гемора, что чуть не уволился.
(верстает под xhtml в блокноте и очень шустро и граммотно) а когда программисты скинули убогие формы, что называется — картина Репина "Неждали, а они приплыли"
печально.
слов нет
Нашел пост Кевина Спенсера на эту тему. Меня на написание такого не хватило бы. Цитирую:
You have created a base page class called "CommonPageBase" and wired up an event handler ("Page_Load") to the "Load" event of the class, which inherits from System.Web.UI.Page. Notice that System.Web.UI.Page does not define an event handler for this event.
Next, you created a class called "Page_Base" which inherits "CommonPageBase" and wired up an event handler called "Page_Load" to the "Load" event of the class. Note that the base class already has a method called (named) "Page_Load." Now, there are several ways of handling an inherited class having a method defined with the same name as the name of a method in the base class.
First, unless there is a difference in what the inherited class and what the
base class do in this method, there is no need to re-define it in the
inherited class; it inherits it. Any method in a base class that is defined
as Overrideable, Overrides, or MustOverride is available to (and, in fact,
already exists in) all derived classes of that class. Any method defined as
NotOverridable is not able to be overridden by derived classes. But it can
be re-defined. I'll get back to that shortly.
Overrideable indicates that a derived class may override (re-define) that
member. Overrides indicates that the member overrides (re-defines) a member in a base class that the base class inherits, and can therefore be overridden in a derived class.
MustOverride indicates that an inherited class MUST re-define the member in
the base class
NotOverridable indicates that an inherited class may NOT override the member in the base class.
Now, when you create a method in an inherited class with the same name as a
method in the base class, this presents a problem to the compiler. The base
class has defined this method, and the derived class has defined a method
with the same name. So, how should the method (in this case) be executed
when called by name? There are several possibilities:
1. The base class can execute its definition of the method, and the derived
class can execute its definition of the method. Of course, the question then
becomes, which one executes first?
2. The derived class can execute its definition of the method, and the base
class can not.
3. The base class can execute its definition of the method, and the derived
class can not (not really possible).
4. The derived class can execute its definition of the method, and in doing
so, at a point of its own choosing, call the base class's implementation of
the same method.
Now, this dilemma is where the access modifiers (Overridable, MustOverride,
etc) come into play. These define the rules for deciding which of these
scenarios is selected.
If the method is overridable, the inherited class can define its
implementation of the method as "Overrides". This means that the base
class's implementation of the method will NOT be executed, unless the
derived class calls it directly (as in "MyBase.Page_Load()"). Note that the
derived class can call this base class method at any time, or not at all. In
fact, it can call the base class's implementation of that method from any
method in the derived class, as long as it is Public, Protected, Friend, or
Shared.
Now, if the method is not overridable, the derived class can actually, not
override it, but re-define it. This is what is referred to as "Shadowing" or
"Name-hiding." Generally, when you implement a method of the same name as a
base class method, in a derived class, and do not modify it with the Keyword
"Shadows," the program will compile, but the compiler will generate a
warning, to indicate that you have implicitly shadowed or hidden the member
of the same name in the base class. When a derived class hides or shadows a
method with the same name in a base class, the method is executed in the
derived class, but not in the base class, unless the derived class calls it
directly (as in "MyBase.Page_Load()"); Note that any method in a base class
may be shadowed (hidden) regardless of whether or not it is overridable.
I'm not sure why implicitly hiding or shadowing a member in a base class is
allowed. It often causes confusion, particularly in the cases of
inexperienced developers, or developers that are not using an IDE like
Visual Studio to create their apps, and cannot therefore see the
compiler-generated warning. But that is what Microsoft decided, for whatever
reasons. No doubt there was some discussion about it.
A bit more about shadowing: A method defined as "Shadows" does not have to
have the same signature (parameters and return type) as the method of the
same name in the base class. This is important, because of overloading.
Overloading is redefining a method with a different signature (parameters
and return type). Overloading a method in a base class, by changing its
signature, is not the same as Shadowing, or Name-hiding. So, if you overload
a method in a base class by creating a method with the same name and a
different signature, the base class's method is still available. It is
important to note this distinction, as there may be times when you want to
overload, and times when you may want to shadow, and it is best to do either
one intentionally!
So, if you define a method is a base class which you want to be Overridden,
it is best to define it as Overridable. You may then define the new version
of the method as Overrides. If you want a method to hide a member in the
base class, it is best to define it explictly as Shadows.
данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение
Здравствуйте, zer, Вы писали:
zer>а вообще такого убожества как ASP.NET не встречал.
zer>НО БЛИН ЖИЗНЬ НАУЧИТ ПИРОЖКИ ЕСТЬ
(и жаль что сейчас ем пирожки от мелкомягких)
К сожалению отчасти с тобой соглашусь. Как и водится у мелкомягких, сама идея АСПНет хорошая, но реализована ректально. Пока ты клепаешь простенькие формочки в дизайнере, проблем вроде бы никаких нет, как тока отойдешь от этого — начинается, и чем дальше, тем чудесатее и чудесатее, я уже забодался говоря откровенно — любая хорошая идея идея возникающая в моей светлой голове

упирается в какие-либо особенности аспнет, которые мешают ее реализовать по-человечески ...
Особенно намутили они с постом. Если ты создаешь че-нибудь динамически, то на посте проблем не оберешься плюс надо пересоздавать все контролы и/или тащить километровые вьюстейты в реквесте (сердце кровью обливается), хотя тебе зачастую нужен на посте тока вызов обработчика события и иногда EventArgs и ничего более.
приходится изобретать свои метОды, шаблоны страниц, отчасти возвращаясь к методам АСП.
в общем пообщавшись с сей технологией годик, я сделал вывод, что АСПнет хорош либо для клепания совсем простенький формочек по книжкам, либо для гуру-профессионалов, которым все нипочем и для которых главное не результат, а доскональное изучение этих самых хитростей, но не очень хорош для "среднего класса", которому надо быстро и безгеморрно писать более-менее сложный функциональный код.
Zer, что-то действительно перемудрил.
Если что-то не получается, это не значит, что плоха технология. Поверьте, ASP.Net позволяет делать все. И новичкам с помощью форм и не новичкам с помощью всего остального. И разметка нормально пишется, и проблем почему-то не возникает. Почему?
По теме. Могу писать только про 1.1. С 2.0 пока не работал. Обработчики событий вызываются методами рефлексии, если на странице включен AutoEventWireUp. В этом случае при загрузке страницы в классе Default_aspx будет искаться метод Page_Load с соответствующей сигнатурой. Это естественно снижает производительность и по умолчанию отключено (можно включить в директиве Page). Поэтому, чтобы при загрузке страницы вызвался метод Page_Load его нужно подписать на событие Load как писали выше:
this.Load += new EventHandler(Page_Load);
Смысл кода в базовом классе я тоже не понял...
Книжки вы наверное не те читали. Прежде чем выбирать книжку лучше спросите у людей какие книжки лучше. В любом случае не стоит покупать книжки с заголовками типа "ASP.Net за 24 часа".
Лучше купите "Программирование для Microsoft.Net" Джефа Просиза. А одна из лучших книжек по ASP.Net — "Основы ASP.Net с примерами на C#" Фрица Оньона (в оригинале "Essentional ASP.Net with examples in C#") — поможет понять многие внутренние механизмы ASP.Net.
данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение