============== TODO for Plone ============== [also some general todos. Some of these are firm ideas, others are just idle thoughts] =============== Plone 2.1 todo =============== 1. fix bugs 2. Make Kupu use the Resource registry to optimise JS and CSS files. Other thoughts =============== Make the toolbar customisable from Plone control panel, possibly by making the kupu tool into an action provider. [DB: I'm not sure this will work as I think the information we need is rather different than the usual action provider. After all, our actions are all client side javascript not server-side methods. However the general idea is good.] Make the initialisation data driven so it can be more easily customised (and driven from plone cpanel. Add user-level documentation to kupu.oscom.org. Make the Plone butterfly direct to a plone specific documentation page? Improved source editing mode? At the least we should apply the content filtering when switching into source mode. Need a pulldown to set classes on non-block tags: e.g. span, a, etc. Make the ul/li pulldown options customisable through cpanel, allow them to set classes as well as list-style-type. Refactor classes to do proper base class initialisation. This also means we need to use .prototype. consistently for methods. Move Plone paragraph styling back into the common code. Generic RPC mechanism to allow tools to be defined entirely on the server?? JSON-RPC? Triage on the issue tracker: which issues are still valid, which are fixed or otherwise outdated, which do we fix and which are unfixable. Make it easier to enable the output transforms. Hotfix ATCT? ==================== Backport into common ==================== Merge PloneKupuUI class back into common so that other variants of kupu can support classnames on styles. Code to make links relative should also be shareable. Collapse saveDataField and prepareForm together: - Maybe make _serializeOutputToString use config to select body or full html. - prepareForm should accept field name or field object and only create output field if it doesn't already exist. - makeLinksRelative should accept configurable pattern for URLs which are to lose their path completely. For Plone this should default to resolveuid. ================ TODO for drawers ================ These are probably core issues rather than specifically Plone. - image drawer should go straight to the correct location when opened on an existing image (is this even possible?) so you can adjust alignment, captioning etc. without having to reinsert the image. - add toolbox drawer to run macros which aren't deemed important enough to be directly on the toolbar. - Uploading an image doesn't let you float the image. Perhaps the upload handler should simply refresh the drawer with the uploaded file selected, then you can set all the usual image options on an uploaded image. And a Plone one: - Want an Archetypes widget which uses Kupu drawers so we can easily incorporate them into reference pickers etc. This should be easier now we have multi-instance Kupu as we no longer need to care whether or not there is already a Kupu on the page. ===================== IE problems and fixes ===================== o importNode(node) fails on XML Document nodes. Use node.cloneNode(true) as a hack. o drawer changes height when navigating with IE. Fixed by forcing the entire drawer to refresh in IE, but there must be something simpler we could do to have the same effect. ======================== Other assorted ideas ======================== Florian Schulze wrote: > In plone with ATContentTypes, Images can have various sizes. I would > like to be able to select the scale when inserting the image into a > document, how can I achieve that. I guess I have to change the drawer > somehow, but I have no clue where and how. > To do this properly will require some effort (which is why I haven't attempted to do it prior to the Plone 2.1 release). On the server we need to find out the available sizes for the images. I guess that information isn't in the catalog, and we don't want to hit every image when sending a listing, so the only option would be to assume that every object with a given portal type has the same list of scales (I'm not even sure how it easy it is to get a list of scales from the type rather than from an instance of the type). Alternatively we add a list of scales to the configlet which would allow you to restrict the list to a useful subset. That information then has to be sent to the kupu client. I think probably we have to send a separate list of sizes for each image (you might have multiple portal types not all of which are scalable) or maybe just for each portal type. By this point I'm thinking that what we actually have is a set of qualifiers which can be added to the image URL rather than necessarily being sizes. For example you might want to add support for greyscaling images or for cropping. On the client side we need to add the modifier to the image dialog, either as a select box or radio buttons (probably determined by the number of options) and then we need to modify the url to match. I would like to see if we can rationalise the xml to avoid adding new tags for every new feature to be sent from the server. Also it would be nice to see if there is a way to avoid changing the client js every time some feature such as this is added. This might be part of a more general refactoring of the drawers such as I know Paul is keen to try. One option would be for the xml to include a section such as: Alt text Add a caption So for a given portal_type (and we would have to add the type to the xml returned) some controls (select, checkbox, radio, text input) could be added to the dialog, and when the image is inserted the associated javascript would be executed in a function with parameters node, url,className,options to modify the newly inserted image. [This isn't fully thought through yet: we also need to get the drawer picking up existing image settings, the alt text needs to get a default from somewhere, and the image size needs to be set somewhere on the tag.] The last of these makes life a bit harder since the size now depends on the exact URL we generated. I suspect we should add an onload handler to every image in kupu and when the image successfully loads make it update the tag to the correct size. The onload attribute will of course be stripped when the file is saved. ================================================= Arrange a Kupu sprint