Changes between Initial Version and Version 1 of Ticket #11341, comment 6
- Timestamp:
- Jan 19, 2014, 4:07:23 PM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #11341, comment 6
initial v1 5 5 1. Link plugin cannot handle link inside <figure>, because it's image2's territory. 6 6 2. Linked captioned image has to stay linked when caption is removed and vice versa. This has to be handled by image2. 7 3. We should not duplicate link feature inside image2 dialog. This w ill require code duplication or reusing link tabs from link dialog, but the latter is very hard, because non-widget dialogs are not reusable, because they don't implement model interface (like widget's data).8 4. In the old image dialog, link tab is very basic because it duplicates links code instead of reus eit.7 3. We should not duplicate link feature inside image2 dialog. This would require code duplication or reusing link tabs from link dialog, but the latter is very hard, because non-widget dialogs are not reusable. Additionally, link button would have to work in any case, so it's just simpler to open link dialog. 8 4. In the old image dialog, link tab is very basic because it duplicates links code instead of reusing it. 9 9 10 10 Therefore: … … 12 12 1. Link dialog should be reused to link captioned image2. 13 13 2. Image2 does not have to create link - it has to update image2's data with link's properties. Link should be created only when downcasting image2 or removing caption. 14 3. By default link command opens link dialog in the old way. If data object has not been passed to the dialog, the dialog looks for <a href> element as it does now, scans it and transforms it to data object which is passed to every field on setup and commit. (FYI: Link plugin does this already!) The only difference will be that we will be able to pass custom data object to link dialog.14 3. By default link command will open link dialog in the old way. If data object has not been passed to the dialog, the dialog looks for `<a href>` element in current selection as it does now, scans it and transforms it to data object which is passed to every field on setup and commit. (FYI: Link plugin does this already! The only difference will be that we will be able to pass custom data object to link dialog.) 15 15 4. Now, image2 has to pass link data object to link dialog when opening it on captioned image2 (empty object has to be passed if image is not yet linked). This can be achieved e.g. by listening on link's command exec and altering the default action. 16 16 5. On commit, widget's data has to be updated. … … 18 18 What cannot be solved: 19 19 20 1. Applying link to selection containing more than a widget. In this case link will be applied the old way, only to nested editables. 20 1. Applying link to selection containing more than a widget. In this case link will be applied the old way, only to nested editables. For me it's acceptable and even expected. 21 21 22 22 What has to be checked: 23 23 24 1. How data object can be passed to dialog. 24 1. How data object can be passed to dialog. Especially that passing data object to dialog fields may become a standard, so a clean way of doing that would be reused in the future in other dialogs. 25 2. What worries me though, is that widgets pass widget instance to the dialog fields, so there will be already two ways to setup a dialog. Therefore, we may use the same idea as implemented in widgets for links. Instead of passing data object, link object (instance of link feature class) would be passed. A model interface would be mixed in link class (the same way as CKEDITOR.event is) adding #setData method and #data property and event. Additionally I would implement transactions (start, end methods), because currently in widgets to avoid too much #data events, we cancel them during committing dialog and fire one at the end. If this idea is implemented we'll have one, standardised way of setting up and committing dialogs.
