Isn't eZ Publish 4 supposed to provide such functionality (to override kernel classes)? Can anyone elaborate on that subject?
(...)
Here we go:
<i>Kernel classes may be overridden by classes in extensions, due to the new autoload regime (making kernel modifications mostly unnecessary), however this flexibility should be exercised with caution.</i> http://ez.no/developer/news/ez_publish_4_0
Yes it is currently possible to override core classes in eZ Publish 4 with the autoload system, but it's not a intentional feature so might change in the future.
Could you elaborate on what you need it for? (bugs / missing features...)
Overriding classes is of course not recommended in the long run since your override classes could break stuff in a future version and you need to closely watch any changes that are made to those classes each time you update/upgrade.
That's interesting, the way it was described during the partner meeting - I got an impression that it was a goal that was going to be achieved ;)
Yes, I do see the possible risks, even though I suspect that override system is always provides little bit of safety and flexibility more than direct modification of critical files. Since I don't know how it works exactly at this point, I cannot assess it and tell you whether I will find it useful in the future or not. Maybe once I've played with it a bit in the next days.
I'm mostly thinking of altering some of the system core functions and options. eZ Publish is quite well written and it's very tempting to make use of it ;) The other thing is that I still may not see all the direct and elegant solutions. One of such things: http://ez.no/developer/forum/general/poll_unique_vote_options_summary_and_questions
To add a view to an existing module, you could create the view in a custom module then add a virtual-url rule to make your custom view belong in the original module. One drawback: you cannot declare in module.php for module B that a view depends on an access function defined in module A. To do so, you'll have to do explicit perm checking within the view code.
Using url rewrites, you can also "take control" of existing views. Another way to reach the same goal is to change settings in site.ini so that your extension's modules/views are scanned before the kernel ones (but be careful with that)
Principal Consultant International Business
Member of the Community Project Board
You must be logged in to post messages in this topic!