Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs






July, 2005
SMTWTFS
     01 02
03 04 05 06 07 08 09
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

Search the weblog





























Genii Weblog


Civility in critiquing the ideas of others is no vice. Rudeness in defending your own ideas is no virtue.


Mon 18 Jul 2005, 04:47 PM
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.

In any case, the CoexEdit issues are to be expected, as there are only a few "real" customers, and we were bound to face some hurdles early on.  The problems in this case are not to do with the CoexEdit engine itself, which has been remarkably solid.  They all have to do with configuration and settings and JavaScript and that sort of thing.  Here are a few of the problems we have faced recently with this customer:

1) Generate HTML for all fields property

Problem
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.

2) OnLoadJavaScript event

Problem
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 JavaScript event.

Solution
Once I found it, this was easy to solve.  I just moved the OnLoad code down into the subform's window.onload code and everything worked fine.  Still, it means I need to be sure people understand that if there is an OnLoad JavaScript event, it needs to be combined with the FCKEditor usage.  Annoying, but better to know than to now know.

3) WQS agent

Problem
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.