Listen up! This is really, really bad!!
Update: 19th Dec 2005 - It looks like this might have been a mistake. I've since tested this with Domino 7 and found there to be no problem.
No, really, this is bad with a capital baaaa.
On Tuesday this week Bob Obringer asked the question "Did Domino 7 break your custom attachment deletion functionality???". Yesterday he answered it by declaring that Custom Attachment Deletion IS broken in R7
Why so? Well, remember the %%Detach trick? A guy called Sylvain at Lotus in France told me about it more than four years ago. Since then it's allowed us all to create better looking attachment management features in our applications. Until now that is. If Bob's right (and I assume he is) it no longer works in Domino 7.
This is a massive deal for me as just about every application I've developed in the last four years has included this technique. What do I do? Tell all my customers they will have problems if they upgrade to Domino 7?
What's the alternative? Back to doing it the "Lotus Way"? Ugly damned check boxes at the bottom of our pages. Damn it, is this progress!?
Now, of course, this has always been an undocumented hack that Lotus had no obligation to continue supporting in order to maintain backwards compatibility. So is it my / our / Sylvain's fault for promoting its use? I don't think so. Sure, we use undocumented features at our own risk, but what kind of Domino applications would we create without the hacks? We have no choice but to use whatever string of hope is thrown us by the likes of Sylvain.
What now then? Well, personally, I hope either Bob is wrong or that this is a temporary glitch to be fixed in 7.0.x. If not we need a solution.
Hands up if you've used this technique in your applications.
Update: 19th Dec 2005 - It looks like this might have been a mistake. I've since tested this with Domino 7 and found there to be no problem.
Skip to the 
You can subscribe to an individual
I would imagine that as soon as Lotus/IBM become aware of this they may re-introduce this hack considering it's wide spread use. They are usually quite accommodating in this respect unless of course there is greater underlying security or future-proofing reasons for removing it. So let's hope it's a temporary glitch.
I have not checked yet, but has anyone posted this on LDD?
I'm with you Jake. I use it in all my Web apps for the same reasons - the standard stuff simply stinks from a presentation standpoint.
I wonder how this made it through all their testing? Hmmmm.
I hope IBM unfixes what they've fixed fast.
Let's hope so Scott.
Jeff. I don't know if anybody has, but somebody should. Are you offering? ;o)
I'm using it on a couple of intranet sites. If it's broken in R7, I'll delay our upgrade on our application servers until I have a work around rather than re-engineer the apps.
Jake - I'm currently testing all our apps for use with R7, which we're planning to upgrade to in Jan '06 (7.0.1 is due in Jan). Thanks for posting this, I haven't actually got around to testing any of our web apps that have attachment handling, but I know I've done a few and they benefit from the technique you demonstrated...
I used it everywhere at my last place of employment. They like to keep up on versions just for the hell of it as well!
Better tip them off that this may no longer work if they upgrade.
For the record, I've never used this technique. What I have done is probably what people are now going to have to do to retrofit their applications.
If I'm dealing with any web-based attachment manipulation whatsoever, I simply create a new document for each attachment that is uploaded. This required a fair bit of WQS hackery, but once you put in the framework of storing each attachment in its own doc, the rest (Deletion, update, display, etc.) gets pretty easy. In fact, if you're feeling lazy about it, you can just use an embedded view to handle most of the display issues.
If people want more specifics, give a shout out.
guys,
can't you add an id to your FUC, hide it and copy its value and its *name* with javascript to a neutral checkbox ? that's a method i use right now and it works like a charm (as if it relies on javascript, which can lead to accessibility problems , i know)
It's not the upload control that's the problem. I've used the %%Detach (and discovered it independently with multiple trips to View->Source), but (fortunately) not in quite this way -- my implementation still works. However, it does rely heavily on JavaScript, so it won't be up Jake's alley.
(The separate doc thing isn't going to fly if the application is for both the web and Notes, since you can't transparently place an attachment "on" the parent document in the Notes client. The extra clicks to open the attachment document before opening the attachment are too much for end-users.)
Jake
If it's broken and you *have* to re-engineer it is really trivial.
1. Field FileNames : @Subset( @AttachmentNames ; 1 )
(list the attachment filenames in a field)
2. <computed text> :
URLs := "<a href=\"0/" + UNID + "/$FILE/" + Filenames + "\" target=\"Right\">" + Filenames + "</a>" ;
(build a list of links to the attachments so you can eyeball them)
@Implode( @If( @IsDocBeingEdited ; "<input name=\"Selected\" type=\"checkbox\" value=\"" + Filenames + "\">" ; "" ) + URLs ; "<br>" )
(build a list of checkboxes with filenames as the values)
3. WSQ Agent, code fragment :
If ContextDoc.HasEmbedded And Contextdoc.Selected(0) <> "" Then
Forall file In ContextDoc.Selected
Set embed = ContextDoc.GetAttachment( file )
Call embed.Remove
...
You retain complete control visually and in code
[quote from Stan Rogers]
(The separate doc thing isn't going to fly if the application is for both the web and Notes, since you can't transparently place an attachment "on" the parent document in the Notes client. The extra clicks to open the attachment document before opening the attachment are too much for end-users.)
[/quote]
@Stan:
It's not too hard to integrate seperate documents as attachments in the Notes client, but it's not as drop-simple as creating a RTL field set to attachments only. The embedded view idea helps a lot here, combined with a form which is set to launch its first attachment when opened. But, you do have to make Notes work a little more like the web by implementing an action button to add the attachment, that gets the file with NotesUIWorkspace.Prompt(13,...), and uses some script to create the new document and do the attachment storage.
Not my point at all, Brian. On the web, you can use computed text (or a CFD field) to put the links to the attachments directly onto the parent. As far as the user is concerned, there are no separate documents to deal with. It's completely transparent. In Notes, you need to open a separate document to get to the attachment. NOT GOOD, no matter what tools you give to the user -- embedded views, buttons, what have you. In order to get the context menu for an attachment, you need to see the actual attachment.
I have used the %%Detach "trick" for as long as I can remember... I can't remember one app not using it actually...
I had another "funny" situation with R7 earlier. R7 generates a hidden textfield named "%%surrogate_<fieldname>" with value="1" directly above all your regular checkboxes, radiobuttons and option-lists...
I guess this new field is ok as long as you submit forms back to domono the regular way, but I have applications that submit to other systems and js-objects that collects valuepairs from fields in different container elements (divs).
I believe the field was introduced to fix bugs similar to this one: {Link}
The new %%surrogate field is perhaps not a problem in most situations and you can avoid potential problems easily, but the way I found out about it (broken applications) was a bit scary...
@Stan:
Ahh. I see. I've never really considered the context menu for attachments to be much use. In my experience, users only ever want four things out of attachments: Add, Delete, Launch, and Save. If you can provide all these things, no one complains. An embedded view/auto-launch form covers three out of four. Detachment without launching can be done via an action button. Or, if you want to be fancy, you can jury-rig the InViewEdit event to do the detachment.
One solution I did used the "Embedded Editor" in conjunction with the embedded view. Working with it was unpleasant, though - I wouldn't recommend it, even though it does work (mostly) :)
Yeah, guys. I know thew feeling. Notes 6 broke at least one LotusScript method for Rich Text that I relied upon for my NotesTracker product. (IBM made lots of changes to Rich Text support in Notes 6, so I guess that's why the methid got broken.)
I noticed it while testing NotesTracker against several of the R6 betas, so developed a workaround.
If this attachement web deletion "trick" functionality is apparently popular with so many developers, and the various ND7 betas were out there for so long before GA (general availability a.k.a. "gold code"), then my only question is why this wasn't noticed much earlier and turns out to be such a sudden surprise to you all.
Even before clicking the submit button, I can feel all your slings and arrows heading down south towards Melbourne!
Let's hope that IBM does something to accomodate you all, anyhow. (And they are welcome to contact me to find out how Notes 6 broke the LotusScript Rich Text method, but I'll bet they don't.)
Cheers to all for the "silly season".
Well. Tony, the ND7 beta didn't have anything like the participation that the ND6 beta had. ND7 promised a few minor enhancements and DB2 (the big selling point). ND6 had a completely rewritten formula engine that was about four times the speed of the old one and looped to boot, a huge stack of enhancements and additions to LotusScript, a two-generation jump in Java and the tantalising possibilities of Garnet (a great toy, but ultimately a dead-end). There were days in the ND6 (RNext) beta forum that had nearly as much traffic as the entire ND7 beta forum saw (okay, a lot of that was heated arguing over features and behaviours, but that's what one wants to see in an exciting beta). Beta testing of the DB2 back-end option was light enough that IBM didn't have enough real-world data to support a DB2 option release (most of the bugs/issues were located and reported by IBM staffers during the beta). The beta participants seemed to me to be either testing DB2 Access and Query Views or doing compatibility testing on mundane apps. Not Jake's crowd at all....
@Ron - That's the way I've done it for years too - can't understand why the %%Detach trick is necessary. Jake?
Tyron. It's not that it's necessary. It's just that it's a lot easier/simpler/quicker.
@Tyron
It's easier, and in Jakes (and others) case, deployed. Having a fix is one thing. Having to go back to who knows how many customers, tell them that you used an undocumented feature that is no longer supported, and then sort out who is going to pay for the man hours to fix the problem... that's a much bigger issue, and I don't envy anyone in that position.
I've a small suggestion after first reiterating the praise often heard here. Jake, you are a paragon of not only giving to the Domino community, but also of how to really do top quality articles. The wonderfully lucid, often entertaining way you make your points, the examples for each of the points, the test forms and databases, and icing on the cake - downloadable example databases.
You also attract many talented and giving commenters. So much so that I often want to read through all article comments, which leads me to a suggestion.
In the same way that your pages provide elegant article nagivation, I wonder if you might do the same thing for comments, with a Previous/Next at the bottom of each comment text? This would save having to scroll through an often lengthy list of comments, seeking to find the inconspicuous thought balloon marking the current comment.
--David
Hm. My suggestion is going to look bizarre in the context of blog comments, where they all come full text one after another.
My comment applies to article comments, where one must navigate to each one.
Hi David. Thanks for what you said. I love praise ;o) Normally I delete comments that are off topic, but yours is far too nice to remove.
You're not the first to ask for another way of navigating the article comments. I'll add it to my todo list.
Jake, I use the same trick on R7 without a problem.
Ferdy. I've since used it on R7 (beta 4) as well and found no problem. I mailed Bob to ask which version he was using. I'm installing 7.0 final as we speak, to see if this isn't just a mistake. Will report back if it is.
It may well be an enhancement designed to manage multiple attachments with the same filename (ignoring the ATTXXXX name, and concentrating on the .Source) -- with the offset checked only in the case of the value being ambiguous. Sometimes those Lotus guys (and gals) are pretty smart.
Phew! I've just tested one of my apps that use this functionality - and it works fine on R7.0 gold. Panic over! :)