Last modified: 2013-11-04 14:38:34 UTC
Claims (not Statements) should be enabled for other Entity types than Item. We already had this working, then we disabled this. Then we implemented Statements for Items. The Statements system is based on the Claims UI, so Claims should still work fine but since we are not using this I am not 100% sure it will work out of the box and as far as I know did all of the Selenium tests change to be Statement specific, so we had to work on those tests. Anyhow, I think the sooner we enable this, the better. If we don't, the chances that we change or write new code which is Statement specific instead of always considering UI using Claims only is more likely. So we could activate this at least in experimental mode for now and concentrate on getting tests running for both, Statements and Claims as well.
Might be worth to discuss architecture of the jQuery.wikibase.claimview/statementview over again as well. Right now they use widget inheritance but I can see certain advantages (also disadvantages though) if we would use composition instead: If we had a statementview widget which would use a claimview as composition, I could see the following: Advantage: + startEditing() would be clearly defined, you would just put the EVERYTHING into edit mode. If you have a statement and don't want to put everything into edit mode (which we currently don't want), you can simply get the widgets representing different parts of the statement, e.g. (1) basic Claim stuff / (2) References / (3) Rank, and set those into edit mode separately (which we want to do currently). By being able to make those differentiations, our toolbarcontroller would require less specific and exceptional handling implemented and we wouldn't have to add weird parameters to our startEditing() to only start edit mode for specific parts of the widget. The whole thing would be more generic and would at the same time allow simpler implementation of global edit modes later (e.g. editing a whole statement or a whole entity at the same time) Disadvantage: - One additional Widget instance per Statement which can be a factor in performance. Could be worse since there are not that many Statements, additional widget per Snak for example would be much worse. Other points involved: ~ Since we would have a Statement and a Claim widget, we would also get Events for both bubbling through the DOM. This is good for what I have mentioned in the advantage point but also is a performance aspect but first of all, I am not sure right now whether it makes sense or whether it is misleading. Opinions please. ~ The DOM structure would change, so we had (as of now) a outer DOM node with the Statementview's base class. Within that we would have a DOM node with the Claimview's base class. This might look weird since a Statement is a Claim. ~ We would perhaps blow up the code a little since we would have to forward certain functions from the Statementview Widget to the Claimview widget. On the other hand, we have to overwrite certain functions anyhow (e.g. startEditing?) so in those cases we might even benefit from the composition.
*** This bug has been marked as a duplicate of bug 49554 ***
