[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bricolage-devel
Subject:    Re: In-place preview editing
From:       "David E. Wheeler" <david () kineticode ! com>
Date:       2009-02-26 20:35:26
Message-ID: 776E81FA-A23F-42D0-8C7A-05DBB6EFF5C0 () kineticode ! com
[Download RAW message or body]

On Feb 26, 2009, at 12:03 PM, Adrian Yee wrote:

>>    Bric::Util::ApacheReq->instance->hostname
>
> Yeah, that's what I'm using, but it gets a little ugly:
>
> if (not PREVIEW_LOCAL and $ar) {
>    $url .= (index($url, '?') == -1 ? '?' : '&') . 'bric_app_uri=';
>    my ($proto, $port);
>    if (SSL_ENABLE && ALWAYS_USE_SSL) {
>        $proto = 'https://';
>        $port = (SSL_PORT eq '*' or SSL_PORT == 443) ? '' : ':' .  
> SSL_PORT;
>    }
>    else {
>        $proto = 'http://';
>        $port = (LISTEN_PORT eq '*' or LISTEN_PORT == 80) ? '' :  
> ':' . LISTEN_PORT;
>    }
>    $url .= $proto . $ar->hostname . $port;
> }
>
> Even then, this doesn't quite work on our proxied modperl  
> installation, since Bricolage runs internally http, but is running  
> https on the outside (SSL_ENABLE = false).

This should be added as a method somewhere, clearly, as we use  
essentially the same code in a few places.

>> Hrm. Why wouldn't the iFrame just wait for the response from its  
>> submit to Bricolage?
>
> The iframe does wait for the response, but the iframe is now on the  
> bricolage app domain and it now can't communicate with the preview  
> frame directly.  After the iframe loads (now on the app domain), it  
> can grab the redirected preview uri and update the preview frame's  
> url to change the fragment identifier.  That's what the preview  
> frame is polling itself for.

Okay.

>> Can the preview page poll the iFrame?
>
> Nope.  After the iframe posts to the bricolage domain, the preview  
> page loses its permission to access the iframe.

What a PITA.

>> Be sure to add comments about all this to the code, as no one  
>> editing this stuff in the future will look for explanations on the  
>> mail list! :-)
>
> Yup, I'll try get that done when I get a chance.  Ideally, I'd like  
> to have a central location for this overview.  Not sure which file  
> would be the best place.

Bric::Util::Burner, I should think.

Best,

David


[prev in list] [next in list] [prev in thread] [next in thread]