Mailing List Archive

ckeditor report
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.
Re: ckeditor report [ In reply to ]
On Jan 17, 2011, at 12:17 AM, Zdravko Balorda wrote:

> 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. :)

Thanks for sending this, 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.

I'm confused. Isn't it a JavaScript editor? I just loaded the demo here:

http://ckeditor.com/demo

I don't see any java there…am I missing something?

> 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>

If it is JavaScript rather than Java, as it certainly appears, just stylistically I'd prefer better variable names. But you can also do this a bit more expressively:

<%perl>;
my %config = $m->comp('/widgets/wysiwyg/bricolage-wysiwyg.mc');
while (my ($k, $v) = each %config) {
$m->print("var $k = $v;\n");
}
</%perl>

> 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.

Okay.

> 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.

I don't understand why these are required. You can look at individual elements to tell if they're related via the `can_relate_story()` and `can_relate_media()` methods.

> 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.

Nice. We do already have FCKEditor support. How does this relate to CKeditor? Is FCK deprecated? Should we drop it in favor of CK?

> 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.

Sounds great.

> 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.

+100 # I'm philosophically with you, brotha.

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

What's required? What is Scyt?

> 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.

Nice.

> 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);

Erm, don't really follow what this is about…

> 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.

Oh, so the HTML stored from CKEditor will have something like /preview/media/$uuid in it? Is there no way around that?

> 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.

Sure, simply editing an element never affects previews or other elements until you save or save and stay. There is no Ajax submission if you just edit an element. But if you delete one or add a new one, all of them are reloaded, and changes should show up then. Is that the case?

Best,

David
Re: ckeditor report [ In reply to ]
Hi,

I'll get back to previous message, let me just sync with github:

latest history is:

I have committed "added support for ckeditor"
I have committed "bricolgae wysiwyg interface"
You have pulled first commit and made some changes
you have pushed it to master and closed my pull request

Now I need to rebase, but
git pull says: Already up-to-date.

I'm stuck. :)
What should I do?

Zdravko
Re: ckeditor report [ In reply to ]
and also:

git rebase master
says: Current branch master is up to date.
Zdravko
Re: ckeditor report [ In reply to ]
David E. Wheeler wrote:
>
> Thanks for sending this, Zdravko.

You are wellcome. I found Bricolage CMS as such a rarely well defined
concept that I am happy to participate even a small part.

>
> I'm confused. Isn't it a JavaScript editor? I just loaded the demo here:

Yes! It's JavaScript. Java term is used to make people blind. :)


>
> If it is JavaScript rather than Java, as it certainly appears, just stylistically I'd prefer better variable names. But you can also do this a bit more expressively:
>
> <%perl>;
> my %config = $m->comp('/widgets/wysiwyg/bricolage-wysiwyg.mc');
> while (my ($k, $v) = each %config) {
> $m->print("var $k = $v;\n");
> }
> </%perl>

Seems nicer. Thanks.
What do mean by better variable names? My English doesn't reach much further.

>> # 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.
>
> I don't understand why these are required. You can look at individual elements to tell if they're related via the `can_relate_story()` and `can_relate_media()` methods.

Excellent. These two configuration variables are dropped.


>
> Nice. We do already have FCKEditor support. How does this relate to CKeditor? Is FCK deprecated? Should we drop it in favor of CK?
>

To my knowledge CKeditor tends to take over. Actually it's a rewrite of FCKeditor.
See: http://drupal.org/node/820682


>
>> I have left out also SpellChecker and Scyt which may be usefull if
>> working.
>
> What's required? What is Scyt?

It's Scayt, really. Is stands for Spell Check As You Type.
Perhaps only one is enough for default configuration. I'd recommend Scayt as it
seems to be licence free and does not require any other installation. But I am
no expert!

>> 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.
>
> Oh, so the HTML stored from CKEditor will have something like /preview/media/$uuid in it? Is there no way around that?

No. That is I don't see it. But I really like the idea of correcting URIs.
There has been some discussion on changed URIs when reloading a media document
by some other file with different file name. Or a related story is moved to
another category...

Regards, Zdravko
Re: ckeditor report [ In reply to ]
On Jan 18, 2011, at 12:12 AM, Zdravko Balorda wrote:

> I have committed "added support for ckeditor"
> I have committed "bricolgae wysiwyg interface"
> You have pulled first commit and made some changes
> you have pushed it to master and closed my pull request
>
> Now I need to rebase, but
> git pull says: Already up-to-date.
>
> I'm stuck. :)
> What should I do?

Yeah, I replied to your pull request with some instructions. HTH,

David
Re: ckeditor report [ In reply to ]
On Jan 18, 2011, at 5:54 AM, Zdravko Balorda wrote:

> David E. Wheeler wrote:
>> Thanks for sending this, Zdravko.
>
> You are wellcome. I found Bricolage CMS as such a rarely well defined
> concept that I am happy to participate even a small part.

Awesome.

>> I'm confused. Isn't it a JavaScript editor? I just loaded the demo here:
>
> Yes! It's JavaScript. Java term is used to make people blind. :)

It worked. HATE. :-)

>> If it is JavaScript rather than Java, as it certainly appears, just stylistically I'd prefer better variable names. But you can also do this a bit more expressively:
>> <%perl>;
>> my %config = $m->comp('/widgets/wysiwyg/bricolage-wysiwyg.mc');
>> while (my ($k, $v) = each %config) {
>> $m->print("var $k = $v;\n");
>> }
>> </%perl>
>
> Seems nicer. Thanks.
> What do mean by better variable names? My English doesn't reach much further.

Instead of `$java`, since it's not Java, maybe `$js`.

>> I don't understand why these are required. You can look at individual elements to tell if they're related via the `can_relate_story()` and `can_relate_media()` methods.
>
> Excellent. These two configuration variables are dropped.

Sweet.

>> Nice. We do already have FCKEditor support. How does this relate to CKeditor? Is FCK deprecated? Should we drop it in favor of CK?
>
> To my knowledge CKeditor tends to take over. Actually it's a rewrite of FCKeditor.
> See: http://drupal.org/node/820682

Okay. We can consider dropping it later, before 2.1.0.

>>> I have left out also SpellChecker and Scyt which may be usefull if
>>> working.
>> What's required? What is Scyt?
>
> It's Scayt, really. Is stands for Spell Check As You Type.
> Perhaps only one is enough for default configuration. I'd recommend Scayt as it
> seems to be licence free and does not require any other installation. But I am
> no expert!

It's commercial. http://www.spellchecker.net/v3/products/scayt.html

>>> 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.
>> Oh, so the HTML stored from CKEditor will have something like /preview/media/$uuid in it? Is there no way around that?
>
> No. That is I don't see it. But I really like the idea of correcting URIs.
> There has been some discussion on changed URIs when reloading a media document
> by some other file with different file name. Or a related story is moved to
> another category...

Hrm. Maybe there's some way to do it in the callback code? That is, a filter to change to the format needed to display in CKEditor and a filter to change it back on submission. The former wold go…erm, not sure where. The latter would go into Bric::App::Callback::ContainerProf, I think.

Best,

David
Re: ckeditor report [ In reply to ]
>> What do mean by better variable names? My English doesn't reach much further.
>
> Instead of `$java`, since it's not Java, maybe `$js`.

Yea.

>>>> 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.
>>> Oh, so the HTML stored from CKEditor will have something like /preview/media/$uuid in it? Is there no way around that?
>> No. That is I don't see it. But I really like the idea of correcting URIs.
>> There has been some discussion on changed URIs when reloading a media document
>> by some other file with different file name. Or a related story is moved to
>> another category...
>
> Hrm. Maybe there's some way to do it in the callback code? That is, a filter to change to the format needed to display in CKEditor and a filter to change it back on submission. The former wold go…erm, not sure where. The latter would go into Bric::App::Callback::ContainerProf, I think.

Hrmmmm... I really like the idea of fixing URIs. Perhaps it could be filtered by
Burner itself?

Regards, Zdravko.
Re: ckeditor report [ In reply to ]
David E. Wheeler wrote:
> On Jan 18, 2011, at 5:54 AM, Zdravko Balorda wrote:
>
>> David E. Wheeler wrote:
>>> Thanks for sending this, Zdravko.
>> You are wellcome. I found Bricolage CMS as such a rarely well defined
>> concept that I am happy to participate even a small part.
>
> Awesome.

Indeed! And what have I managed to achieve with it! It has gone beyond
my own expectations. As was briefly discussed in some thread on the user mail list,
I tweaked the way of using Bricolage and Mason. The concept of patching up
a cover story I've extended to patching templates too. Just like a cover story
one can patch up the whole template, headers, footers, ... etc. The templates got
additional parameter $template, which holds a tree of subelements defining the
header, footer, ... contents. No programming is required for building a site and
all sites have the same underlying set of templates.
Well, it's not so well defined concept and I'm hoping it won't break. :)
Frankly, it still needs to be proved. But at the time there are 14 different
sites build and it still holds together. :)

So, yes, indeed!
Regards, Zdravko
Re: ckeditor report [ In reply to ]
On Jan 19, 2011, at 5:19 AM, Zdravko Balorda wrote:

> Indeed! And what have I managed to achieve with it! It has gone beyond
> my own expectations. As was briefly discussed in some thread on the user mail list,
> I tweaked the way of using Bricolage and Mason. The concept of patching up
> a cover story I've extended to patching templates too. Just like a cover story
> one can patch up the whole template, headers, footers, ... etc. The templates got
> additional parameter $template, which holds a tree of subelements defining the
> header, footer, ... contents. No programming is required for building a site and
> all sites have the same underlying set of templates.
> Well, it's not so well defined concept and I'm hoping it won't break. :)
> Frankly, it still needs to be proved. But at the time there are 14 different
> sites build and it still holds together. :)

Nice!

David
Re: ckeditor report [ In reply to ]
On Jan 19, 2011, at 1:13 AM, Zdravko Balorda wrote:

>> Hrm. Maybe there's some way to do it in the callback code? That is, a filter to change to the format needed to display in CKEditor and a filter to change it back on submission. The former wold go…erm, not sure where. The latter would go into Bric::App::Callback::ContainerProf, I think.
>
> Hrmmmm... I really like the idea of fixing URIs. Perhaps it could be filtered by
> Burner itself?

I'd rather it be done for the container stuff, so that it's just stored with the proper URIs in the database. Only downside is if a URI changes, of course. Erm, so maybe the burner *would* be better. You could just add a method that one could call from a <%filter> section, or that could get a single field's worth of stuff passed to it.

Best,

David
Re: ckeditor report [ In reply to ]
Hi,
I wanted to say how impressed I am by Bricolage but it
ended by me showing up my work and myself. Please forgive
me, I get easily overexcited when it comes to Bricolage.

Regards, Zdravko


David E. Wheeler wrote:
> On Jan 19, 2011, at 5:19 AM, Zdravko Balorda wrote:
>
>> Indeed! And what have I managed to achieve with it! It has gone beyond
>> my own expectations. As was briefly discussed in some thread on the user mail list,
>> I tweaked the way of using Bricolage and Mason. The concept of patching up
>> a cover story I've extended to patching templates too. Just like a cover story
>> one can patch up the whole template, headers, footers, ... etc. The templates got
>> additional parameter $template, which holds a tree of subelements defining the
>> header, footer, ... contents. No programming is required for building a site and
>> all sites have the same underlying set of templates.
>> Well, it's not so well defined concept and I'm hoping it won't break. :)
>> Frankly, it still needs to be proved. But at the time there are 14 different
>> sites build and it still holds together. :)
Re: ckeditor report [ In reply to ]
On Jan 23, 2011, at 9:58 PM, Zdravko Balorda wrote:

>
> Hi,
> I wanted to say how impressed I am by Bricolage but it
> ended by me showing up my work and myself. Please forgive
> me, I get easily overexcited when it comes to Bricolage.

I consider than an excellent sign. Thanks!

David
Re: ckeditor report [ In reply to ]
Hi,
to continue with ckeditor I stumbled across the following:
wysiwyg field inside a subelement won't save it's contents.
It acts quite strange actually. Previewing a story containing
wysiwyg subelment field shows my last name (Balorda). ?!

Any hint?

Zdravko
Re: ckeditor report [ In reply to ]
On Jan 26, 2011, at 1:09 AM, Zdravko Balorda wrote:

>
> to continue with ckeditor I stumbled across the following:
> wysiwyg field inside a subelement won't save it's contents.
> It acts quite strange actually. Previewing a story containing
> wysiwyg subelment field shows my last name (Balorda). ?!
>
> Any hint?

Don't really understand what you're asking. Is there a bug here? If so, can you describe how to reproduce it?

Thanks,

David
Re: ckeditor report [ In reply to ]
David E. Wheeler wrote:
> On Jan 26, 2011, at 1:09 AM, Zdravko Balorda wrote:
>
>> to continue with ckeditor I stumbled across the following:
>> wysiwyg field inside a subelement won't save it's contents.
>
> Don't really understand what you're asking. Is there a bug here? If so, can you describe how to reproduce it?

I have only discovered that when an element containing wysiwyg
field one need to "save and stay" before adding the field,
or the field contents won't be saved later.
It's probably how AJAX works.

Zdravko
Re: ckeditor report [ In reply to ]
On Jan 26, 2011, at 10:07 PM, Zdravko Balorda wrote:

> I have only discovered that when an element containing wysiwyg
> field one need to "save and stay" before adding the field,
> or the field contents won't be saved later.
> It's probably how AJAX works.

That doesn't sound right. You should never lose content unless you hit the "Cancel" button.

Best,

David
Re: ckeditor report [ In reply to ]
David E. Wheeler wrote:
> On Jan 26, 2011, at 10:07 PM, Zdravko Balorda wrote:
>
>> I have only discovered that when an element containing wysiwyg
>> field one need to "save and stay" before adding the field,
>> or the field contents won't be saved later.
>> It's probably how AJAX works.
>
> That doesn't sound right. You should never lose content unless you hit the "Cancel" button.

Yes, I know. Probably the data should be retreived via some JS instead of directly
from the form field, because there is no field yet. Before one saves and reloads the
story profile it's all on the client side only.

Zdravko
Re: ckeditor report [ In reply to ]
On Jan 27, 2011, at 10:47 PM, Zdravko Balorda wrote:

> David E. Wheeler wrote:
>> On Jan 26, 2011, at 10:07 PM, Zdravko Balorda wrote:
>>> I have only discovered that when an element containing wysiwyg
>>> field one need to "save and stay" before adding the field,
>>> or the field contents won't be saved later.
>>> It's probably how AJAX works.
>> That doesn't sound right. You should never lose content unless you hit the "Cancel" button.
>
> Yes, I know. Probably the data should be retreived via some JS instead of directly
> from the form field, because there is no field yet. Before one saves and reloads the
> story profile it's all on the client side only.

That's how the textarea type works, so it should be the same. AFAIK all the WYSIWYG fileds are just textareas under the hood, so it should be the same. If not, it's a bug.

Best,

David
Re: ckeditor report [ In reply to ]
David E. Wheeler wrote:

>>> That doesn't sound right. You should never lose content unless you hit the "Cancel" button.
>> Yes, I know. Probably the data should be retreived via some JS instead of directly
>> from the form field, because there is no field yet. Before one saves and reloads the
>> story profile it's all on the client side only.
>
> That's how the textarea type works, so it should be the same. AFAIK all the WYSIWYG fileds are just textareas under the hood, so it should be the same. If not, it's a bug.
>
> Best,
>
> David

Hi,
it seems resolved. I'm not sure I did it properly, but it seems to be working.
The thing here was ajax submit. Here is the code from ckeditor.html:
<script type="text/javascript">
var editors = new Array();
var ckCallback = function () {
$A(editors).each(function(editor) {
delete CKEDITOR.instances[editor];
CKEDITOR.replace( editor, {customConfig : '/widgets/wysiwyg/ckconfig.js'});
});
};

var sub = $('theForm').onsubmit;
$('theForm').onsubmit = function () {
if ( !arguments.callee.caller) return sub();
$A(editors).each(function(editor) {
if (document.getElementById( editor ))
CKEDITOR.instances[editor].updateElement(); });
return sub();
}
</script>

which I borrowed from fckeditor.html and quite blindly ported to CKEditor.

Otherwise, I released this wysiwyg media linking on our Broclage installation and I am
happy to say that users accepted this gladly. Well, since we also upgraded from 1.10.4 it's no
surprise, really. :)

Regards, Zdravko.
Re: ckeditor report [ In reply to ]
On Jan 30, 2011, at 11:50 PM, Zdravko Balorda wrote:

> which I borrowed from fckeditor.html and quite blindly ported to CKEditor.

Cool. So is this in your branch on GitHub now?

> Otherwise, I released this wysiwyg media linking on our Broclage installation and I am
> happy to say that users accepted this gladly. Well, since we also upgraded from 1.10.4 it's no
> surprise, really. :)

You're on 2.0 now? Congrats!

Best,

David
Re: ckeditor report [ In reply to ]
David E. Wheeler wrote:
> On Jan 30, 2011, at 11:50 PM, Zdravko Balorda wrote:
>
>> which I borrowed from fckeditor.html and quite blindly ported to CKEditor.
>
> Cool. So is this in your branch on GitHub now?

No, not yet. Users have also reported a few bugs, so it's good, actually. :)
Also, there are some points I'd like to discuss:

A small piece of code is needed to rewrite URIs and titles in html tags.
This code looks for all related type documents, and builds hashes:
%uris and %titles. The last two lines actually do the rewriting.
This code should go as a <%filter> section, probably in autohandler.mc.
Is there a way to stash this code somewhere internal to Bricolage, so that
template designers wouldn't have to worry about it? Or shell we leave it
to them?

Zdravko

% my (%uris,%titles, @docs);
% foreach my $e ($element->get_elements())#make lists of all related stories and all related media
% {
% my $doc;
% if ($e->is_container) {
% if ($e->can_relate_media) {
% $doc = $e->get_related_media();
% } elsif ($e->can_relate_story) {
% $doc = $e->get_related_story();
% }
% if ($doc) {
% $uris{$doc->get_uuid} = $burner->best_uri($doc);
% $titles{$doc->get_uuid} = $doc->get_title;
% }
% };
% }
% s|(/preview/media/[\w-]+)|$uris{substr($1,15)}|g;
% s|(/::title::/[\w-]+)|$titles{substr($1,9)}|g;
Re: ckeditor report [ In reply to ]
On Feb 3, 2011, at 12:33 AM, Zdravko Balorda wrote:

> No, not yet. Users have also reported a few bugs, so it's good, actually. :)
> Also, there are some points I'd like to discuss:
>
> A small piece of code is needed to rewrite URIs and titles in html tags.
> This code looks for all related type documents, and builds hashes:
> %uris and %titles. The last two lines actually do the rewriting.
> This code should go as a <%filter> section, probably in autohandler.mc.
> Is there a way to stash this code somewhere internal to Bricolage, so that
> template designers wouldn't have to worry about it? Or shell we leave it
> to them?

It could go into Bric::Util::Burner, though I hesitate to add something HTML-specific to it -- especially since it's a well-known that it's extremely difficult to properly parse HTML with regular expressions.

>
> Zdravko
>
> % my (%uris,%titles, @docs);
> % foreach my $e ($element->get_elements())#make lists of all related stories and all related media
> % {
> % my $doc;
> % if ($e->is_container) {
> % if ($e->can_relate_media) {
> % $doc = $e->get_related_media();
> % } elsif ($e->can_relate_story) {
> % $doc = $e->get_related_story();
> % }
> % if ($doc) {
> % $uris{$doc->get_uuid} = $burner->best_uri($doc);
> % $titles{$doc->get_uuid} = $doc->get_title;
> % }
> % };
> % }
> % s|(/preview/media/[\w-]+)|$uris{substr($1,15)}|g;
> % s|(/::title::/[\w-]+)|$titles{substr($1,9)}|g;


Shorter, for use in /autohandler:

my %data_for = map {
$_->get_uri => [ $burner->best_uri($_), $_->get_title ]
}
s|(/preview/media/[\w-]+)|$data_for{substr($1,15)}->[0]|g;
s|(/::title::/[\w-]+)|$data_for{substr($1,9)}->[1]|g;

Although the substr() looks wrong. UUIDs are 36 characters long with dashes.

Best,

David
Re: ckeditor report [ In reply to ]
David E. Wheeler wrote:
>
> Shorter, for use in /autohandler:
>
> my %data_for = map {
> $_->get_uri => [ $burner->best_uri($_), $_->get_title ]
> }
> s|(/preview/media/[\w-]+)|$data_for{substr($1,15)}->[0]|g;
> s|(/::title::/[\w-]+)|$data_for{substr($1,9)}->[1]|g;
>
> Although the substr() looks wrong. UUIDs are 36 characters long with dashes.

Indeed. This can be still cleaned up before 2.1. So, let's leave it to template
designers. There is no harm in it. Preview won't show images which is an early
warning. Until a better solution is found, users could be instructed what to do
via Changes.pod.

I'll prepare then a complete commit.
Regards, Zdravko.

ps. a good news from small print: Scyt spellchecker is free for CKEditor users.
Re: ckeditor report [ In reply to ]
>
> Although the substr() looks wrong. UUIDs are 36 characters long with dashes.


Hi,
I have pushed last changes to my fork. Below is the <%filter%> code. The regexps are
a bit tighter and it looks correct too. :) Shame, I really don't know how to incorporate
this piece of code into Bricolage distribution. Help needed.

my (%uuids,%titles);
foreach my $e ($element->get_elements())#make lists of all related stories and all related media
{
my $doc;
if ($e->is_container) {
if ($e->can_relate_media) {
$doc = $e->get_related_media();
} elsif ($e->can_relate_story) {
$doc = $e->get_related_story();
}
if ($doc) { #if related document exists, get uri and title
$uuids{$doc->get_uuid} = $burner->best_uri($doc);
$titles{$doc->get_uuid} = $doc->get_title;
}
};
}
#rewrite html tags properly
s|(/preview/media/([\w-]{36}))|$uuids{$2}|g;
s|(::title::([\w-]{36}))|$titles{$2}|g;


The wysiwyg patch has been brought to a level discussed in this thread. Few other bugs
have been resolved and it should be ok. The remaining bug is:
The editor dosn't know about any changes to related documents made by AJAX API, until
at least Save and Stay is pressed.

Regards, Zdravko

1 2 3  View All