plainblack.com
Username Password
search
Bookmark and Share

    

WebGUI::AssetExportHtml - Path / File names

User DBell
Date 9/24/2006 5:58 am
Views 1367
Rating 7    Rate [
|
]
Previous · Next
User Message
DBell

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");
       # ...
        my $path;
        my $filename;
        if ($url =~ /\./) {
            $url =~ /^(.*)\/(.*)$/;
            $path = $1;
            $filename = $2;
            if ($filename eq "") {
                $filename = $path;
                $path = undef;
            }
        } else {
            $path = $url;
            $filename = $index;
        }

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
Child: My.Test.Asset/My.Test.Child <- Not created at all, no error .

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

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
> 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 [
|
]
 
 
    



© 2012 Plain Black Corporation | All Rights Reserved