custom error pages for IBM Domino iNotes - lotus-domino

we're currently customizing iNotes for a customer (platform currently is Domino 9). We almost reached our goals, but one thing that's on our todo list I can't really figure out: they want us to also customize any possible error pages; see the following example screenshot:
This and other similar pages seem to come from the central Forms9.nsf which I'd love to leave as it is. We so far tried domcfg.nsf mappings, but as this is an iNotes internal error it obviously can't work; I also tried to figure out a way to put seomething into our customized Forms9_x.nsf but without any hint this is too abstract for me.
So my questions are:
has anyone ever done this?
what options do we have (apart from "hacking" Forms9.nsf)?
Many thanks in advance...
Update:
After continuing to play with domcfg mappings I suddenly saw a first result; not sure what's the difference to the first attempts, though; maybe moving the error form to Forms9_x.nsf did the trick? I'll keep investigating and post an answer if I can find one...

Alright, this has been an afternoon of wild guessing and hacking along, but finally I think I found it:
first of all, my playing around with domcfg mappings didn't have to do with solving the problem; instead, I just by chance had put my error page form into my Forms9_x.nsf and named it $$ReturnGeneralError (that's simply the name used in Forms9.nsf...; I completely had forgotton about those 4 pre-defined form names back from Domino 5 times).
What did not work was the old method of simply including a text file named MessageString to display the exact error message returned from the server; obviously iNotes is handling those error strings differently.
After a few hours of testing, and comparing codes between the standard iNotes error page and mine I finally found it: include some iNotes specific computed text into the page, in my case that is
#{{MessageString}; html}
See this document for some details (last row in the table)
Hopefully this can help someone else as well...

Related

Intellij IDEA SDK - How can I programmatically handle spellcheck 'typos'?

Wrote a plugin to handle some custom format stuff in yaml files that I've written for a huge project. It's a chat bot that can respond in a huge number of ways. There is a lot of slang and non-standard words in the yaml.
I don't want to disable spellchecking as I want to fix legitimate speeling errors. But the annotations under the "misspelled" slang words are conflicting with the annotations in my plugin, and causing issue.
One yaml file has 349 "typos". 10% or so are legit. The rest are slang and custom words.
I need to do one of two things. Either add those words to the dictionary (I've found the method to do that - SpellCheckManager.getInstance(project).acceptWordAsCorrect()) OR get a list of the words and create a custom dictionary from them. Both approaches require me to grab a list of all typos in the document/editor/project.
That's the part I can't find. Looked everywhere. (List of current Annotations? List of current Problems?) Googled my fingers off. Anyone able to point me in the right direction?
This is not the IDEAL solution, but it worked for my means, and I'm leaving the answer in case this is googled.
In DaemonCodeAnalyzerImpl, there is a method:
DaemonCodeAnalyzerImpl.getHighlights(Document document, HighlightSeverity minSeverity, Project project);
This returns a list of all highlights in the document. The method is Annotated with #TestOnly, and docs state that it should only be used in Test code because it breaks/shortcuts the normal way to access that. It still works in non-test code however.
Since the only thing I wanted was the strings of the typos, I pulled the list, then looped through the HighlightInfo's in the list, and pulled the .getText()s.
No danger of screwing anything up.
Then pushed all those strings into:
SpellCheckerManager.getInstance(project).acceptWordAsCorrect(word, project);
Viola! All current highlighted typos are now added to the dictionary.
Proper solution? No. Good enough for what I needed to accomplish? Yup.

off topic autocomplete suggestions

Can't remember when, but a while ago IntellIJ started to show suggestions in the autocomplete suggestions that seem off topic. Very often the "wrong" suggestion gets to the top of the list and ends up in the code. This starts to get annoying. ;-)
I wonder where it is coming from (what language is it?) and why does it shows up editing java files?
Example:
Starting to type, CTRL+Space, suggests:
Pressing Enter inserts:
This is just a single example it happens here and there.
Seems you have some non-default live templates configured? E.g. in this example the template has the fina abbreviation.
Delete them from your configuration for the IDE not to offer them in completion.

Umbraco ContourContrib Error

So I have a bunch of forms that I made using Umbraco contour and I'm also using the ReCaptcha datatype contained in the ContourContrib package.
My problem is that after reinstalling ContourContrib, I now get server errors saying:
Error adding macro Insert form from Umbraco Contour
Method 'Contour.Contrib.FieldTypes.ReCaptcha.ToolTip' not found.
I looked in the Contour.Contrib.dll and indeed there is no method called "Tooltip" in the referenced namespace and class. The oddest part is that after looking through Codeplex, I can't even find where that method ever even existed.
So my next thought was to remove the field in Contour and add it again. That might work, but I can't even get the "Forms" section of Contour to expand anymore because of this error.
I'm really at a loss and I'm hoping that smarter people than myself have some clue as to a different avenue I can take to resolve this.
Thanks for you time,
Jason
Found out that I was reinstalling a version that was 2 versions ahead of where I was before. I was installing v0.0.5 but the Contour.Contrib.dll only contained a method called tooltip in v0.0.2 and prior. Beware of this if you already have forms made and are thinking about upgrading.

SharePoint SPWeb.GetList seems to cause infinite loop?

So, I'm working on a SharePoint 2010 site that I developed, and I am trying to implement content type change propogation. During this process I seem to have found a strange bug. It seems my combination of calling methods in the SharePoint object model causes an infinite loop. You can see the code here (a little too large to post directly here I think): http://pastebin.com/U0qbLxpS. The key line there is on line 13. Leaving that line commented out results in an infinite loop of sub sites (starting at the first one). If I uncomment that line though, things seem to work fine. Does anyone have any experience with this bug or have any advice? Can anyone duplicate this issue for me? I was trying to use SPWeb.GetList("blah") instead of using SPWeb.List["blah"] directly as GetList is the recommended way to get access to a list (according to everything I have read). But this bug is a bit odd and is going to force me to leave a completely unrelated line of code in there (which leaves me feeling a bit strange).
My test site structure is this: http://localhost (main site) and http://localhost/ASubSite. The infinite loop happens on http://localhost/ASubSite and just keeps appending /ASubSite to the end and continuing the loop.
Thanks for any hope you can offer. If anyone can duplicate this, it would be great. Then maybe I can submit a bug to Microsoft about this. Otherwise, maybe this is just some strange combination of things I am doing combined with my site.

internal error markers

Theoretically, the end user should never see internal errors. But in practice, theory and practice differ. So the question is what to show the end user. Now, for the totally non-technical user, you want to show as little as possible ("click here to submit a bug report" kind of things), but for more advanced users, they will want to know if there is a work around, if it's been known for a while, etc. So you want to include some sort of info about what's wrong as well.
The classic way to do this is either an assert with a filename:line-number or a stack trace with the same. Now this is good for the developer because it points him right at the problem; however it has some significant downsides for the user, particularly that it's very cryptic (e.g. unfriendly) and code changes change the error message (Googling for the error only works for this version).
I have a program that I'm planning on writing where I want to address these issues. What I want is a way to attach a unique identity to every assert in such a way that editing the code around the assert won't alter it. (For example, if I cut/paste it to another file, I want the same information to be displayed) Any ideas?
One tack I'm thinking of is to have an enumeration for the errors, but how to make sure that they are never used in more than one place?
(Note: For this question, I'm only looking at errors that are caused by coding errors. Not things that could legitimately happen like bad input. OTOH those errors may be of some interest to the community at large.)
(Note 2: The program in question would be a command line app running on the user's system. But again, that's just my situation.)
(Note 3: the target language is D and I'm very willing to dive into meta-programming. Answers for other languages more than welcome!)
(note 4: I explicitly want to NOT use actual code locations but rather some kind of symbolic names for the errors. This is because if code is altered in practically any way, code locations change.)
Interesting question. A solution I have used several times is this: If it's a fatal error (non-fatal errors should give the user a chance to correct the input, for example), we generate a file with a lot of relevant information: The request variables, headers, internal configuration information and a full backtrace for later debugging. We store this in a file with a generated unique filename (and with the time as a prefix).
For the user, we present a page which explains that an unrecoverable error has occurred, and ask that they include the filename as a reference if they would like to report the bug. A lot easier to debug with all this information from the context of the offending request.
In PHP the debug_backtrace() function is very useful for this. I'm sure there's an equivalent for your platform.
Also remember to send relevant http headers: Probably: HTTP/1.1 500 Internal Server Error
Given a sensible format of the error report file, it's also possible to analyze the errors that users have not reported.
Write a script to grep your entire source tree for uses of these error codes, and then complain if there are duplicates. Run that script as part of your unit tests.
I know nothing about your target language, but this is an interesting question that I have given some thought to and I wanted to add my two cents.
My feeling has always been that messages for hard errors and internal errors should be as useful as possible for the developer to identify the problem & fix it quickly. Most users won't even look at this error message, but the highly sophisticated end users (tech support people perhaps) will often get a pretty good idea what the problem is and even come up with novel workarounds by looking at highly detailed error messages. The key is to make those error messages detailed without being cryptic, and this is more an art than a science.
An example from a Windows program that uses an out-of-proc COM server. If the main program tries to instantiate an object from the COM server and fails with the error message:
"WARNING: Unable to Instantiate
UtilityObject: Error 'Class Not
Registered' in 'CoCreateInstance'"
99% of users will see this and think it is written in Greek. A tech support person may quickly realize that they need ro re-register the COM server. And the developer will know exactly what went wrong.
In order to associate some contextual information with the assertion, in my C++ code I will often use a simple string with the name of the method, or something else that makes it clear where the error occured (I apologize for answering in a language you didn't ask about):
int someFunction()
{
static const std::string loc = "someFunction";
: :
if( somethingWentWrong )
{
WarningMessage(loc.c_str(), "Unable to Instantiate UtilityObject: Error 'Class Not
Registered' in 'CoCreateInstance);
}
}
...which generates:
WARNING [someFunction] : Unable to
Instantiate UtilityObject: Error
'Class Not Registered' in
'CoCreateInstance