Annotation of kupuMPIWG/plone/TODO.txt, revision 1.1.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>