Header Image -

Monthly Archives

7 Articles

jQuery Performace Problem & Solution

by dave 0 Comments

One of my current tasks is to refactor our SharePoint portal’s design.

The original design was heavily laden with tables and large images.And each new subsite had its own master page, style sheet, and images directory. It was performing poorly in the browsers, and making it painful to create new subsites.

So I’m making a CSS-based version, removing all the images, simplifying the design while improving performance and flexibility.

The end result was much faster, but the look was too simple. It needed just a little something to give the design some depth.

And that is where jQuery came in — I picked up a Drop Shadow plug-in, and put some shadows around the main page elements. It was just enough to make the page look pretty decent.

BUT — performance degraded exponentially every time I worked with web parts. I haven’t determined exactly where or why, but I do know that somehow the jQuery calls combined with what SharePoint does to a web part page in edit mode was very unhappy. As-in, browsers hang and crashes almost every time I worked with a page.

So, I turned off the jQuery when a web part page is in edit mode by just popping the following into the code:

if ($(“.ms-WPAddButton”).length == 0){
…Do the jQuery Stuff…
}

In other words, I use jQuery to look for the ‘Add a Web Part’ buttons. If they are not found, I continue with the script. Editable pages have the simple interface, and run quickly. Normal content pages have the nicer interface… and still run quickly.

There may be a better way to handle this, but it has worked for me so far.

Notes Dev Hall of Shame #2

by dave 0 Comments

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info

——-

The main topic for today is user-configurable data.

It is true that hard-coding data is bad. The values in various drop-down lists, etc, would ideally be populated from data that the business owners can update.

But somehow, the idea of “hard-coding is bad” got misunderstood. One former developer obviously missed the point… that the idea was to not require code changes when data changes.

So we have a database full of hundreds of configuration documents. When you put these documents into edit mode, a big red warning pops up. “Do NOT change these documents without checking with Notes Development staff — code changes will be required!!”

Ehh… what??

So I look at the code. While it is true that these documents populate drop-down lists, the agents that then process documents are full of hard-coded business logic…

“If docmuent.FieldA(0) = “Data from config doc” Then…”

So if the data changes, the agents all break. So not only does any data change require a code change, but we are actually inviting the business to break things, and doing so in a way we need to debug code instead of just updating a field.

And this is done all through the entire Notes platform. To the point that the business community here think that these kinds of configuration documents are a built-in feature of Notes, and all Notes apps will always work this way.

In an environment like this, is it any wonder that people think Notes is a hopeless platform? I have a strong suspicion that if the Notes system had been well built from the start, SharePoint would never even have been a consideration here.

Roadmap for functions in the SharePoint World

by dave 0 Comments

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info

——-

When people say “SharePoint”, they usually mean any application accessed through a SharePoint portal. In truth, this may actually be SharePoint, but could also mean .NET or InfoPath applications.

One of the challenges we’ve had is defining which types of applications really are a SharePoint app vs. InfoPath vs. .NET.

But before I go there… why does it matter?

It matters in our organization because of the various roles certain individuals play. Power users and business analysts can do some of their own work… if it is truly pure SharePoint. We’re finding that Domino developers pick up InfoPath so well, they can do more with it than many Microsoft experts. (Which is a blog topic in and of itself, but in short, we’ve spent years working with form-based platforms… we know what to do with, for example, Conditional Formatting (Hide-Whens) to simplify forms instead of making new forms and views for minor UI differences.) And… .NET — while our team can certainly write the code, it brings on whole new levels of deployment and maintenance issues. So we try to avoid it.

Which brings us to the “Road Map”. This is not very profound… it is a very simple thought exercise for any application function that we are asked to provide:

1) Can SharePoint do it? Then make it so.

2) Well, then, can InfoPath do it? Then make it so.

3) Well, then, we’ll have to write .NET code.

After some discussions, we also added a question 0:

Does this even need server-side code? If JavaScript in the browser can do it, don’t get too clever with SharePoint… just write the script.

We had to add this question because developers who have never really been web-focused are forgetting that SharePoint ultimately renders in a web browser. Throwing some script in a master page or even in a content editor web part is sometimes a very quick, easy solution to some problems.

Our most recent example of this was a ‘Contact Us’ link. It was supposed to be available on all pages, provide an infopath form, then return the user to their original page on submit. They first wrote .NET code to do this. I talked them into just using a SharePoint list. Then they were doing some crazy SharePoint CAML stuff to make it happen. I talked them into just using JavaScript to append ‘&Source=originalpageURL’ to the HTML link.

I use this as an example to illustrate the eternal point of KISS — if 1 line of JavaScript code does the trick, don’t go writing .NET features. Find the simplest solution.

Code Quality vs. Platform Quality

by dave 0 Comments

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info

——-

If you’ve read the previous post, you know that the code quality at my current job is… questionable. Not all of it, to be sure. There is some good work. But… one bad app spoils the bunch, so to speak.

That form that took 10 minutes to open? It made people believe that Notes was a poor platform that could not perform well… that the Client was a horrible piece of work, and that the whole platform, in short, sucks.

I’ve tried to explain to many people that any given Notes system is only as good as the people working on it. People do not judge, for example, the PHP language based on how well people use it. (Which is ironic, because as a platform, PHP is actually quite poor…)

So why do they judge Notes based on the implementation?

And yet, when SharePoint goes badly, how do the same people manage to blame the implementation, not the platform. (And yet still re-hire the consultants who screwed it up in the first place…)

Somehow, there is a marketing issue ’round these parts.

Just a few more outrageous examples of what people do not judge…

“The Pinto was a horrible car, so all cars must suck.”
“Titanic was a horrible movie, so I’ll never watch another  movie again.”
“Terry Goodkind is a violent, misogynistic writer, so I’ll never read any books again.”

See? Wouldn’t those statements be absurd? Then why is it so hard for people to grasp the concept that a platform may still be good, even if the current implementation is not?

Notes Dev Hall of Shame — #1

by dave 0 Comments

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info

——-

I wanted to share a few choice items that have not only boggled our minds, but also caused endless amounts of helpdesk tickets.

1) The EmployeeID field in names.nsf

At first glance, it almost looks reasonable. They added a field to the person document, labelled “Employee ID”, called EmployeeID, and updated nightly from our HR system. All applications look to this field when they need to get user data, as it is the common data point between every platform in our enterprise.

Or is it??

As we started to get all kinds of calls that applications were breaking, we found that about 20% of the applications read this field. The other 80% read ‘EmplID’. Also in the person doc. NOT displayed in the UI. Nor was there an agent to set it.

Our old admin team set this field manually when they created new users, using agents local to their system. Only when we switched to a new admin team did the problem crop up.The new admin team was already setting the visible field, and we ended up hacking together a little agent to keep both EmployeeID fields in sync.

2) The Action bar of Doom and Despair

Let’s ignore for one second that this action bar has 125 actions, and all of them are the same code, copied and pasted with minor modifications.

Let’s even ignore that any given user only will see 2-3 of these actions, based on their role within the system, so there may have been a simpler way to do these functions.

Lets just focus on the hide-whens. The hide-whens that repeat the same DBLookup 5 times in each formula. Repeated across 125 actions. With some actions having 15-20 DBLookups, instead of the paltry 5.

Do the math — I counted 724 @DBLookups in this action bar just to determine which actions should display.

People wouldn’t even open the form. When I took this job, I was told that it takes 10 minutes to open that form, so they installed a Citrix system… because via Citrix, it is much faster. Really, is that the answer to an application coded so badly that it is unusable? To install Citrix to avoid the network bottleneck?

I rewrote all the code into a single function, wrote an agent that does all the lookups in a batch process each night, and sets your personal access in a profile document. One lookup to the profile document to know which actions to display. One set of actions with dynamic labels and a function call. I was left with 10 actions, 1 function, 1 agent, and 1 lookup. And the form now opens in 3 seconds.