Mailing List Archive

> Line 189 of comp/media/wysiwyg/xinha/modules/ColorPicker/ColorPicker.js
> Goes from
> 'this.table.style.display="";'
> To
> 'this.table.style.display="block";'

Unfortunately, this doesn't work for me. :(
Is it prehaps browser dependant? I am using Firefox.

Regards, Zdravko

Zdravko Balorda escribió:
>
>> Line 189 of comp/media/wysiwyg/xinha/modules/ColorPicker/ColorPicker.js
>> Goes from 'this.table.style.display="";'
>> To
>> 'this.table.style.display="block";'
>
> Unfortunately, this doesn't work for me. :(
> Is it prehaps browser dependant? I am using Firefox.
>
> Regards, Zdravko
>
>

Hi Zdravko,

I can't tell you about the color picker, because I'm not using it, but I
have had several problems with Xinha, for instance with the spell
checker for Spanish. It insisted on applying a conversion of certain
characters into entities that confused the spell checking engine (I
don't remember exactly what it was, because I dealt with it about a year
ago). I had to patch the source. The problem is due to the fact that
several "legacy" modules (inheritated from HTMLArea days) in Xinha are
not well maintained.
I'm considering the switch to another WYSIWYG-editor for Bricolage (I'm
thinking about TinyMCE).

Best,

Michael

> ago). I had to patch the source. The problem is due to the fact that
> several "legacy" modules (inheritated from HTMLArea days) in Xinha are
> not well maintained.
> I'm considering the switch to another WYSIWYG-editor for Bricolage (I'm
> thinking about TinyMCE).


Well, Kahil's patch does work indeed. Perhaps it's a Davids decision
now to say whether it's Xinha or Bricolage.

Otherwise TinyMCE would be a good solution, too. I've tried it and it
seems to work fine.
More important to me though, is which editor is the most customizible.
For instance I would like to let users select/insert images from a list of
bricolage "related images" only!

Regards, Zdravko.

Zdravko Balorda escribió:
>
>> ago). I had to patch the source. The problem is due to the fact that
>> several "legacy" modules (inheritated from HTMLArea days) in Xinha
>> are not well maintained.
>> I'm considering the switch to another WYSIWYG-editor for Bricolage
>> (I'm thinking about TinyMCE).
>
>
> Well, Kahil's patch does work indeed. Perhaps it's a Davids decision
> now to say whether it's Xinha or Bricolage.
>
> Otherwise TinyMCE would be a good solution, too. I've tried it and it
> seems to work fine.
> More important to me though, is which editor is the most customizible.
> For instance I would like to let users select/insert images from a
> list of
> bricolage "related images" only!
>
> Regards, Zdravko.
>
>
Hello Zdravko,

do you mean you will allow them to insert images from inside the
WYSIWYG-field?

Best,

Michael

> do you mean you will allow them to insert images from inside the
> WYSIWYG-field?

Well, Michael, yes. They can do it anyway. It's also possible to do
remote include! This is why I wish there were some interface between
bricolage and wysiwyg editor.

Regards, Zdravko

On Jan 4, 2010, at 3:31 AM, Zdravko Balorda wrote:

> Well, Michael, yes. They can do it anyway. It's also possible to do
> remote include! This is why I wish there were some interface between
> bricolage and wysiwyg editor.

It's a good idea. Want to add an API for this for editors to use?

Best,

David

Zdravko Balorda escribió:
>
>> do you mean you will allow them to insert images from inside the
>> WYSIWYG-field?
>
> Well, Michael, yes. They can do it anyway. It's also possible to do
> remote include! This is why I wish there were some interface between
> bricolage and wysiwyg editor.
>
> Regards, Zdravko
>
>
You can configure Xinha's interface so that the "Insert image" button
doesn't appear (you probably know). And you can filter remote includes
in your template (That you know, too). I think letting users include
images that are not Bricolage assets would be very un-Bricolaging.

Best,

Michael

>> remote include! This is why I wish there were some interface between
>> bricolage and wysiwyg editor.
>
> It's a good idea. Want to add an API for this for editors to use?

I may get involved in this a bit deeper. I am not sure if I have the
right approach, too.

Xinha seems quite difficult to understand. To me at least. :)

Otherwise, for editors it may be even better to have some very smart
story importer from Word, or something.... perhaps even excel! :)

Regards, Zdravko.

On Jan 5, 2010, at 2:55 AM, Zdravko Balorda wrote:

>> It's a good idea. Want to add an API for this for editors to use?
>
> I may get involved in this a bit deeper. I am not sure if I have the
> right approach, too.

No one does. But any approach is better than none.

> Xinha seems quite difficult to understand. To me at least. :)

Yeah, the JavaScript editors are a mess, especially the older ones.

> Otherwise, for editors it may be even better to have some very smart
> story importer from Word, or something.... perhaps even excel! :)

You are a very very evil man.

Best,

David

>
>> Otherwise, for editors it may be even better to have some very smart
>> story importer from Word, or something.... perhaps even excel! :)
>
> You are a very very evil man.

:))) maybe not. :) I have just tried OpenOffice html export and it
looks quite nice. Even figures get exported, so that import into
bricolage should be feasible.

As for Xinha there is some ExtendedFileManager that seems promissing
regarding having limited list of files to choose from. At least to those
in /data/preview directory (which may be still too many).

Regards, Zdravko.

On Jan 5, 2010, at 11:24 PM, Zdravko Balorda wrote:

> :))) maybe not. :) I have just tried OpenOffice html export and it
> looks quite nice. Even figures get exported, so that import into
> bricolage should be feasible.

Yes, but OO itself is crap. Just like MSO.

> As for Xinha there is some ExtendedFileManager that seems promissing
> regarding having limited list of files to choose from. At least to those
> in /data/preview directory (which may be still too many).

Cool.

Best,

David

Hi,

I've given some thought to the issue of bricolage-xinha interface.
Here is my proposal for simple interface regarding images and related stories.

The starting point here would be parsing HTML field inside
comp/widgets/wysiwyg/xinha.html and rewriting tags so that:

1. for all related media of type image not already referenced in the wysyiwyg
field, add an <img> tag with appropriate URI. This will efectively insert
the image at the begining of the field so that a user can then drag/drop
or cut/paste it to a proper place.
URI should be prepended wirh "/data/preview" so that images are visibile
inside Xinha wywsiwyg field. This is then cleaned by story template.

2. fix any src attributes if some URI has changed. To do this one could use
alt attribute to save UUID of the related media (which xinha doesn't use).

3. check for any other img tags which are probably wrong.

For other type of media, say .pdf, audio, video, it could be regarded
similarly, but I haven't got that far.

For related stories I have already defined the following protocol:
1. for a related story use a pseudo URI: "story", that one types in Xinha
pop up window Insert Link.
2. In the story template replace every <a> tag with "story" URL with URI of
the related story, consecutively, so that first link points to the first
related story, second to the second, and so on.

However, this is too done in the templates, but it would be better to make this
cleanup internal to bricolage, thus freeing a designer from these details.

Any comments are very welcome.
And some pointers, too. Is xinha.html a good place for this code? How to
get access to $story from within xinha.html, and perhaps a few others.

Regards, Zdravko.

On Jan 28, 2010, at 5:33 AM, Zdravko Balorda wrote:

> The starting point here would be parsing HTML field inside
> comp/widgets/wysiwyg/xinha.html and rewriting tags so that:
>
> 1. for all related media of type image not already referenced in the wysyiwyg
> field, add an <img> tag with appropriate URI. This will efectively insert
> the image at the begining of the field so that a user can then drag/drop
> or cut/paste it to a proper place.
> URI should be prepended wirh "/data/preview" so that images are visibile
> inside Xinha wywsiwyg field. This is then cleaned by story template.
>
> 2. fix any src attributes if some URI has changed. To do this one could use
> alt attribute to save UUID of the related media (which xinha doesn't use).
>
> 3. check for any other img tags which are probably wrong.
>
> For other type of media, say .pdf, audio, video, it could be regarded
> similarly, but I haven't got that far.

Use an the thumbnail icon if you like.

> For related stories I have already defined the following protocol:
> 1. for a related story use a pseudo URI: "story", that one types in Xinha
> pop up window Insert Link.
> 2. In the story template replace every <a> tag with "story" URL with URI of
> the related story, consecutively, so that first link points to the first
> related story, second to the second, and so on.
>
> However, this is too done in the templates, but it would be better to make this
> cleanup internal to bricolage, thus freeing a designer from these details.

Sure, sounds okay. Just use a real XML parser, of course. Bricolage already uses XML::Simple, though it sucks.

> Any comments are very welcome.
> And some pointers, too. Is xinha.html a good place for this code? How to
> get access to $story from within xinha.html, and perhaps a few others.

xinha.html probably is not the best place for this code. Well, no, that depends. If you're doing something with HTML submitted from WYSIWYG fields, then do it in Bric::App::Callback::ContainerProf::_update_subelements(). But if you're parsing HTML to change how it's displayed in the browser, then xinha.html might be the best place to do it -- although if it could be applied to any WYSIWYG field, not just xinha, then we'll have to find someplace else.

Best,

David

> xinha.html probably is not the best place for this code. Well, no, that depends. If you're doing something with HTML submitted from WYSIWYG fields, then do it in
Bric::App::Callback::ContainerProf::_update_subelements(). But if you're parsing HTML to change how it's displayed in the browser,
then xinha.html might be the best place to do it -- although if it could be applied to any WYSIWYG field, not just xinha, then we'll
have to find someplace else.
>

Well, this could be used for any wysiwyg that works with html.
The field would be preprocessed just before it is displayed.
So it's not really xinha dependant.

Zdravko

On Jan 29, 2010, at 3:12 AM, Zdravko Balorda wrote:

> Well, this could be used for any wysiwyg that works with html.
> The field would be preprocessed just before it is displayed.
> So it's not really xinha dependant.

Actually, much as I hate to say it, the proper place to do it is in comp/widgets/profile/displayFormElement.mc, which is probably the single worst piece of code in Bricolage. But if you search for "wysiwyg" in that file, you'll see:

wysiwyg => sub {
my ($key, $vals, $value, $js, $name, $width, $indent, $useTable,
$label, $readOnly) = @_;

And within that code ref, you'll see this line:

$value = defined $value ? escape_html($value) : '';

It's there you'll want to do your parsing of the contents of $value.

Best,

David

> comp/widgets/profile/displayFormElement.mc, which is probably the single worst piece of code in Bricolage. But if you search for "wysiwyg" in that file, you'll see:
>
> wysiwyg => sub {
> my ($key, $vals, $value, $js, $name, $width, $indent, $useTable,
> $label, $readOnly) = @_;
>
> And within that code ref, you'll see this line:
>
> $value = defined $value ? escape_html($value) : '';
>
> It's there you'll want to do your parsing of the contents of $value.

If browser is the user interface a code can't be anything but ugly.

This might be too low, actually, since access to subelements "related_media" and
"related story" is needed. In this sense this seems no better then xinha.html.
Do you see any general approach about this? Probably not, because you would have
it programmed in brocolage already. :)

The question remains: how to grab the current $story variable?

Regards, Zdravko

On Feb 2, 2010, at 12:34 AM, Zdravko Balorda wrote:

> This might be too low, actually, since access to subelements "related_media" and
> "related story" is needed. In this sense this seems no better then xinha.html.
> Do you see any general approach about this? Probably not, because you would have
> it programmed in brocolage already. :)
>
> The question remains: how to grab the current $story variable?

From there, it's just

my $doc = get_state_data(story_prof => 'story');

You'd need to figure out if you were dealing with a story or a media document. Better might be to add a $doc param to <%args> and pass it in from edit_meta.html in comp/widgets/container_prof/field.mc, which is itself called from comp/widgets/container_prof/container.mc, which has a $story variable. Hrm. Dunno why it doesn't have $media, too. I'll have to look at that.

Best,

David

David E. Wheeler wrote:
> On Feb 2, 2010, at 12:34 AM, Zdravko Balorda wrote:
>>
>> The question remains: how to grab the current $story variable?
>
> From there, it's just
>
> my $doc = get_state_data(story_prof => 'story');
>
> You'd need to figure out if you were dealing with a story or a media document. Better might be to add a $doc param to <%args> and pass it in from edit_meta.html in comp/widgets/container_prof/field.mc, which is itself called from comp/widgets/container_prof/container.mc, which has a $story variable. Hrm. Dunno why it doesn't have $media, too. I'll have to look at that.
>
Hi!
Let me get back to this thread. I've reportted that I work on integrating CKeditor in Bricolage.
It works just fine! There are only two lines needed in /widgets/profile/displayFormElement.mc, namely
$code = lc WYSIWYG_EDITOR eq 'ckeditor'
? "var editor = CKEDITOR.replace( '$key', {
customConfig : '/media/wysiwyg/ckeditor_config.js' });"
: $code;

I took the liberty to add external user config file for the editor, but it would work without it.

But this is not all. There are another two lines that were changed in insert image plugin.
Now, the input text field that accepts image URL is replaced with a select list filled in from
external java array. Following the David's tip above, this array is assembled in ckeditor.html
and it contains "title", "uri" pair for every related media image document associated to a story.
Users now pick an image from this list instead of by typing in URL. I believe
users will gladly accept this. This is just to prove a concept of integrating wywsiwyg into
Bricolage. I intend to follow this for insert flash, and maybe even adding a new dialog tab
for links to related stories.

Until the day users will edit their stories on the very preview page... regards, :)
Zdravko

Sounds awesome. Will you be submitting a patch for 2.2?

Best,

David

PS: Flash is dead.

On Nov 28, 2010, at 10:42 PM, Zdravko Balorda wrote:

> David E. Wheeler wrote:
>> On Feb 2, 2010, at 12:34 AM, Zdravko Balorda wrote:
>>>
>>> The question remains: how to grab the current $story variable?
>> From there, it's just
>> my $doc = get_state_data(story_prof => 'story');
>> You'd need to figure out if you were dealing with a story or a media document. Better might be to add a $doc param to <%args> and pass it in from edit_meta.html in comp/widgets/container_prof/field.mc, which is itself called from comp/widgets/container_prof/container.mc, which has a $story variable. Hrm. Dunno why it doesn't have $media, too. I'll have to look at that.
> Hi!
> Let me get back to this thread. I've reportted that I work on integrating CKeditor in Bricolage.
> It works just fine! There are only two lines needed in /widgets/profile/displayFormElement.mc, namely
> $code = lc WYSIWYG_EDITOR eq 'ckeditor'
> ? "var editor = CKEDITOR.replace( '$key', {
> customConfig : '/media/wysiwyg/ckeditor_config.js' });"
> : $code;
>
> I took the liberty to add external user config file for the editor, but it would work without it.
>
> But this is not all. There are another two lines that were changed in insert image plugin.
> Now, the input text field that accepts image URL is replaced with a select list filled in from
> external java array. Following the David's tip above, this array is assembled in ckeditor.html
> and it contains "title", "uri" pair for every related media image document associated to a story.
> Users now pick an image from this list instead of by typing in URL. I believe
> users will gladly accept this. This is just to prove a concept of integrating wywsiwyg into
> Bricolage. I intend to follow this for insert flash, and maybe even adding a new dialog tab
> for links to related stories.
>
> Until the day users will edit their stories on the very preview page... regards, :)
> Zdravko
>
>

Hi!

Yes, gladly. I just need to resolve some technicalities:

URIs are rewritten by burner depending on output channel definition.
For wysiwyg preview purposes URI prepended by /data/preview works fine,
but for publishing the image src attribute may change. Actually
I rely on that there is only one output channel so cutting of
/data/preview by template is ok. But I'm afraid this is not a general
solution.

Any suggestions?
Similarly for anchor tags, burner rewrite related story uri, so that
href attribute may need to be rewritten by templates, too.

Zdravko

David E. Wheeler wrote:
> Sounds awesome. Will you be submitting a patch for 2.2?
>
> Best,
>
> David
>
> PS: Flash is dead.

On Dec 1, 2010, at 2:57 AM, Zdravko Balorda wrote:

> Hi!
>
> Yes, gladly. I just need to resolve some technicalities:
>
> URIs are rewritten by burner depending on output channel definition.
> For wysiwyg preview purposes URI prepended by /data/preview works fine,
> but for publishing the image src attribute may change. Actually
> I rely on that there is only one output channel so cutting of
> /data/preview by template is ok. But I'm afraid this is not a general
> solution.
>
> Any suggestions?
> Similarly for anchor tags, burner rewrite related story uri, so that
> href attribute may need to be rewritten by templates, too.

Maybe use the related document uuid in the html generated by xinha and then transform it in your templates?

Best,

David

David E. Wheeler wrote:
> On Dec 1, 2010, at 2:57 AM, Zdravko Balorda wrote:
>
>> Hi!
>>
>> Yes, gladly. I just need to resolve some technicalities:
>>
>> URIs are rewritten by burner depending on output channel definition.
>> For wysiwyg preview purposes URI prepended by /data/preview works fine,
>> but for publishing the image src attribute may change. Actually
>> I rely on that there is only one output channel so cutting of
>> /data/preview by template is ok. But I'm afraid this is not a general
>> solution.
>>
>> Any suggestions?
>> Similarly for anchor tags, burner rewrite related story uri, so that
>> href attribute may need to be rewritten by templates, too.
>
> Maybe use the related document uuid in the html generated by xinha and then transform it in your templates?
>

Yes, I would suggest that, too. uuid could be harmlessly stored in the alt imag attribute, while
in anchor tags it can be put in the very href attribute. It doesn't matter if links don't work from
wysiwyg text area.
Then, the template processing is either left to a user, or we could introduce some special
utility template (or even $burner->wywsiwyg_cleanup($text) subrutine?) to fix things.

my $cleaned_text = $m->comp(
'/util/wysiwyg_cleanup.mc',
text => $my_story_contents, #user defined field
);

Regards, Zdravko

Ages ago, we story-boarded out one possible way to handle adding
embedded images and links via a WYSIWYG. I believe we proposed
generating markup in the WYSIWYG that used a custom "uuid" protocol,
like:

<img src="uuid://d5d5ceb0-fe1d-11df-8cff-0800200c9a66" alt="media
object's description field, or something" />

<a href="uuid://d5d5ceb1-fe1d-11df-8cff-0800200c9a66">My link</a>

Your element template would then be responsible for resolving UUID's
to their appropriate values.

Using standard markup would make it easy to write/modify plugins for
the various WYSIWYG's. The consistent protocol would also make it
easier to override default click behaviors when viewing things in said
WYSIWYG, so the browser never actually has to deal with a protocol it
doesn't understand.

Our concept may be more involved than what's currently being
discussed; it required creating a RESTful back-end to handle dynamic
asset relation management. The overall picture looked like this:

* Make utility template for finding/expanding 'uuid://' to the
appropriate URI, given current burner context, OC, etc.
* Implement a RESTful web service that:
* Returns object list of specified type related to current asset
(JSON with uuid, title, uri, etc.).
* Accepts a category, and lists all child categories that
the current user can read (default to root).
* Accepts a category, returns list of all assets of specified
type that the current user can read.
* Accepts a list of UUID's whose relations should be removed.
* Accepts a list of UUID's whose relations should be added.
* Modify WYSIWYG image/link plugins to leverage the web service.
* Add js to the bric interface that handles stuff with 'uuid://',
so the WYSIWYG behaves reasonably.

Even skipping the web service part and outputting static markup when
the story profile loads (which is my understanding of Zdravko's
current solution) might benefit from the 'uuid://' approach.

-Aaron

---------------------------------
Aaron Fuleki
Senior Web Architect
Denison University
740.587.5752
---------------------------------



On Dec 2, 2010, at 2:00 AM, Zdravko Balorda wrote:

> David E. Wheeler wrote:
>> On Dec 1, 2010, at 2:57 AM, Zdravko Balorda wrote:
>>> Hi!
>>>
>>> Yes, gladly. I just need to resolve some technicalities:
>>>
>>> URIs are rewritten by burner depending on output channel definition.
>>> For wysiwyg preview purposes URI prepended by /data/preview works
>>> fine,
>>> but for publishing the image src attribute may change. Actually
>>> I rely on that there is only one output channel so cutting of
>>> /data/preview by template is ok. But I'm afraid this is not a
>>> general
>>> solution.
>>>
>>> Any suggestions?
>>> Similarly for anchor tags, burner rewrite related story uri, so that
>>> href attribute may need to be rewritten by templates, too.
>> Maybe use the related document uuid in the html generated by xinha
>> and then transform it in your templates?
>
> Yes, I would suggest that, too. uuid could be harmlessly stored in
> the alt imag attribute, while
> in anchor tags it can be put in the very href attribute. It doesn't
> matter if links don't work from
> wysiwyg text area.
> Then, the template processing is either left to a user, or we could
> introduce some special
> utility template (or even $burner->wywsiwyg_cleanup($text)
> subrutine?) to fix things.
>
> my $cleaned_text = $m->comp(
> '/util/wysiwyg_cleanup.mc',
> text => $my_story_contents, #user defined field
> );
>
> Regards, Zdravko
>

On Dec 2, 2010, at 6:39 AM, Aaron Fuleki wrote:

> Even skipping the web service part and outputting static markup when the story profile loads (which is my understanding of Zdravko's current solution) might benefit from the 'uuid://' approach

+1, especially if we added a Burner method that would fix such links for you. In fact, it'd be nice if there was something that would allow the wysiwyg editor to display them; maybe use a URI like http://$bricolge_host/preview/media/$uuid, which would be a call to the back end that would return the document. Should be pretty simple, really.

Best,

David