Mailing List Archive

David E. Wheeler wrote:
> 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.
>

Nice. This would cover for generality. Relative links would do, too: /preview/media/$uuid.

But what to do on template part?
Should it be left entirely to users?

Running some predefined template would be an exception in bricolage.
It may be better having some $burner->wysiwyg($html) that does the uri replacements or even
calls display_element($related_media)?

Zdravko

On Dec 2, 2010, at 11:57 PM, Zdravko Balorda wrote:

> Nice. This would cover for generality. Relative links would do, too: /preview/media/$uuid.
>
> But what to do on template part?
> Should it be left entirely to users?

Yes. Maybe there'd be a convenience method to transform them if the output is HTML.

> Running some predefined template would be an exception in bricolage.
> It may be better having some $burner->wysiwyg($html) that does the uri replacements or even
> calls display_element($related_media)?

Yeah, something like that.

David

David E. Wheeler wrote:
> On Dec 2, 2010, at 11:57 PM, Zdravko Balorda wrote:
>
>> Nice. This would cover for generality. Relative links would do, too: /preview/media/$uuid.
>>
>> But what to do on template part?
>> Should it be left entirely to users?
>
> Yes. Maybe there'd be a convenience method to transform them if the output is HTML.

Right! /preview/media/$uuid is the way to go. It will work for all tags while preserving
correct HTML.
I am not sure I know how to write this, though.

Zdravko

On Dec 5, 2010, at 10:07 PM, Zdravko Balorda wrote:

>> Yes. Maybe there'd be a convenience method to transform them if the output is HTML.
>
> Right! /preview/media/$uuid is the way to go. It will work for all tags while preserving
> correct HTML.
> I am not sure I know how to write this, though.

We'll help you. Send questions and pointers to your fork when you need to. Also, I'm often on #bricolage on irc.perl.org.

Best,

David

>> I am not sure I know how to write this, though.
>
> We'll help you. Send questions and pointers to your fork when you need to. Also, I'm often on #bricolage on irc.perl.org.
>
> Best,
>
> David

This would do. Help is welcome. It will be my first fork, too. So please, bare with me. :)
Under img tag go images. But under link a tag what shell we put:
everything, or just non-images + related stories? I'd say non-images+stories.
And then there is also flash (object) plugin. Any sugesstions which media to
handle by this plugin?

Zdravko

On Dec 7, 2010, at 6:31 AM, Zdravko Balorda wrote:

> This would do. Help is welcome. It will be my first fork, too. So please, bare with me. :)
> Under img tag go images. But under link a tag what shell we put:
> everything, or just non-images + related stories? I'd say non-images+stories.
> And then there is also flash (object) plugin. Any sugesstions which media to
> handle by this plugin?

You lost me. Flash? Wha?

David

Hi,
let me briefly get back to you regarding my new /preview/media/dhandler:
how to return media file contents?

% ($mfile) = Bric::Biz::Asset::Business::Media->list({ uuid => "$uuid" });
Now I need to dump the contents od $mfile.

% $fh = $mfile->get_file();
% while (read($fh, $buffer, 4096)) { print $buffer };

This is probably wrong.

Regards, Zdravko

On Jan 3, 2011, at 5:00 AM, Zdravko Balorda wrote:

>
> Hi,
> let me briefly get back to you regarding my new /preview/media/dhandler:
> how to return media file contents?
>
> % ($mfile) = Bric::Biz::Asset::Business::Media->list({ uuid => "$uuid" });
> Now I need to dump the contents od $mfile.
>
> % $fh = $mfile->get_file();
> % while (read($fh, $buffer, 4096)) { print $buffer };
>
> This is probably wrong.

Why? Looks fine to me. I might have done

print while <$fh>;

But if you have very long lines or binary data, your way is better.

Best,

David

> Why? Looks fine to me. I might have done
>
> print while <$fh>;
>
There was an empty line that corrupted image file during output. Shame on me. :)
It does work actually.

But there is something else: it seems that ckeditor.html (like xinha.html) does not
execute on story profile reload; that is, after adding some related media. Only after the
document is saved ckeditor.html is executed. A bit annoying, because my data for ckeditor
are prepared by ckeditor.html and should be refreshed to immediately show the new
related document. Any solution to this?

Regards,
Zdravko

On Jan 3, 2011, at 11:04 PM, Zdravko Balorda wrote:

>
>> Why? Looks fine to me. I might have done
>> print while <$fh>;
> There was an empty line that corrupted image file during output. Shame on me. :)
> It does work actually.
>
> But there is something else: it seems that ckeditor.html (like xinha.html) does not
> execute on story profile reload; that is, after adding some related media. Only after the
> document is saved ckeditor.html is executed. A bit annoying, because my data for ckeditor
> are prepared by ckeditor.html and should be refreshed to immediately show the new
> related document. Any solution to this?

Erm, no idea. That's stuff on the Xinha side, no?

David

>
> Erm, no idea. That's stuff on the Xinha side, no?
>
> David

I need an "online" list of related media. If the story is stored then it's ok
to build this list from ckeditor.html. But while working on story_profile currently
added element isn't seen via $story pointer. Also if an element is deleted the change
does not reflect in $story until it's saved.

Probably comp/widgets/container_prof/container.html
could be a better place to prepare the java vars needed by the editor? Or could we
use some other reference than the document reference: get_state_data(story_prof => 'story');
to obtain the current list of elements?
Zdravko

On Jan 4, 2011, at 10:09 PM, Zdravko Balorda wrote:

>> Erm, no idea. That's stuff on the Xinha side, no?
>> David
>
> I need an "online" list of related media. If the story is stored then it's ok
> to build this list from ckeditor.html. But while working on story_profile currently
> added element isn't seen via $story pointer. Also if an element is deleted the change
> does not reflect in $story until it's saved.

Both should be reflected, actually. You might have to check the active status or something for deleted elements. Make sure that you're using the $story object stored in the session, though. Don't fetch it from the database yourself.

> Probably comp/widgets/container_prof/container.html
> could be a better place to prepare the java vars needed by the editor? Or could we
> use some other reference than the document reference: get_state_data(story_prof => 'story');
> to obtain the current list of elements?

No, that's the one to use, that's what container.html uses. Look at how it determines what elements there are. And yeah, maybe that *is* the proper place to sent the variables, since it's iterating over the elements already anyway.

Best,

David