|
Replies
:
4
-
Pages
:
1
-
Last Post
:
Jan 17, 2007 4:09 AM
by: scott nichol
|
|
|
Posts:
304
Registered:
Aug 26, 2004
|
|
|
|
Web Gallery Pages Contain Garbage if Referencing External Scripts
Posted:
Jan 15, 2007 11:19 AM
|
|
|
Like many, I've been customizing the very limited web gallery templates that ship with Aperture, but in addition the many annoyances mentioned elswhere (generation of non-compliant HTML, deletion of certain content, reformatting, altering the DOCTYPE, etc.) I've encountered a serious problem that makes rich customization a chore.
Adding a script tag that references the Google Maps API causes Aperture to generate garbage in certain web gallery pages containing the tag.
Placing
<script type="text/javascript" src="http://maps.google.com/maps?file=api&v=2&key=ANYKEY"></script>
into the HEAD element (with any api key, including an invalid one) causes the element to be replaced with
<SCRIPT type="text/javascript" src="http://maps.google.com/maps?file=api&v=2&key=ANYKEY"></SCRIPT><SCRIPT src="http://maps.google.com/mapfiles/maps2.70a.api.js" type="text/javascript"></SCRIPT><STYLE type="text/css" media="screen">.gmnoscreen{display:none}</STYLE><STYLE type="text/css" media="print">.gmnoprint{display:none}</STYLE>
in most pages, and causes all of the second detail page (that's right, only the second page!) to be replaced with
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><STYLE type="text/css" media="screen">.gmnoscreen{display:none}</STYLE><STYLE type="text/css" media="print">.gmnoprint{display:none}</STYLE><STYLE type="text/css" media="screen">.gmnoscreen{display:none}</STYLE><STYLE type="text/css" media="print">.gmnoprint{display:none}</STYLE><STYLE type="text/css" media="screen">.gmnoscreen{display:none}</STYLE><STYLE type="text/css" media="print">.gmnoprint{display:none}</STYLE></HEAD></HTML>
which results in a blank page.
The styles gmnoscreen and gmnoprint come from Google, so apparently, the code that generates the web pages from the template actually reads the Google Map API file, triggering side effects that write into (and spoil) the page being generated.
Sadly, I've found no clever workaround for this bug. Aperture strips out SSIs (along with all HTML comments) so conditioning inclusion of the script tag on being on the server won't work, and substituting a page (that's only) on the server that redirects to the Google URL fails (probably because of some limitation of the Google API). The only workaround I've found is to generate pages with a place holder for the bug-triggering script (actually just the src attribute will do) that is then replaced in the files generated on the server (which is easy enough to do with BBEdit).
Note that inclusion of the offending script also causes some misbehavior in Aperture itself when previewing the pages.
Has anyone had a similar experience?
Any suggestions on a better way to prevent the script tag from being read by Aperture when it generates the pages?
This would seem to be a frank bug in the Aperture web gallery page generation code, which should simply be copying all script tags to the server files unchanged -- certainly without traversing the src url and thus executing any code they contain.
MacBook Pro 15.4" ● 2.33GHz ● 3 GB ● 160 GB |
Mac OS X (10.4.8)
|
|
Posts:
304
Registered:
Aug 26, 2004
|
|
|
|
Re: Web Gallery Pages Contain Garbage if Referencing External Scripts
Posted:
Jan 16, 2007 10:59 AM
in response to: scott nichol
|
|
|
It's hard to imagine what the designers intended then. No interactive web pages? Almost any code included in or referenced by the templates can result in serious and hard to detect bugs.
For example if I have an element containing
... id="someid" class="styleA"... and have
document.getElementById('someid').className='styleB'; somewhere in code that executes on load, then the Aperture-generated files will change the element to read
... id="someid" class="styleB"...
This is clearly a bug that needs to be fixed. The underlying model of what Aperture is doing certainly is not meant to include execution of code in page templates as part of he page generation process. Such code is only intended to run when the page is built in the client's browser.
I also don't buy the notion that this isn't really such a big problem since one can always use the features of a code editor like BBEdit to repair the problem in generated pages on the server. Such problems (as the above example illustrates) can be very hard to detect in the first place, and, more importantly that can't possibly be the model of "workflow" that Apple intends, since it means that every time I make photo related changes in Aperture (e.g. simply rearranging the photos in my gallery, or changing a caption) I have to run a development tool to fix the damage that such an update will do to the code in the generated web pages. They're hardly "templates" if their products need to be fixed every time they're used.
MacBook Pro 15.4" ● 2.33GHz ● 3 GB ● 160 GB |
Mac OS X (10.4.8)
|
|
Posts:
304
Registered:
Aug 26, 2004
|
|
|
|
Re: Web Gallery Pages Contain Garbage if Referencing External Scripts
Posted:
Jan 16, 2007 11:14 AM
in response to: scott nichol
|
|
|
Also note that I'm hardly trying to get the application to do something that it was "never meant to handle". I'm just pointing out that it should stop doing something that it shouldn't be doing in the first place: it should not be executing my scripts when it generates pages.
MacBook Pro 15.4" ● 2.33GHz ● 3 GB ● 160 GB |
Mac OS X (10.4.8)
|
|
Posts:
268
Registered:
Feb 4, 2005
|
|
|
|
Re: Web Gallery Pages Contain Garbage if Referencing External Scripts
Posted:
Jan 17, 2007 4:08 AM
in response to: Roy Levien
|
|
|
It's hard to imagine what the designers intended
then. No interactive web pages? Almost any code
included in or referenced by the templates can result
in serious and hard to detect bugs.
what i mean here is that Apple and the Aperture team have never supported any kind of external or third-party created web page templates. if they did there would be a guide for developers trying to do exactly what you're doing that would clearly define how to set up styles, naming conventions, etc. the team has not, to my knowledge, published any such guide. so what may seem logical to you is clearly not what the application is doing. if you really think this is a bug, none of us here can help you. you should post it to the Aperture feedback page.
good luck,
scott
PowerMac G5 2.5GHz Mac OS X (10.4.8) MacBook Pro 2.0GHz
|
|
|
