fulekia at denison
Dec 2, 2010, 6:39 AM
Post #24 of 37
(1612 views)
Permalink
|
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
>
|
1
