@Tommy - Matt's example of a namespaced ID is a perfect illustration of WHY the ID must be namespaced: if you have an edit box with a "designer" ID of "myField", but it's inside a repeat control, you could end up with 10, 20, maybe 100 fields in the rendered HTML, all with an ID of "myField"... unless the ID is translated into something guaranteed to be unique.

So I like your idea of having a client-side function that we can just pass the source ID and have it resolve the client ID... except for two caveats:

1. As Matt mentioned, we already have that in the form of the #{id:myField} syntax.
2. A "true" client-side function (i.e. one that is not translated by Domino at render time) would be forced to return a NodeList (just like dojo.query), because any ID passed to it would potentially match numerous elements (not just in the example of a repeat control, but also in cases where the same ID is used in multiple custom controls included in the same XPage (or once in a control and once on the XPage itself). In other words, you'd still end up having to do something like this:

XSP.byId("myField").forEach(function(thisNode){
if(someEvaluation(thisNode)) { // is this actually the one we want?
executeSomeProcess(thisNode);
}
});

In the case of a repeat, you might have to loop through dozens or even hundreds of nodes that all have the same source ID but have different client IDs, and try somehow to determine which of them is actually the one you're targeting.

I'm guessing that what you're really looking for is a way to target an element that WILL be unique (i.e. it's not inside a repeat, and you've named your elements uniquely across the entire render hierarchy). My recommendation would be to assign your elements a unique class as well - in addition to any other CSS classes applied to the element, list the ID as another class to apply. Then you could do something like this:

XSP.byId = function(id) {
var returnNode;
dojo.query("." + id).forEach(function(thisNode){returnNode = thisNode;});
return returnNode;
}

The result is that it will return the last element it finds using the passed ID as a class... as long as the class was used uniquely, this will return the precise element you're looking for.

If you feel comfortable modifying the mail template, you can add an action button / menu item / agent that creates an NDL file for each selected document in a folder of the user's choosing.

Some advantages of this approach:
- Assuming Notes is installed correctly, launching the NDL files will open the original document within Notes, so the behavior is essentially equivalent to Outlook.
- Instead of duplicating storage by maintaining the same data in the mail file on the server (and probably in a local replica) and in an exported copy, each NDL file is only about 1 KB, because it's just a link to the content, not the actual content.
- If the original content changes (i.e. the user edits the message and saves their changes), the NDL is still a link to the current content, not an outdated copy of the old content.

Disadvantage:
- In order for the user to know which NDL links to which message, the filename must be fairly descriptive (i.e. sender and subject). In some cases, if the subject is descriptive enough, even that much information can be enough to qualify as a violation of a non-disclosure agreement if revealed to the wrong individuals. Storing information from a mail file outside of the built-in security controls placed upon that mail file increases the risk of inappropriate disclosure. If the nature of your data and user skillset / policy awareness mitigates that risk, you may never get burned... but just keep in mind that there's a reason documents with Reader fields don't even show up if you don't have access to them: sometimes even the details of a document that display in a view can be enough to provide you information that you don't currently have clearance to know.

This is already planned for 8.5, at least for certain categories of design elements. Maureen demonstrated the feature during a session at Lotusphere.

Nathan and I don't agree on everything, but extended syntax is definitely one of my pet peeves.

- Option Declare lets you catch more bugs at compile time instead of run time, but, as Nathan pointed out, extended syntax reduces that ability.
- The reason I like having Option Declare automatically included is that it enforces variable declaration from the outset, so that whoever inherits my code doesn't have to clean it up later (well, okay, not as much). While the compatibility issue may not impact design elements until the next modification, it can be a huge productivity drain if, following an upgrade, numerous design elements can no longer be modified without first fixing what wouldn't be broken if extended syntax hadn't been used. Given a choice between something that might break (though, admittedly, the *vast* majority of item names we reference will never become a class member) and something that is pretty much guaranteed not to break, why would I possibly choose the former?

The *only* advantage I can see to extended syntax is that it saves a half second per item while coding. I do agree that this is mostly a matter of personal preference, and should probably be a lower priority than some of the other items we're waiting on, but we get new INI variables all the time for fringe use cases, so perhaps an INI setting that any given developer could enable that doesn't store the setting within design elements, but flags at compile time any use of extended syntax.......

I suppose everyone already knows I'm a DXL fanatic, but it's exhilarating to see how many others realize the potential here. It truly is a "sky's the limit" item... if it works fully and reliably, there isn't much we won't be able to do in the way of integration between Domino and other platforms, dynamic generation and analysis of data and design elements... the potential is enormous.

To be honest, I use it constantly and have rarely encountered any problems with it (offhand, the only example I can think of is view selection corruption, and the first time I ever saw that actually happen was about three weeks ago, and that bug is already fixed in 7.0.3 and 8). However, a lot of people shy away from it because so many people talk about how buggy and incomplete it is. I do want them to finish all the pieces we can currently only get as encoded binary, but mostly I want them to fix the round-tripping so that we can all embrace this with confidence.

If you add the same icons you use in the voting details section, the text could be next to (or partially overlap) the icon.

This probably belongs in its own idea, but I'd like to see GMail-style keyboard shortcuts; i.e., P promotes, D demotes, I creates a new idea... unless you're already focused in a field like this one.

The clickable tags are fine by me, but when I click to auto-complete, it doesn't return the cursor to the end of the value. I was entering multiple tags for an idea, so I started typing the first, clicked the tag that I'd partially typed, then pressed the space bar, expecting it to add a space after the tag. Instead, the browser jumped to the end of the page because the link was still focused.

Looks good in Google Reader...

I'd rather see it moved to the sidebar; expand when you need it, collapse when you don't, resize when you need to see more info.