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>