2.5 years later, this is still very much something I would like to see!

Setting aside the emotive / language bits, I stand by my demotion because I think IBM can easily split out the info they need already, i.e. via tags applied to an idea. If an idea relates to xpages, tag it as such (as this one is), job done!

I see what you mean Peter, but heavy reliance on XPages for Notes client applications is probably not a great idea at the moment—see discussion over on Sean Cull's site:

{ Link }

If we're talking about being able to differentiate between “classic” and XPages development, then that’s what the tags are for, right?

The rest of the idea text seems to just be editorial to me…

I certainly see how this could be useful, but I don't think it's something for the core product. Some custom development would address this easily.

Once you introduce something like this, people will want to tweak it. John makes a very good point: I wouldn't want my HTML to be that verbose, and would prefer selectors. So the odd id / class would indeed be useful, but it's easy to go over the top.

Couple that with endless arguments over the naming conventions to use, and you'd end up with a pretty iffy implementation I think :-)

In voting this up, I consider this more from a local client machine standpoint than the server. As a user, I would expect local deletions to use the client OS deletion facility. This is consistent with many other workstation applications (especially on OS X), and I don't see why it does any harm.

Now, the server: I can see the arguments against such a process, especially as the "bin" concept is not universal.

However for the client machine, i think that this sort of functionality is a shoo-in (and you're more likely to be a Manager of a local database of course).

Point taken. Just thinking of practicalities. Shared columns go some of the way I guess (at least in terms of duplicated effort *across* views / folders). Sub-columns as an analogue to subforms sound intriguing ;-)

Not sure I understand your comment. Yes you can hide / show columns programmatically, and yes you may have developers / designers managing the situation. But that doesn't mitigate the issue, particularly.

Appreciate the reasoning behind this, but I think that (a) you'd end up with a maintenance nightmare and; (b) in prohibiting the refresh of a specific component of a design element (e.g. a view column), you may break the updated parent element if new code relies on that view column (to continue the example).

I agree that this is a hassle, and something to address it would be cool. I don't think that this is the solution though, sorry.

This strikes me as being spam

Another area in which having the JVM compile LS would help :)

LS has already been retired as far as I can tell

Hmm. Problem is, for everyone who thinks *their* standard should be enforced, there's someone who thinks a different type of mark-up should be supported. Whilst we could theoretically agree a "standard" in the Domino world, that's not going to help in the wider sphere.

With regards OpenNTF, I am aware of two types of wiki: the Xpages one and DominoWiki. What other ones are there? Do the Quickr ones use a form of wiki mark-up?

Ironically, this is what Domino search already does, both in Notes and the web. (Check out the "&highlight..." parameter)

Appreciate the sentiment, but it's clear that IBM / Lotus are not interested in what people think they should do.…

The beauty of IdeaJam lies in its (apparent) simplicity.

I don't see the need for things like this. If an idea author *really* needs to know why something was demoted, they already have options:

- In the idea submission text, encourage demoters to comment
- (This is the radical one) *communicate* with any demoters to find out their reason(s)

Damn straight something's not right. Specifically: Ian's approach to interaction within a community on a beta website

In practice, I find that people just delete these emails, and pay no heed to them.

This would be better configured by policy I would have thought.

I hear people talking about OpenNTF apps as being "half-baked" a lot, and it ticks me off frankly: if you want apps brought up to scratch, GET INVOLVED!

I don't just mean code either: OpenNTF needs people willing to test, people willing to write documentation, and so on and so forth.

Taking one of your points in the follow-up, re making the server free and the client paid-for, I'd rather pay for the SERVER than for Domino Designer.

As it currently stands, Domino Designer is an aged, sub-par IDE and not something that I would pay for!

I get the point about spreading the joy of Domino development, but I don't see how this move would achieve that.

Does the upcoming wiki support some kind of import process (XML or other)? That would probably make more sense than a full-on migration toolset, as developers just need to do a bit of XSLT.

I looked into this far too much when I was playing about with content-type in DominoWiki 1.1 a couple of years back (Jason, as discussed, you can see from the template what I do now).

@SetHttpHeader doesn't work for certain attributes—content-type being one of them—intentionally. Apparently it's some kind of security thang. Although given that we can set this value in form properties, I'm not sure that's really a valid reason.

Even if this could happen, the codebase would have to be documented.

Aye, there's the rub ;o)

I don't believe this is in ND8. Thread independence is one of those things that people have been clamouring for since the year dot. It means a fundamental re-write of a lot of code, but has to happen someday, surely??

Absolutely; cardinal rule of UI design!

Twas a real highlight of ILUG and has to be a shoe-in for LS09!

As you say, devs and admins need to be productive too, and I'm sure manager types would appreciate a session like this. I say go for it!

Do we still have newbie developers in the Domino world? I thought we were all oldies now ;o) Anyway, good idea.

In the fit of demotes that this idea is receiving, people seem to be overlooking the point I make at the end… do people really not think it would be handy to have a more explicit error message—i.e. tell us which field / variable is the dodgy one? I guess I just want things easy(ier) eh ;o)

Good spot! I have never seen that before. Should really check the Info Centres more often...

Totally agree; not hard to implement, and something that other email clients do (e.g. GMail, Mail.app).

Yeah, backwards-compatibility is a big one. Oh well, just a thought. The community has spoken ;o)

Yes it's certainly been in the product a long time... in which case more useful error reporting would be fab for us poor maintenance coders :)

I know null != 0. But that's irrelevant. Contrary to popular belief, null is not a construct in the Notes formula world. If you're going to treat field values a certain way, you must be consistent. Notes is not consistent when it comes to numeric (or date) fields, compared with text fields. It is not consistent to say that a NUMERIC field has a value of "".

I like this (although as Harkpabst mentions, I was expecting a different idea!) I would envisage this as being similar to the 'compiler compliance' settings you have in Eclipse on a per-project basis -- e.g. "this app is 6.5x-compliant"... "this app is 8.0.2-compliant"... and so on.

So what happens if the NDS task is never done? I've tried being patient and letting it runs its course, but considering it's essentially just logging a load of stuff about memory and task state, it seems to take an awful long time to finish. So much so, that often I can't be bothered to let it continue—5+ minutes is WAY too long IMHO.

On the plus side, in OS X Notes just... disappears. And doesn't seem to leave anything behind part from the usual ~.lck file :o)

@2.. what, and Windows *is*? Come on now.

A basic Finder connector would be a great start, and would integrate with load / save dialogs in OS X, so whilst the Office connector would be handy for many, I wouldn't regard is essential. We definitely need *something* though!!

@1: where's the overlap between IBM & OpenNTF when it comes to DominoWiki? If you mean the wiki they've deployed re Domino best practice, that's a separate database entirely, based on Dominoblog.

I haven't tested it with CTRL-BREAK, but in Lotusscript we have a Terminate event which should be used to handle code exits gracefully.

Agreed; in the mean time, why not carry a flask around for that extra hit when the coffee's gone? Ha!

Seek, and ye shall find...

{ Link }

This idea is surely a no-brainer... why would anyone demote??

I believe the Skype protocol is actually { Link } isn't it? Anyway, good idea!

Even better: what about a debugger that actually opens on ALL events? I've tried to debug stuff in the past that simply won't open up in the debugger, even with a STOP statement (e.g. routines invoked from a form querysave, Lotusscript code included dynamically).

AMEN! And Matt, which soft keyboard do you use on your Mac? I've installed on in XP in VMware to no avail...

Why don't you like updating the FT index programmatically? It shouldn't put much of a strain on the server.

As an aside, if users are regularly searching for cases in your application by status, why not offer them a view which shows data "by status", rather than relying on the FT index?

This is a wordier version of the notes.ini variable "GoFaster = 1" isn't it?

Why aren't you comfortable cleaning up after yourself in the notes.ini file? As Corey says, profile documents sound like the way forward for you.

I'm not sure about this. There are plenty of tools out there for devs / admins to examine all the profile docs in a database. Is any more work here really required?

How would this iterate though? Order of fields in main form? (urgh) , alphabetically? Order of creation?

Your "Mika vs Axel" comments made me laugh out loud Axel (in a good way) :)

Re "this is not professional", built-in search is more than adequate for an application like Idea Jam. I fail to see a valid use-case for being able to search on content the nanosecond it's been submitted.

Why should idea spaces be confined to technical ideas Axel?

Great idea. I find that wikis are a great place for documentation like this.

My understanding is that the properties box in Designer (in Eclipse) would probably be morphing into an Eclipse view, so it would make sense to do likewise in the client, definitely.

No-one deserves that :)

Oh yes, that would make DominoWiki a whole lot easier... :)

That would be useful, but I'd have to give some props to Ytria on this point. signEZ does this really nicely (e.g. you can keep control of your signing IDs).

Well, a lower price would be great of course, but considering what we get for the money, can't really complain. I doubt I'll make it in '08, but I agree with Matt's sentiment, and certainly hope to make it in '09 when the company cashflow is a little more established ;)