Ok, not a real comparison, but some curious behavior on the part of a DocumentCollection has reminded me why I abandoned manually creating DocumentCollections in favor of a good, old fashioned arrays. Not to say that the documentcollection does not have its uses, but I cannot figure out why it would not work for me in this particular instance.
Everyone who runs a blog deals with the incessant blog spam. There are alot of tools out there that block this crap, or at least hold it until you can spank it.
On this site I use Spam Karma and recently the author of the tool mentioned that he was seeing in increase in “smarter spammers” that were doing things like using tools that can parse javascript (inserting javascript payloads into comment forms is a way to identify spammers). For every spam that comes in, Spam Karma will evaluate many criteria like black-lists, keywords, user-agents, etc.. to determine what is spam and what is not. Evidently, some think there are some new tools out there that are better at circumventing these controls. Well, that may be, but SK just spanked a spam that makes me think these morons are getting more stupid.
Another basic criteria of spam control is counting the number of URL links in the message body, and spanking those that exceed the blog-owner-set threshold. Most spam control tools I saw defaulted to three links being the limit, and I notice alot of spammers keep there URL links to only two so this criteria will not apply. This recent spam message that I mentioned actually had 32 URL links in the body. Since Spam Karma “scores” each message with negative points for each time they break a rule, this spam was tagged with a total “karma” of -308.5 (originating from a well known spammer blacklist did not help his case either)!! With the worst spam messages being aroung -50, this has to rank as the most amateurish spam message ever.
I am still proceeding (slowly) towards a total overhaul of my present companies intranet, and I wanted something to “soften” the overall design. Rounded corners on things like menu headers, and around images came to mind, but I have always avoided that approach since they have traditionally relied upon creating images for the corners, and the smallest of UI changes always had the cascading effect of changes to those little images.
If you do anything in the area of intranet portal design, you will find this report from The Nielson Norman Group invaluable. I have purchased the last three reports and they have saved me countless hours of design time that would have been spent correcting mistakes or pondering design changes. Jakob Nielson’s announcement page has some highlights, but the full report has almost 200 screenshots and interviews with some of the designers of these intranet sites. The report is 158USD and is a PDF download of 287 pages.
A business need has recently forced the issue to create an interface that can read an RDBMS, collate the data, present it for informational purposes, and provide a reporting mechanism to collect errors in the data. Not very unusual requirements, but a good example of how “competing” technologies can be used in tandem, both showing their strengths. .NET with its rapid data binding model, and flexible web controls, and Domino with its rapid UI development model, and a plug-n-play security model.
Security, Sessions, and all that jazz
Let me first take the time to curse those things that I shall refer to as “RLC’s” (real life commitments), and their perpetual hold on our progress in this series. I apologize for the delay, so I will keep this installment as short as possible so I can deliver something that takes less than a week to digest.
Let’s do a little side by side comparison with what we have learned about .NET and what we know about Domino.
A recent request from a past client brought out an old piece of code that I always liked. This client had an ASP3 site that they used to manage another public site, and they had a requirement to do mail merges from this admin site. The previous site data management tool was an Access database where MS Office integration is pretty easy, but MS’s tight product integration (that classic love/hate relationship) makes the process of browser based mail merges with MS Word just as easy.
A more powerful form and view, and the need for validation.
Like a train wreck you just can’t turn away. If you have followed my disjointed ramblings so far then I hope the remaining installments will be easier to follow than the last. Let’s do a real quick recap of what we have covered:
1. The breadth of the .NET server objects
2. Page/form creation and positioning of controls
3. Binding data to server controls
4. How to use Multiview and View objects
5. How to use GridView and DetailView
Last pieces of our first form/view
Welcome back intrepid sailors, and let us waste no time on pleasantries. In our last installment we created our first table in MySql, and created the beginnings of our first view and first form. I left you with some homework to finish the view/form, and the first thing we will do is finish off our Keywords view/form.
Beginnings of data and Forms Redux
Hopefully you had a chance to browse through the various design objects that .NET gives you, and I hope you found some cool things. The last installment was nothing more than downloads and playtime with a little background. In this installment we will take some more concrete first steps in designing our help desk application.