Annotation of kupuMPIWG/plone/TODO.txt, revision 1.1
1.1 ! dwinter 1: ==============
! 2: TODO for Plone
! 3: ==============
! 4:
! 5: [also some general todos. Some of these are firm ideas, others are
! 6: just idle thoughts]
! 7:
! 8: ===============
! 9: Plone 2.1 todo
! 10: ===============
! 11: 1. fix bugs
! 12: 2. Make Kupu use the Resource registry to optimise JS and CSS files.
! 13:
! 14: Other thoughts
! 15: ===============
! 16: Make the toolbar customisable from Plone control panel, possibly by
! 17: making the kupu tool into an action provider.
! 18: [DB: I'm not sure this will work as I think the information we need is
! 19: rather different than the usual action provider. After all, our
! 20: actions are all client side javascript not server-side methods.
! 21: However the general idea is good.]
! 22:
! 23: Make the initialisation data driven so it can be more easily
! 24: customised (and driven from plone cpanel.
! 25:
! 26: Add user-level documentation to kupu.oscom.org. Make the Plone
! 27: butterfly direct to a plone specific documentation page?
! 28:
! 29: Improved source editing mode? At the least we should apply the content
! 30: filtering when switching into source mode.
! 31:
! 32: Need a pulldown to set classes on non-block tags: e.g. span, a, etc.
! 33:
! 34: Make the ul/li pulldown options customisable through cpanel, allow
! 35: them to set classes as well as list-style-type.
! 36:
! 37: Refactor classes to do proper base class initialisation. This also
! 38: means we need to use .prototype. consistently for methods.
! 39:
! 40: Move Plone paragraph styling back into the common code.
! 41:
! 42: Generic RPC mechanism to allow tools to be defined entirely on the
! 43: server?? JSON-RPC?
! 44:
! 45: Triage on the issue tracker: which issues are still valid, which are
! 46: fixed or otherwise outdated, which do we fix and which are unfixable.
! 47:
! 48: Make it easier to enable the output transforms. Hotfix ATCT?
! 49:
! 50: ====================
! 51: Backport into common
! 52: ====================
! 53: Merge PloneKupuUI class back into common so that other variants of
! 54: kupu can support classnames on styles.
! 55:
! 56: Code to make links relative should also be shareable.
! 57:
! 58: Collapse saveDataField and prepareForm together:
! 59:
! 60: - Maybe make _serializeOutputToString use config to select body or
! 61: full html.
! 62:
! 63: - prepareForm should accept field name or field object and only
! 64: create output field if it doesn't already exist.
! 65:
! 66: - makeLinksRelative should accept configurable pattern for URLs which
! 67: are to lose their path completely. For Plone this should default to
! 68: resolveuid.
! 69:
! 70: ================
! 71: TODO for drawers
! 72: ================
! 73:
! 74: These are probably core issues rather than specifically Plone.
! 75:
! 76: - image drawer should go straight to the correct location when opened
! 77: on an existing image (is this even possible?) so you can adjust
! 78: alignment, captioning etc. without having to reinsert the image.
! 79:
! 80: - add toolbox drawer to run macros which aren't deemed important
! 81: enough to be directly on the toolbar.
! 82:
! 83: - Uploading an image doesn't let you float the image. Perhaps the
! 84: upload handler should simply refresh the drawer with the uploaded
! 85: file selected, then you can set all the usual image options on an
! 86: uploaded image.
! 87:
! 88: And a Plone one:
! 89:
! 90: - Want an Archetypes widget which uses Kupu drawers so we can easily
! 91: incorporate them into reference pickers etc. This should be easier
! 92: now we have multi-instance Kupu as we no longer need to care whether
! 93: or not there is already a Kupu on the page.
! 94:
! 95: =====================
! 96: IE problems and fixes
! 97: =====================
! 98:
! 99: o importNode(node) fails on XML Document nodes. Use
! 100: node.cloneNode(true) as a hack.
! 101:
! 102: o drawer changes height when navigating with IE. Fixed by forcing the
! 103: entire drawer to refresh in IE, but there must be something simpler we
! 104: could do to have the same effect.
! 105:
! 106: ========================
! 107: Other assorted ideas
! 108: ========================
! 109: Florian Schulze wrote:
! 110: > In plone with ATContentTypes, Images can have various sizes. I would
! 111: > like to be able to select the scale when inserting the image into a
! 112: > document, how can I achieve that. I guess I have to change the drawer
! 113: > somehow, but I have no clue where and how.
! 114: >
! 115:
! 116: To do this properly will require some effort (which is why I haven't
! 117: attempted to do it prior to the Plone 2.1 release).
! 118:
! 119: On the server we need to find out the available sizes for the images. I
! 120: guess that information isn't in the catalog, and we don't want to hit every
! 121: image when sending a listing, so the only option would be to assume that
! 122: every object with a given portal type has the same list of scales (I'm not
! 123: even sure how it easy it is to get a list of scales from the type rather
! 124: than from an instance of the type). Alternatively we add a list of scales
! 125: to the configlet which would allow you to restrict the list to a useful
! 126: subset.
! 127:
! 128: That information then has to be sent to the kupu client. I think probably
! 129: we have to send a separate list of sizes for each image (you might have
! 130: multiple portal types not all of which are scalable) or maybe just for
! 131: each portal type. By this point I'm thinking that what we actually have is
! 132: a set of qualifiers which can be added to the image URL rather than
! 133: necessarily being sizes. For example you might want to add support for
! 134: greyscaling images or for cropping.
! 135:
! 136: On the client side we need to add the modifier to the image dialog, either
! 137: as a select box or radio buttons (probably determined by the number of
! 138: options) and then we need to modify the url to match.
! 139:
! 140: I would like to see if we can rationalise the xml to avoid adding new tags
! 141: for every new feature to be sent from the server. Also it would be nice to
! 142: see if there is a way to avoid changing the client js every time some
! 143: feature such as this is added. This might be part of a more general
! 144: refactoring of the drawers such as I know Paul is keen to try.
! 145:
! 146: One option would be for the xml to include a section such as:
! 147:
! 148: <options>
! 149: <type name="Image">
! 150: <input name="alt" size="40">Alt text</input>
! 151: <radio name="align">
! 152: <option value="image-left">Left</option>
! 153: <option value="image-centre">Centre</option>
! 154: <option value="image-right">Right</option>
! 155: </radio>
! 156: <select name="size">
! 157: <option value="">Normal</option>
! 158: <option value="/mini">Medium</option>
! 159: <option value="/thumb">Small</option>
! 160: </select>
! 161:
! 162: <checkbox name="captioned">Add a caption</checkbox>
! 163:
! 164: <action type="text/javascript"><![CDATA[
! 165: if (options.alt) node.alt = options.alt;
! 166: node.className = options.align.value;
! 167: node.url = url + options.size.value;
! 168: if (options.captioned) {
! 169: node.className += " captioned";
! 170: }
! 171: ]]></action>
! 172: </type>
! 173: </options>
! 174:
! 175: So for a given portal_type (and we would have to add the type to the xml
! 176: returned) some controls (select, checkbox, radio, text input) could be
! 177: added to the dialog, and when the image is inserted the associated
! 178: javascript would be executed in a function with parameters node,
! 179: url,className,options to modify the newly inserted image.
! 180:
! 181: [This isn't fully thought through yet: we also need to get the drawer
! 182: picking up existing image settings, the alt text needs to get a default
! 183: from somewhere, and the image size needs to be set somewhere on the tag.]
! 184:
! 185: The last of these makes life a bit harder since the size now depends on the
! 186: exact URL we generated. I suspect we should add an onload handler to every
! 187: image in kupu and when the image successfully loads make it update the tag
! 188: to the correct size. The onload attribute will of course be stripped when
! 189: the file is saved.
! 190:
! 191: =================================================
! 192:
! 193: Arrange a Kupu sprint
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>