Friday, September 28, 2012

Dreamweaver cloaking file extensions

A client of mine has a very large web site built using Dreamweaver templates.  It's literally a few thousand pages of content with an additional hundreds, maybe thousands, of document and media files.  When we want to update the template, its a pretty big chore.

Since we have multiple authors working on the site, the first thing that we need to do before updating the template is to do a GET of the entire site to make sure all the local files are the most recent.  Doing a GET of a site this big can take an hour or two just for the text files.  We try to avoid getting any unnecessary files that will not be affected by the template by using Dreamweaver's cloaking feature.

Cloaking allows you to specify file extensions that you do not want to transfer when you do a Get or a Put of a folder, potentially with many subfolders. It seems cloaking might be easier if we could specify file extensions to include rather than exclude.  We only want files that could be affected by the template, basically .aspx and .html.  But there are dozens of file types that need to be excluded.

Recently I lost my cloaking settings in Dreamweaver and had to rebuild that list of extensions. (Here are Adobe's instructions for using cloaking).  I imagine its a common list for anyone with a site this size with lots of documents and media files.  So I thought I'd share my list of extensions that I exclude with cloaking.  Here it is, in no particular order.  You can enter them into the cloaking settings just like this, separated by spaces, no commas:

.png .fla .flv .wmv .avi .pdf .doc .ppt .jpg .gif .zip .ppsx .wma .csv .pptx .bmp .docx .docm .log .pptm .mp3 .exe .psd .mov .xls .wmf .tif .pub .db .mp4 .xslm .ai .arf .mpg .swf

And a basic overview of what they are:

Images: .png .jpg .gif .bmp .tif
Flash: .fla .flv .swf
Audio and Video: .wmv .avi .wma .mov  .wmf .mp3 .mp4 .mpg
Documents:.pdf .doc .ppt .ppsx .pptx .docx .docm .csv .pptm  .psd .xls  .xslm .ai
Other: .zip .log .exe .pub .db .arf 

Wednesday, September 26, 2012

Android Launcher Icons for PhoneGap not changing

I've had the hardest time changing launcher icons for my Android application built with PhoneGap.  I would change the icons in the res/drawable-hdpi, res/drawable-ldpi, and res/drawable-mdpi, folders in Eclipse, compile my app so that it launched on the phone, and the icon just would not change.  It had worked before, I had a custom icon in there, I just couldn't get it to change again.

So I would just leave the new icon there and give up on it for a while.  Then, seemingly for no reason, the icon would eventually update at some point, event though I hadn't touched it.  Couldn't figure it out for a long time.

Finally, it occurred to me that the icon must be cached somehow.  I tried clearing the application's cache on the phone, but that didn't work.  Then I tried cleaning my application in Eclipse, and that worked.  Just go to Project... / Clean and select your project (or Clean all projects), then next time you compile the app to install on phone, it should be there.

(By the way, for a while I thought maybe I got the size wrong so I was looking for a sizing table.  This is a good page with information on Android icons, but not related to PhoneGap)

Tuesday, September 25, 2012

Everest error "Unable to save given Data" code 8002A415 and "security check" error 800200A5

The "Unable to save given Data" code 8002A415 and "Unable to perform security check for the browser" code 800200A5 errors had our Everest site down for about a week.  We spent a couple days trying to figure it out ourselves and then eventually called Versata's Everest support.  Although Versata took almost two business days to get back to us, they were able to solve the problem in less than 1 business day once they started, so overall I was pretty pleased with their help.

Just a little more background.... our site that is built with the Everest API was able to perform any read-only API calls just fine -- like Session.Open, Create.List, Create.Retrieve, etc.  But if we tried a call that performs a write -- like Customer.Create -- then we would get the "Unable to save given Data" code 8002A415 error.  At first, I wasn't trapping this error, and then I was trying a Session.Close, and that would give me a  "Unable to perform security check for the browser" error.  Not to mention, it wouldn't close the connection, so we quickly would end up exceeding our maximum open connections.  It was a mess.

I was able to duplicate the "Unable to save given Data" error in the API's Object Browser. (though I couldn't recreate the security check error in the object browser)  I made a simple XML test case for Customer.Create and sent this screenshot to Versata.

First, I had a web conference with a Level One support person.  After trying things for about an hour, she was able to determine that the error was related to using an Everest application server that was not on the same machine as the database server.  That made sense because staff weren't having any problems using the Everest application, and it was on the same machine as the database.  Our web server and development server were on different machines.  From there, she moved it to Level Two support.

The Level Two support person suspected a COM configuration problem.  Via web conference, he looked all over the development machine at the COM settings.  We stopped and restarted the Everest COM components, restarted machine, nothing was working.  Then we started looking at the database server.  That made more sense to me since multiple other machines suddenly were having problems using the database server.

After about two hours, the Level Two support person found the COM settings that needed to be changed.  The screen shot is below.  Our IT person wasn't real happy with having to make those settings, he said it left the machine somewhat vulnerable.  And we still don't know why everything was working for over a year and suddenly we had to make those settings.  There were some network changes, and the database server IP address had changed, but we don't specify the IP address anywhere, so it didn't seem it should matter.  Regardless, here are the steps to change those settings on your Everest database server if you need to.  This is for Windows Server 2003 Enterprise:

1. Open "Component Services".  You can either type dcomcnfg from the command prompt, or go to Control Panel > Administrative Tools > Component Services.
2. On the left side tree view, find "My Computer" under Component Services > Computers
3. Right click on "My Computer" and choose Properties
4. Go to the MSDTC tab and click the "Security Configuration" button
5. In the Security Configuration dialog, check every check box and pick "No authentication required" for the radio buttons.

That's it.  If it doesn't work at first, try a reboot of the machine.  Good luck!