I have to say that I “upgraded” one site to EE 2…. and I seriously think that I won’t be doing any other sites for a long long time.
Personally, I find that using the new control panel to be a huge time waster.  It’s taking more clicks to get around to the areas that were clearly visible in EE 1.6._.
Then all my templates… things that don’t work… lack of a gallery… what to do with all those images in the 1.6._ gallery?
So much “wrong” with this upgrade…. I just don’t see the benefit of wasting so much time upgrading… and for what?

Too bad.  I thought this would have been a good step forward.  But if the step is this “painful”.... what really is the use?

Thanks for the good times with 1.6._.

otto

Like I said earlier, if “final” is added to various places, EllisLab needs to seriously think about what they’re doing and add some hooks into key placees. For instance, my Custom System Messages extension fixes a serious problem with a, how should I say it, craptastic and lazy way of handling ALL success and error messages. Please don’t take this and other means of extending EE away from us.

litzinger - 28 October 2010 03:19 PM

Please don’t take this and other means of extending EE away from us.

+1. At least not without alternative ways to do it.

I’ve used the session_start hook with success to add additional functionality into EE which could not have been done with regular hooks. I have already created a feature request for a better way of extending core classes but for now this is all we have.

Adding a final would definitively be a step in the wrong direction here. We need to extend core classes, you may not like it, but it’s sometimes a requirement.

EllisLabs adding final to some classes is a good idea. Inheritance is not the way to go to achieve these modifications to EE.  If you were using CodeIgniter and had complete control over the usage and implementation of all code then maybe, but in the case of EE you are going to run into many people breaking other people’s code and causing a support nightmare.

The best solution is for Ellislabs to add more hooks and get rid of the double call to call_user_func_array() for every hook call.  That is one of the slowest function calls in PHP and it is called 2 times everytime a hook is called.

Are we currently seeing a support nightmare because of this? People are using inheritance today ... you could say the same about hooks.

I think inheritance is vital, but of course it needs to be handled correctly. For instance, EE could provide a system where addons could “override” a core class and then, it it took control over that process, it could make sure there was maximum one override per class.

Bjørn Børresen - 29 October 2010 01:20 PM

I think inheritance is vital, but of course it needs to be handled correctly. For instance, EE could provide a system where addons could “override” a core class and then, it it took control over that process, it could make sure there was maximum one override per class.

Just as they do with the Extension “priority” property, developers would just start doing that to make sure that their add-on was the super-addon and that no other add-on would interfere with what it wanted to do.

I’m approaching this from a position of building a specific website - solving a specific case - which means having the possibility to extend core classes, to solve stuff that cannot be solved otherwise.

As we say here in Norway; don’t paint the devil on the wall .. if you get my point.

Inheritance is not the end all be all means of modifying and extending code in a OO system.  Delegation and notifications/callbacks/hooks are usaully better than inheritance for large systems with lots of third party code/plugins.

Hi Derek,

It seems that this discussion about adding “final” declarations is in many ways similar to discussion about “show_full_control_panel_end” hook. In general, both discussions are superficial and unproductive. Developers are saying: “Don’t take away from us our beloved ways of extending EE; these ways are essential in context of our projects”. To this EllisLab people answer: “These ways of extending EE are dangerous; they break things, they generate unneeded support requests, so no more creativity of this kind will be allowed”.

It seems that no party in this discussion will convince the other party. In some sense both sides are right: some ways of extending EE really can break things, but, on the other hand, these same ways are essential for some projects. In some sense EllisLab has upper hand in this discussion - they decide what to introduce and what not to introduce into EE. But significant restrictions on how EE can be extended in the end will lead to the Wiki article “How to make EE2.x as flexible as EE1.x” being written and many respected EE developers doing massive search/replace in EE core files upon each EE installation. Such guerilla warfare is not what either EllisLab or EE developers need.

What both EllisLab and developers need is creative approach to those ways of extending EE which might interfere with EE functionality or with functionality of other add-ons. Perhaps it could be proposed that those dangerous ways of extending EE could be enabled conditionally, i.e. disabled by default but could be enabled by by site-admin perhaps by changing some values in site’s config. Alternatively, or in addition to it upon installation of each extension which uses those dangerous ways an alert might be displayed informing users that something might break. Also such extensions can be displayed in other color, e.g. in red. There could be an option or button to disable all such extensions etc. And when something breaks support stuff can always ask a user either to disable all extensions or to disable those dangerous ones.

Simply removing such ways to extend EE as using “show_full_control_panel_end” hook or extending EE classes is a solution too crude for EE developers. There is much creativity which can be displayed in seeking solution satisfactory for both Ellis Lab and EE developers. Let’s be creative.

Well put, Laisvunas.

the3mus1can - 30 October 2010 02:27 PM

Inheritance is not the end all be all means of modifying and extending code in a OO system.  Delegation and notifications/callbacks/hooks are usaully better than inheritance for large systems with lots of third party code/plugins.

There is no replacement for inheritance. You can’t have a hook on every line (and in addition passing every conceivable piece of data and using the return values).

Personally I’d be happy just to have the option to extend core classes - it doesn’t even have to be bundled like addons are - just the possibility to extend the core on a project where it is needed, without doing an actual core hack.

deleted

Attached: please find replacement for inheritance.

Mostly I just wanted to see if it could be done.

Also I don’t like it when people tell me I can’t do something I want to do.

I’m not saying using this is a good idea, but if you want show_full_control_panel_end back, here it is.

Updated: fixed a pretty serious problem with the css controller
Updated: latest version now at http://devot-ee.com/add-ons/wallace/ - fixes similar problem with javascript controller

You are genius!

If EllisLab will not really restore show_full_control_panel_end but will introduce some weak substitute for it I will certainly use your solution!

airways - 25 November 2010 05:50 AM

Attached: please find replacement for inheritance.

Mostly I just wanted to see if it could be done.

Also I don’t like it when people tell me I can’t do something I want to do.

Don’t know if you’re referring to my “there is no replacement for inheritance” statement but I was talking in general (inheritance vs. hooks). This was sort of a OT discussion I guess that started when Derek mentioned introducing “final” (which would be a problem for many of us who rely on inheritance to avoid core-hacking).

Bjørn Børresen - 25 November 2010 08:25 AM

airways - 25 November 2010 05:50 AM

Attached: please find replacement for inheritance.

Mostly I just wanted to see if it could be done.

Also I don’t like it when people tell me I can’t do something I want to do.

Don’t know if you’re referring to my “there is no replacement for inheritance” statement but I was talking in general (inheritance vs. hooks). This was sort of a OT discussion I guess that started when Derek mentioned introducing “final” (which would be a problem for many of us who rely on inheritance to avoid core-hacking).

Oh yes yes I know, no worries. I was just being tounge-in-cheek.

Honestly though I just think that there are things that are just easier to do with some simple text replacement. Overriding classes works for a lot of the broad strokes but when it comes to more subtle changes, and when it comes to things that the API designers haven’t thought of, it’s nice to have something to fall back on.

Personally I like the model of having a system that just lets you do whatever you want - be it show_full_control_panel_end, mix-ins, or Extends keywords (http://docs.realsoftware.com/index.php/Extends) or other such things that a lot of purists might consider “hacks”.

The bottom line is they let you get your job done and they let you do things that the original designers of a system might not have thought of. That’s really all I care about.

And to be honest? I’ve never had a problem with extensions competing for show_full_control_panel_end that I couldn’t solve pretty quickly. I would tend to think that anyone who says that it is unworkable probably just hasn’t done very many real-world EE implementations. It is almost never an issue.

The bottom line is they let you get your job done and they let you do things that the original designers of a system might not have thought of. That’s really all I care about.

And to be honest? I’ve never had a problem with extensions competing for show_full_control_panel_end that I couldn’t solve pretty quickly. I would tend to think that anyone who says that it is unworkable probably just hasn’t done very many real-world EE implementations. It is almost never an issue.

Perfectly said.

airways, you’re a genius. Very clever name too.