Welcome to the FogBugz Knowledge Exchange

Question

6

When writing Bugmonkey scripts it's hard to parse the html to find just the right element you want to modify.

Let's say that you have a custom field which is meant to store id numbers of customers in your CRM tool. In order to convert these to links with bugmonkey you need to parse the html to find the correct element in order to replace those ids with urls. The result seems to be hit and miss depending on how the page was rendered.

If, however, the custom field had an id attribute which could be used as an anchor (for example to be able to find directly on the page with getElementByID) it would make writing these scripts a lot easier.

Although in this case I'm talking about custom fields, I'm sure there are other places where this could be useful.

Case FC2038241

edited Mar 29 2011 at 19:59

Bradford♦♦
1,765●1●10

asked Sep 14 2009 at 19:38

Roman
1,211●3●16

Michael Pryor · Answer 1 · 2009-09-15 05:03:12Z UTC

1

It's a good suggestion, but it's also an interface that we have to adhere to. i.e. it's essentially an API. I'm not saying we shouldn't do this, just pointing out that it's not as simple as throwing a bunch of ids all over the place, as it needs to be documented and supported into the future as soon as we do it...

answered Sep 15 2009 at 5:03

Michael Pryor♦♦
3,192●2●10

	sure, but i got the basic structure of a bug in fogbugz is quite mature. and in case of any updates it should be backwards combatible anyway. in comparison to screenscraping any break would be much simpler to fix. – sbn Mar 2 2010 at 9:23
	It's a great idea, having a published API would basically be a BugMonkey API. While it may be work for FogBugz to make sure the API still works with changes, it far less work than it would be for everyone who ever created a BugMonkey script to update it every time there's a new FogBugz version change that could make random changes that affect scripts. – Samuel Neff Apr 15 2011 at 13:46
	They wouldn't have to be a guaranteed API. Sure, that would be ideal, but even if you document that the tags are subject to change, having even a half-done set of ids would still be very useful. Even if they change every release, the scripts would be easier to write and fix than they currently are. IOW, even if you can't promise stability, and even if it's a best-effort sideline project, we'd still love to have more ids for scripting. – Todd May 4 at 15:56

Feature Request: Anchors for bugmonkey customization

1 Answer