Problem/Motivation
At the moment the view classes has a lot of different variables and methods
which are at the end sadly only somehow related to a view, but not really seperated.
Especially for the config entity it would be helpful to split the runtime information from the configuration.
Proposed resolution
Split up the class into two clases: ViewStorage and ViewExecutable or something named like that.
ViewExecutable
The ViewExecutable would contain information like:
- base_table, base_field
- built,executed,editing
- args,build_info,result,pager-information
- exposed_data, exposed_input
- current_display
- etc.
The ViewExecutable can be constructed by using a view entity object in the constructor.
So the code could look like:
public function __construct(ViewStorage $storage) {
$this->storage = $storage;
}
To be able to access the storage information you could either access them via $view->storage->foo though as you see this requires quite
some work for the existing code. Therefore i propose some magic __get and __set which will first look at the storage and then return
information stored on the ViewExecutable object.
ViewStorage
View storage will certainly hold all the "entity" information of a view so:
- name
- base_table
- human_name
- display
- etc.
Remaining tasks
Decide what belongs to the executable
API changes
The objects will be seperated so maybe api has to changed as well.
Comment | File | Size | Author |
---|---|---|---|
#60 | views-1751358-59.patch | 84.26 KB | dawehner |
#59 | views-1751358-59.patch | 70.82 KB | tim.plunkett |
#57 | views-1751358-57.patch | 68.38 KB | dawehner |
#54 | views-1751358-53.patch | 70.82 KB | tim.plunkett |
#52 | views-1751358-52.patch | 68.43 KB | tim.plunkett |
Comments
Comment #1
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedI created a discussion group on this: http://groups.drupal.org/node/249958.
Comment #2
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedWould you like to work with me on that particular problem ? I need some understanding of the overall architecture then we can categorize attributes and parameters.
Comment #3
dawehnerJust updated how to construct a ViewExecutable/ how to access information in itself.
Comment #3.0
dawehnerupdated summary
Comment #4
dawehnerAt least adding a new view works, but then a lot of things break.
One question i do have and could not answer yet:
Where should the displays be "stored" on runtime.
It seems to make sense to store the displays on the executor object.
Ideally viewDisplay could be removed so $executable->display['default']->getOption() could work
but to reduce the amount of changes for now i would vote for $executable->display['default']->handler as it is now.
On the storage just the display_options are stored as the pure array.
Comment #6
tim.plunkettRerolled and fixed the one line.
Comment #8
tim.plunkettMissed the rename while rerolling.
Comment #10
tim.plunkettFixed up a couple things
Comment #12
tim.plunkettPushed up http://drupalcode.org/sandbox/damiankloip/1685040.git/shortlog/refs/head...
Comment #14
tim.plunkettMore fixes.
Comment #16
dawehnerJust posting a patch which is not applied to the branch yet.
This allows to at least not fatal all of the tests.
Some random spin-off based on this issue: #1787270: Split up default views into one per module
Comment #18
dawehnerThanks for helping on this issue!
Committed the changes from #14 and made some fixes on top of it.
Regarding magic methods: you don't have to do the default code, as the function will never be called without it.
http://www.php.net/manual/en/language.oop5.overloading.php#object.get
...
Comment #20
tim.plunkettSorry about the unpushed code.
Your last patch left out the & for __get
Comment #22
tim.plunkettI had way less fails in #14, going to figure out why
Comment #23
tim.plunkettMore stuff.
Comment #25
Lars Toomre CreditAttribution: Lars Toomre commented@tim.plunkett... I was looking at the most recent patch and was confused at times by the ordering of the various 'use' statements. I am not sure what our standard is, but does it make sense to put them in alphabetical order if there is no standard yet?
Comment #26
tim.plunkettRight now we're just trying to get it to work, we can clean that up before commit.
Plus, there is no core convention.
Comment #28
tim.plunkettMore fixes.
Comment #30
tim.plunkettAdded more fixes, but also a couple more tests.
Comment #32
tim.plunkettWith the exception of the ViewTest failure, it's all 404 stuff, which I couldn't track down.
I pushed all of my commits up to 1751358-split-up in Damian's sandbox.
Comment #33
dawehnerPushed two changes. The first one fixes the menu issue. The second one cleans up some code.
Comment #35
dawehnerAnother try to upload a patch.
Comment #37
dawehner94501b7 Make sure that only enabled views are used in hook_menu
This commit should fix a lot of the test errors, maybe this time the test actually applies,
but i don't 100% get that.
Comment #39
dawehnerThere should be more green with that.
e5a2633 document the style_options variable and rename setItemsPerPage on the pager plugin
Comment #40
dawehnerNow even with a patch
Comment #41
tim.plunkettAdded an __isset()
Comment #43
tim.plunkettThere was a bug in cloneView.
Comment #44
tim.plunkettOkay, now I'm throwing exceptions in the else cases of the magic methods, to try to find bad properties.
Comment #46
tim.plunkettMore fixes.
Comment #47
tim.plunkettOkay, here's the patch above without the debug code, and another patch with more debug code.
Comment #50
tim.plunkettHm, removed too much.
Comment #52
tim.plunkettAdded a helper for initDisplay.
Comment #53
aspilicious CreditAttribution: aspilicious commentedWhy are we removing the camelcase on functions? :s
Comment #54
tim.plunkettOkay! Here it is with docs and @todos added.
I can create follow-ups after I go to lunch :)
But I think this is good to go.
Comment #56
dawehnerAssign myself.
Comment #57
dawehnerWhen the storage controller saves a config file you don't have a executable yet
and you also don't want one.
so let's for __set first check whether certain properties exists
Comment #58
dawehnerA list of properties which aren't on the viewExecutable __set
maybe more but couldn't find more.
So if we fix these usages we could maybe remove the __set helper.
Comment #59
tim.plunkettI forgot to push my docs changes before, this includes the fix from #57.
I think we should phase out the magic methods in a follow-up.
Comment #60
dawehnerNew version which fixed a lot of the existing code (beside display) to access the right object automatically (getHumanName(), name, base_table, base_field, etc.)
Comment #62
tim.plunkettI'd say #59 is RTBC, and deal with #60 in a follow-up.
Comment #63
tim.plunketthttp://drupalcode.org/project/views.git/commit/65fb7f9
http://drupalcode.org/project/views.git/commit/74ce4fc
Committed!
#1788232: Move UI properties from ViewExecutable to a new ViewUI class is the first follow-up.
Comment #64.0
(not verified) CreditAttribution: commentedsome updates