On 8/13/06, Jörn Nettingsmeier <[EMAIL PROTECTED]> wrote:
i "solved" it, but i'd love to hear comments about my solution. there
must be a better way...
Jörn Nettingsmeier wrote:
> Jörn Nettingsmeier wrote:
>> i'm working on the tinymce module. i want to get rid of any special
>> preprocessing in the usecase handler and just feed a completely
>> rendered page to tinymce (with the exception of script headers).
>>
>> basically, i want to
>> <map:generate
>>
src="http://localhost:8888/{page-envelope:publication-id}/authoring/{page-envelope:document-url}/>
>>
>> but i'd like to do that inside cocoon without all the http overhead.
>>
>> it's also important not to make assumtions about the publication
>> sitemap, i.e. duplicating the aggregation code is out.
>> so i have to call into the sitemap somehow.
>> the problem is that the publication might be using fallback. now when
>> i try <map generate
>> src="fallback://lenya/pubs/{page-envelope:publication-id}/sitemap.xml"/>
>> (i know it doesn't make sense, just for testing), i get a 404
>> exception, because the file does not exist (it's in the template
>> publication).
>> is that me doing something wrong, or does fallback resolution fail
>> from modules into publications?
>
> i should have mentioned that the first thing i tried was
>
cocoon://{page-envelope:publication-id}/{page-envelope:area}{page-envelope:document-url},
> but it complains about a missing sitemap.xml (again due to the
> publication using fallback).
i'm doing this:
tinymce.jx usecase handler:
[a header that loads the javascript for the editor]
<cinclude:includexml>
<cinclude:src>cocoon://modules/tinymce/content</cinclude:src>
</cinclude:includexml>
this is unchanged wyona code so far. but the wyona module hardcodes the
default css and does not display the menus and stuff, only the div#body
section. i'd like to accomplish the same level of "in-place wysiwyg"
that bxe has, but without all the pipeline kludgery around...
my tinymce module sitemap:
<!-- this pattern is called by usecases/tinymce.jx -->
<map:match pattern="content">
<map:generate
src="cocoon:/__content/authoring{page-envelope:document-url}"/>
<map:serialize type="xml"/>
</map:match>
<map:match pattern="__content/**">
<map:mount
src="{fallback:{page-envelope:publication-id}:sitemap.xmap}"
uri-prefix="__content"/>
</map:match>
if there was a cocoon god, i'd probably drop dead.
there must be a nicer way to do it. all i want is:
"ok, we have this request, like
http://localhost:8888/mypub/authoring/foo_de.html?lenya.usecase=edit.tinymce.
now call the jxtemplate handler to load the editor code and
configuration, and instead of a page:body, just include what you would
get if you requested http://localhost:8888/mypub/authoring/foo_de.html.";
any comments much appreciated.
[sharing joy without the slightest bit of condescension] Cool! I'm
impressed. Cocoon is very powerful; sometimes you just need an extra
pipeline to make it work. map:mount often requires one because the
url must be changed for the uri-prefix. And the lightning strike will
go through me first; 1.3's Modules use that algorithm everywhere.
Wait until you see how I am using Kupu to edit any one field without
saving the current state of the document to disk. I have the module:
protocol replacing fallback, and virtual documents to make it
"easier", but this is not how grandpa uses Cocoon.
(You did ask for "any comment". I just woke up and have to go to a
meeting where business people are designing an application without any
clue about best practices, so my sense of humor may be running
backwards. Did you appreciate the comments?)
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
