| Previous · Next | |
| User | Message |
|
DBell
|
Date: 9/24/2006 5:58 am · Subject: WebGUI::AssetExportHtml - Path / File names · Rating: 7
While investigating a bug in WebGUI/AssetExportHtml.pm, I came across this code that splits an asset's URL into a path and filename. my $url = $asset->get("url"); It seems to work alright except when an asset URL has a directory that contains a period, then $filename will contain a directory separator, causing a later call to mkpath() to not create the entire path, and causing FileHandle->new() to sometimes complain about trying to open a directory. Here's a patch that fixes one problem but not another: Assets that have a URL that's a descendant of an asset with a URL with a . in it don't get created at all Parent: My.Test.Asset <- created as a file I think the best way to solve this would be to have each exported asset be its own directory. Ugly for the file system, perhaps, but it would export a site that's functionally identical to the generated site (save for Apache possibly putting trailing / on everything). Attached Files |
| Back to Top |
Rate [ | ]
|
|
dwilson
|
Date: 9/25/2006 4:52 pm · Subject: Re: WebGUI::AssetExportHtml - Path / File names · Rating: 2
Giving each asset its own directory is kind of okay for HTML pages, but it gets more awkward to configure properly when you can have arbitrary MIME types. The fundamental difference is of course that a URL can have both content and children, whereas a filesystem entry can be a file or a directory but not both. Hmm. Another possibility may be to punt, after a fashion, by forcing anything that returns HTML to be a directory and anything that does not to be a file, then simply refusing to export anything that requires URLs underneath what is now a file. |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 9/26/2006 9:25 am · Subject: Re: WebGUI::AssetExportHtml - Path / File names · Rating: 5
> Another possibility may be to punt, after a fashion, by forcing anything that returns >HTML to be a directory and anything that does not to be a file, then simply refusing to >export anything that requires URLs underneath what is now a file. I think that Drake's suggestion here is a good one Doug. Take a look at making the code do this, and then report back with your findings. JT ~ Plain Black ph: 703-286-2525 ext. 810 fax: 312-264-5382 http://www.plainblack.com I reject your reality, and substitute my own. ~ Adam Savage |
| Back to Top |
Rate [ | ]
|