Plug-ins Pro: Rich Text Editor Pro v22.1 and image handling within CLOB
It’s been some time since the last official release for the Plug-ins Pro Rich Text Editor plug-in. The freshly released version – 18th January 2022 – comes with quite big changes to how images are handled after adding them to this rich text editor.
I don’t want to duplicate the changelog – which you can read here –, but instead, I want to tell you how the current version can make your daily work with rich text stored in CLOB easier – if you are already doing it. Or – if it is your first time reading about the plug-in – let me convince you that Oracle APEX session state limitation – which is 32 767 characters – doesn’t apply to this rich text editor and keeping images separated from CLOB – but in relation to – is very simple.
Please, take your time and let me introduce you to the key features of United Codes Rich Text Editor Pro v22.1.
Images are NOW uploaded on page submission
Images are no longer uploaded when the end-user selects them from the desktop or pastes them from the clipboard. Now, all new images are always added as base64 images and they stay as part of CLOB – literally – until the end-user clicks the specific button defined by an APEX developer – which I’m sure you’re one of.
What happens when the end-user clicks the button “B” (not the button “A”)? Firstly, the plug-in checks if request “B” is defined as the request on which uploading images happens. After that, it checks if the editor’s content contains not-yet-uploaded images. If there are no images to upload, the page is submitted without any turbulences – nothing special. But! If the plug-in spots any image that should be uploaded – ie. base64 images – the plug-in shows its teeth and claws.
The page submission is canceled by the plug-in, then the plug-in starts the images uploading process. Uploading images is done through the REST service saving images in the database table/filesystem – or whatever-you-can-implement using PL/SQL code. Right after the last image is uploaded, the plug-in re-submits the page with the same request that was canceled at the very beginning.
From the perspective of the end-user nothing suspicious is happening. A page was submitted, some loading indicators were shown, the page reloads – the end-user continues working with an application. But, the end-user doesn’t have to know that the uploaded images are now part of CLOB, but not as base64 images – which increases CLOB length – but as URLs to images stored where the developer decided.
The biggest advantage over the prior version is that you can easily create CLOBs drafts without worrying about never-used images that were uploaded just because the end-user dragged and dropped them into the editor. When the right time comes, the end-user clicks the proper button uploading images and updating CLOB. The CLOB content is updated but all images are referenced by URLs, and it does reduce the CLOB volume. Keeping the relation between uploaded images and freshly created CLOB is as easy as creating a loop over the APEX collection used by the plug-in – you can expect an article about it!
If you are new to this plug-in, I encourage you to try the plug-in sample application.
If you are already using the plug-in, please remember that updating to v22.1 requires you to edit your application pages. In order to enable uploading images, you must set a new item level attribute Upload Image(s) on Request(s) to page request(s) on which uploading images must be performed.
Deleting removed images
Image handling is not just only the matter of uploading images, but also, it’s the matter of handling uploaded and later removed images – you don’t want your images table to grow in volume because of not published images, don’t you?
Previously, the plug-in was tracking images statuses in the plug-in collection and it was up to a developer to implement a process removing images. With this release, tracking images is much better – it has been reimplemented –, and the supporting process plug-in exposes a new PL/SQL process Delete Removed Images.
So, how easy it is now? In order to delete removed images from CLOB, a developer has to create one extra PL/SQL process! The code specified by a developer is executed in a loop over uploaded and removed images only – collection flag removed is set to Y.
Please, have a look at this example code:
begin if UC_FROALA_RTE.g_froala_image_safe_to_delete = 'Y' then delete from UC_FROALA_SAMPLE_BLOBS where id = UC_FROALA_RTE.g_froala_image_id; end if; end;
It is simple, isn’t it?
The variables UC_FROALA_RTE.g_froala_image_id and UC_FROALA_RTE.g_froala_image_safe_to_delete are plug-in variables updated for every loop iteration. The flag saying whether an image can be safely deleted is computed on the fly while the end-user creates the rich text. I need you to have a look at these three screenshots from the sample application.
The first screenshot was taken right after uploading an initial image. On the second, you can see that the initial image was copied and pasted within the editor (the image is having the same database ID and URL). The third screenshot shows the image statuses right after removing the initial image, but with the copy image remaining in the rich text.
An image status flag changes every time an image is added, removed, or restored (using undo/redo command). As long as an image URL is used within CLOB content, the image shouldn’t be deleted from the database because it is still referenced by copied image. All you have to do is just check whether the flag safe to remove is set to Y. Isn’t it simple?
If you were implementing removing images based on the plug-in collection, please note that the plug-in collection columns for images statuses have changed – you can read about it in the plug-in documentation.
Displaying rich text in an application
In prior releases, in order to display CLOB content – with styling applied by the end-user –, the only option was using an APEX item read-only state. PL/SQL API for version 22.1 was extended with a new procedure and function displaying and fetching CLOB content without the need to create the plug-in instance on the page!
create or replace package UC_FROALA_RTE as ... procedure clobDisplay( p_clob in clob ); function clobGetHTML( p_clob in clob, p_include_css in boolean default false ) return clob; ... end UC_FROALA_RTE;
The sample application page Examples \ How to display CLOB content? has been updated and now shows how native region PL/SQL Dynamic Content along with a new plug-in procedure UC_FROALA_RTE.clobDisplay can be used to display rich text!
Additionally, on the page, you can test (and inspect) displaying CLOB content in native Oracle APEX inline dialog using the new function UC_FROALA_RTE.clobGetHTML
You can learn more about the new PL/SQL API on the sample application page The plug-in \ PL/SQL API.
Test it yourself
The plug-in sample application pages were updated – new pages are marked with list badge New -, but the biggest enhancement was applied to the sample application home page. Starting with version 22.1 you don’t have to navigate the sample application to find a proper place to test plug-in features. You can do it right after visiting the sample application home page. Just open the inline dialog Settings available after clicking the gear icon and test core functionalities right away!
If you want to learn more about Plug-ins Pro, please visit our web page.
I hope I have managed to put some light on the very technical changelog and I hope I have convinced you to give the plug-in a try. From my perspective, this release is very important. On the one side, you get a reliable rich text editor supporting CLOB volumes and handling images – features that are not yet available using the native component –, and on the other side, I’m really proud of how easy implementing the plug-in is, and how many new possibilities it creates.
Personally, I can’t wait to tell you more about the plug-in and its cool features. You can expect a series of articles about plug-in features, how-to examples, and more! Stay tuned!