Mailing List Archive

Hi,

I've just pushed an update to Bricolage github regarding Bricolage
wywsiwyg inteface. Bellow is a short report on what things are about.

Be critical, please. :)

Regards, Zdravko

This is a report on changes made on Bricolage to provide
its wysiwyg interface, written for repository maintainers.

This interface provides for passing Bricolage internals to
Java applets, namely ckeditor.

While editing a story in story profile the wysiwyg editor
is now aware of all releated documents attached to the story.
It's done via Java array variables, namely:

var related_images;
All related media documents of MIME type image/*

var related_nonImages;
All related media of MIME type NOT image/* and all related
story documents

var related_objects;
All related media documents of MIME type: video/*, audio/*
and application/x-shockwave-flash.

A call to:
<& '/widgets/wysiwyg/bricolage-wysiwyg.mc' &>;
returns a hash containing Java source strings that are assigned to
Java variables from two files:
comp/widgets/wysiwyg/load.mc
and
comp/widgets/wysiwyg/container.html

The first declares the hash keys as arrays:

<script type="text/javascript">
% my %java_vars = $m->comp('/widgets/wysiwyg/bricolage-wysiwyg.mc');
% foreach my $key_name (keys %java_vars)
% {
var <% $key_name %> = <% $java_vars{$key_name} %>;
% }
</script>

while the file container.html merely redefines their values at
page reload. Since container.html also reinitializes ckeditor the
editor is aware if an element is deleted or a story is saved from
story profile.

Perhaps I pushed the issue of generality a bit too far here.
/widgets/wysiwyg/bricolage-wysiwyg.mc is supposed to be a single
entry point between Bricolage and external Java applets like ckeditor.
Please, feel free to repack things or let me know.




conf/bricolage.conf

Bricolage configuration have two new parameters:
# A comma or space separated list of key names of related documents element
# types e.g. related_media, related_exponat
# RELATED_MEDIA_TYPE_NAMES = related_media
# RELATED_STORY_TYPE_NAMES = related_story, linked_news

Deafult values are related_media and related_story. This is a bit of
hack, because get_elements() wants one or more strings as arguments
that cannot be directly passed as constants.


CKeditor

CKeditor is good as it comes. Addittional fields to Image, Link and
Flash plugins are defined externaly via ckeditor API. This, other, end
of the interface is contained in ckeditor.html. Porting this code to
other editors would provide the same functionality. Nothing else needs
to be changed.

Users now have an option to select a media from a list instead of
linking html tags to hard URLs. When selected other fields got populated,
typically alt and title attribute of the appropriate tags.

I have stripped quite a lot of tools from the editor. I don't feel
that much should be left to users in CMS. No font sizes! One can and
should use <small> or <big> but, that's it! God forbid changing fonts.

I have left out also SpellChecker and Scyt which may be usefull if
working.



preview/media/dhandler

The editors goes after their URIs to provide for wysiwyg media preview.
Here, the URI would be of the form:
/preview/media/$uuid

There is new /preview/media/dhandler that returns the media file according
to the $uuid embedded in the calling URI.


Template

The URIs in html tags <img>, <a>, and <object> are saved in a story
as:
/preview/media/$uuid
This needs to be processed by story template. Here is a simple suggestion:

% sub bricolage_wysiwyg {
% my @media = $element->get_elements('related_media');
% my @stories = $element->get_elements('linked_news');
% my (%uuids);
% foreach my $rm (@media) {
% my $md; $md = $rm->get_related_media();
% $uuids{$md->get_uuid} = $burner->best_uri($md) if $md;
% }
% foreach my $rs (@stories) {
% my $st; $st = $rs->get_related_story();
% $uuids{$st->get_uuid} = $burner->best_uri($st) if $st;
% }
% s|(/preview/media/[\w\d\-]+)|$uuids{substr($1,15)}|g;
% return $_;
% }

The subroutine call
$story_text = bricolage_wysiwyg($story_text);

rewrites all tags entering correct URI for every html tag. A nice
thing about it is that when a story is republished, html tags will be
rewritten accomodating for any possible change in document URIs.

BUGS
- any changes to story profile are visible to the editor by reloading
the story profile page. It is ok for deleting an element and
"Store and Stay", but, ckeditor is not aware of changes made by
editing a subelement. This needs to be done via AJAX in lib/js/lib.js
and is too deep for my knowledge of Java. Help needed.