Confirmed users, Bureaucrats and Sysops emeriti
969
edits
SVG:Data Storage: Difference between revisions
Jump to navigation
Jump to search
add issue
No edit summary |
(add issue) |
||
| Line 8: | Line 8: | ||
The problem this document aims to address is how and where to store the typed data. There are significant problems to be overcome. | The problem this document aims to address is how and where to store the typed data. There are significant problems to be overcome. | ||
== Issues that are Independant of Strategy == | |||
* We plan to use tearoffs for the object heavy SVG DOM. How are the tearoffs to access their corresponding typed object trees on the content object? First, how will they get to the right attribute? Then how do they identify which item in a tree and/or list corresponds to them? | |||
* How do changes to values of the objects in the typed object trees result in the correct notifications? Does every object in the tree have to keep a pointer to its corresponding nsAttr? Or to its owning content object <b>and</b> corresponding attribute? Or to its owning tree object (notifications to go up the tree first)? | |||
== Strategies == | == Strategies == | ||
| Line 29: | Line 35: | ||
* What should tearoffs do if they are accessed after RemoveAttribute has been called? They could have knowledge of default values, but frames (and probably other code?) will also need to have this knowledge since often attributes and their typed object tree won't exist. | * What should tearoffs do if they are accessed after RemoveAttribute has been called? They could have knowledge of default values, but frames (and probably other code?) will also need to have this knowledge since often attributes and their typed object tree won't exist. | ||