MarmotBlog

First off, all of the Marmot pages except CVS Monitor should have John’s new Marmot favicon. Safari seems to lose the icon when you switch tabs, so it’s not as cool as it could be. And it looks like IE doesn’t like it either. Oh, well.

Also, CVS Monitor has been updated to the final release of 0.6.3 (was 0.6.3b3). They say 0.7 will have :ext support and possibly Subversion and arch support as well.

My new update to the documentation should finally work right in Safari, Mozilla, and IE. Those changes will get moved over sometime later today if they work.

CVSMonitor hadn’t been updating since John added templates/mu/marmot/ because that directory wasn’t owned by the cvsphp group in the repository. I have added a cron job at :59 to make sure group permissions are right so the :00 CVSMonitor updates should go without a hitch.

Finally, I have three RSS feeds for Bugzilla. I hope to someday replace them with one fancy script and maybe even better integration with Bugzilla’s query tools and saved queries. Until then, we have feeds for:
30 recently updated bugs
30 recently closed bugs
all open bugs

I think that’s all for now. All these little changes made for a big post.

Bug 105 started with two similar problems John and Tim had with <goofytext> making its way into their applications, in and out of a database, and back out to the presentation layer, either causing an XML parsing error or a very mangled output stream.

The root of the problem was Marmot’s questionably-intelligent encoding practices. In 1.0.x, Marmot’s add_element would try to encode < and > signs in content, unless it resembled a tag. This was to allow the developer to insert Marmot tags directly in a content string. The two big uses of this were <break /> and <link> tags inserted into paragraphs or other block-level elements. (Also any of the style tags like <bold>.) The problem with this is that it wasn’t any more intelligent than this, so bits of the string’s contents that were not valid tags but somewhat resembled tags, like <user@host.org> or <www.host.com> were not being encoded, causing these non-tags to end up in the XML stream at build time.

This problem was further compounded by 1.1’s new mu_insert_element() function, which would return a stringified representation of a tag. We decided on this as a way to allow developers to insert elements into another element’s content without typing the tags themselves. Today we realized that this only pushed the problem around and didn’t solve anything. The content of one element still contained a stringified representation of another element, which made our encoding decisions even more difficult.

At the same time mu_insert_element() was created, MU_Presentation::make_element() was added to return an unattached element object, exactly like mu_insert_element() returned a string. add_element() was already modified to accept either a string or one of these objects, so it was only logical that we further extend add_element() to accept a string, an object, or an array made of strings and objects. This finally solved our embedded-element issue that plagued us since the beginning. Now, developers do not write tags for Marmot elements by hand, nor do they even have access to string representations of those elements.

The remaining issue is handling cases where this is already being done the wrong way. We are moving forward to document the UBB features to allow developers and users the ability to represent test styles, links, and other basic formatting within strings, for user editing or storage in a database.

Changes for Bug 105 include:
Expanding add_element()’s functionality
Deprecating text2xml(), mu_insert_element(), and the use of tags in a content string

First off, the Blog, Bugzilla, and official Documentation are now all on naslnx05. naslnx07 will redirect for a while, but I’ll probably clean that junk off in the next week or two.

Secondly, we’re going to try to have a much bigger focus on Bugzilla. Previously, it was just a way for Dirk to have a checklist. Now, we are going to try to use Bugzilla as the single collection point for all change tracking. This also changes the way we deal with CVS.

• Any changes you make in CVS should be associated with a Bugzilla entry.
• CVS changelogs should still be used, but do not have to be overly lengthy. They should at least contain a Bug ID.
• CVS commits should all be associated with a small number of bugs (preferably 1) and a small number of files. This is to prevent “Tim Syndrome”, where a developer makes tons of unrelated changes over a 2-week period before remembering to commit. This will also make it much easier to track changes.