Products.RichDocument
by Martin Aspeli
RichDocument is a document type which provides the same fields as the standard Plone Document/Page type, but allows users to upload images directly into the document during editing.
A RichDocument is a folderish type with Image and File as the only permitted contained types. Two special widgets for managing contained images and attachments are provided near the bottom of the edit form, though you have to expand a collapsed fieldset to see them.
Once uploaded, images and attachments can be referenced in the document’s body text or inserted using editors such as kupu.
In addition, the user can optionally either automatically float the topmost uploaded image at the top left of the page, or display a box of thumbnails floating at the right of the page, on which the viewer can click to open the full-size image in a pop-up window. This is achieved using the Plone 2.1 ‘display’ menu.
RichDocument is released under the GNU General Public Licence, version 2. Please see http://gnu.org for more details.
Installation
Install in the usual way, using the QuickInstaller or Plone’s Add/Remove Products control panel.
This version works with Plone 3 and 4 only. Version 2.0 works with 2.1 and 2.5. Version 1.0 works with Plone 2.0.
Please see the Installing an Add-on Product tutorial for more information.
Acknowlegements
The ImagesManagerWidget was originally created for km|portal, a knowledge management system aimed at small businesses (c) 2004 Martin Aspeli.
RichDocument extends ATContentTypes. Thanks to Christian Heimes, Alec Mitchell and everyone else who made this such a useful framework.
The RichDocument view templates are derived from Plone’s document_view. The FileAttachment and ImageAttachment view templates are derived from Plone’s file_view and image_view templates respectively.
Dorneles Tremea contributed with some patches and added the i18n infrastructure.
Known Issues and Potential Improvements
The templates use presentational markup and style attributes in some places and could do with a cleanup.
It’s not possible to upload images while the object is still in the portal_factory. If the object is in the factory while it is being edited for the first time and the user uploads an image, it will be instantiated into the target folder first.
The image and attachment controls are submit buttons, managed via PortalFormController with custom actions registered during the installation. However, this button comes before the Save button on the form, and thus may steal the default button status - if the user presses Enter in the form, they may get a (benevolent) portal error message telling them they must upload an image.
The only re-ordering support provided directly by the manager widgets is “move to top”. This is useful in support of the single-image preview mode or to make an attachment in the attachments download box stand out, but more detailed re-ordering functionality may be desirable.
Changelog
3.5.1 (2014-08-21)
fixes MANIFEST.in in order to fix last broken release
3.5 (2014-08-20)
return the correctly rendered page when calling the RichDocument context
moved to github [petschki]
removed document_relateditems macro, caused problems with p.a.multilingual [agitator]
3.4 - 2012-01-23
Use getWidth/getHeight for image attachment thumbnails to prevent unauthorized errors. [mj]
3.3 - 2011-10-06
- Added Upload adapter for TinyMCE.
[tesdal]
3.2 - April 28, 2010
remove dependency Simple Attachment in metadata.xml to import step since installing the product via metadata.xml will fail since kupu does not think the RichDocument portal is available when Simple Attachment is registering it’s kupu linkable types. [vangheem]
3.1 - April 21, 2010
registerType need to support project name for Plone 4 support [vangheem]
fixed is_editable call for Plone 4 [vangheem]
handle kupu linkable installation [vangheem]
remove Extensions install directory [vangheem]
fixed bulgarian translation [vangheem]
3.0.2 - February 19, 2008
Register the skin layers for all skins. Without this RichDocument would not work when installed in sites using a custom theme. [wichert]
Repackaged RichDocument in egg form [wichert]
Modernise installation logic to use GenericSetup better. [optilude]
Set “add” permissions to make contributor role work properly . [optilude]
Add i18n domain to the zcml files to make the package title and FTI information translatable in the RichDocument domain. [optilude]
Release files for Products.RichDocument 3.5.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| Products.RichDocument-3.5.1.zip | 63.2 kB | Without provenance | Details |
Release files / Products.RichDocument-3.5.1.zip
| Download URL | Products.RichDocument-3.5.1.zip |
|---|---|
| Size | 63.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
ec93ceb43df5801431674837960ae49366f592d056653c2a3eb4f630a6555146
|
|
BLAKE2b-256 checksum How to use checksums |
b28de8e13df49b6c098c1e39568b9f30bccdbaeb3d22b09bde7b7269611c82a9
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
Security for Products.RichDocument 3.5.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.
