Annotation of kupu/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>