One of the problems with writing software is that you can test it until you are blue in the face, but you simply can't foresee everything. One of the mixed joys in a software developer's life, therefore, is facing the worst case scenario, where it feels with a particular customer like you haven't foreseen anything. This has been happening to me on two fronts recently, one with CoexEdit and one with our Midas Rich Text C++ API.
You might wonder why I would refer to this as a "mixed joy". It certainly isn't fun, even if there is the occasional thrill as you manage to overcome each hurdle. It is a joy, however, to identify the problems and scenarios that your customers will actually face. A known evil is almost always better than an unknown one.
1) Generate HTML for all fields
The sample db using FCKEditor worked fine, but when the customer added the code to his database, it didn't work at all. It wasn't just CoexEdit which didn't work (it didn't even get to that point). The FCKEditor edit control didn't work at all. After a certain amount of banging my head against the wall, I discovered that the customer's form had the Generate HTML for all fields value
set, which completely screwed up the FCKEditor implementation we shipped to start with. That implementation uses innerHTML, and needs to not have a field called Body (or whatever) specified on the document. I tried to hide it in various ways, and I tried to talk the customer out of using the setting, but they need it. Sigh!Solution
This had a pleasant ending, since it forced me to learn about and figure out how to use the ReplaceTextarea
method in FCKEditor. The new sample we will ship will use that setting, which matches the functionality is several other editors, and which works with the Generate HTML for all fields
setting. It also does better with large quantities of data and is a bit easier to add. Score one joy.
This was a stinker. Again, I couldn't get a form to show the FCKEditor editing controls, but the HTML source looked practically identical to the form in the sample. I kept adding fields and settings to the sample to match the form that wouldn't work, and followed lots of red herrings before realizing that the new ReplaceTextarea
approach was using a
window.onload = function()
function and the form had a small OnLoad
Even after getting everything else working,the changes made from the web were not saving. I turned on the CoexEdit debugging, even went into the C++ debugger, and I could see the changes were happening, but they were not showing up. I checked every database setting, looked for scheduled or reactive agents, then finally found that there was a Web Query Save agent that was overwriting the changes in an earlier attempt to solve the problem CoexEdit was designed to solve.Solution
Once I found it, this was also easy to solve. I just removed the offending code, and added yet another note to our trouble shooting db. It is OK to have a WQS agent, and it can even modify the document, but it shouldn't modify the rich text field.
These may not sound that dire, but I have been working on solutions on and off for many days. Fortunately, this customer has been very patient, partly due to a strong desire to have CoexEdit working for them. Whatever the reason, I appreciate their patience, and am glad I now have some additional items to document and remember for future implementations. With any luck, I can find ways to make the samples even more bulletproof so that these considerations won't have to be taken into account.
Copyright © 2005 Genii Software Ltd.