Best practice for developing an alternate UI for Sharepoint interaction [Resolved]

Feb 28, 2010 at 8:26 AM

Best practice may be a little too early since these techniques you all are developing are just now really coming into their own for Sharepoint. And I am new to SharePoint and looking to absorb good info early on. And then I stumbled upon jPoint.

Basically I am used to working in the MVC mindset. Sharepoint blends alot of that together to make things easier for the end user and it makes sense. But coming up with custom layouts become more challenging. It looks easier to me, for example, to use jPoint to pull list data and just build a list instead of using a List webpart dropped on a page. Would that be advisable? It's not very "SharePoint-ish" I know but it's essentially how I do it elsewhere.

Another example is saving data to multiple lists. I haven't found the simplest way to really customize the display of multiple related lists in SharePoint yet, not to mention saving data BACK to those related lists. Say you have a list of options for a product for a user. The number of options can change and the values needed to be saved are saved per user/per option. But you also have other *sets* of options similar to that for this user and the design spec says they need to show at the same time and be saved in one go. I can see how to do it with jPoint (love that bulk save by the way) by updating the related lists checking for errors along the way. jPoint doesn't have happen to have a way of doing these kinds of transactions does it? :)

What it seems you have done with jPoint is allowed any front end to easily integrate with SharePoint. Is that desirable from an experienced SharePoint developer view? Mind you, the things I am building for this site don't need to be visually tied to the site components for lists, etc. The master layout will be retained.

Let me know if my questions make sense.


Mar 1, 2010 at 3:25 PM

Hi Michael,

jPoint can help a developer get around developing ajax like components for SharePoint. This ranges from custom layouts (hiding/showing/applying css to form fields), using jQuery plugins like flexygrid in combination with jPoint to create datagrids with search capability and yes you can even use it to save data back to the multiple lists with one click of a button.

As per your question this is becoming more and more desirable way to go for lots of SharePoint developers. At least for charging up your out of box SharePoint experience. If you are building some very intense application just living under Sharepoint I would still suggest creating a .NET project.

Here is an example of a SharePoint page jPoint team has built which demonstrates drag and drop, auto refresh queues, expand/collapse form, custom jquery menues, right click context menues, etc.

If you find something useful in there feel free to ask for suggestions/code snippets.

Mar 1, 2010 at 5:17 PM

One of the main reasons I like jPoint is that it allows deep interaction without having to develop and deploy compiled projects. I have done C# programming but not full on .Net web programming and the time/budget/technical constraints (like not having actual server access) prohibit a .Net project. Is the demo you posted done completely with jPoint then?

Since you mention intensity and .Net, what are the performance issues that should be watched out for? The current app I am working on won't be scaling up to millions of rows or anything like that. This page compares some rough benchmarks for 100K items and querying them from a list:

Are those the sort of concerns you mean requiring a .Net project or just intense interactivity within the UI?


Mar 1, 2010 at 5:36 PM

Lots of common things can be done with jPoint. We are thinking on extending functionality to calendars/meetings/documents, etc.

For now it performs great with lists display/updates, form editing, user info, interaction with jQuery plugins, and some other underlying sharepoint webservices.

Performance can be slow if developer does not use best clientside scripting practices (As with any programming we face).

Just like Google, I believe that we will see more and more clientside programming as client machines get faster and new browsers get more optimized.

SharePoint out of box gets slow grades from clientside perspective. You can use firefox plugin called Yslow to test your clientside pages.

Everything you saw in demo was done in jPoint.

The only things you can't do from clientside (as far as I know) due to security is uploading files to server and sending emails.

For those I have created very simple .aspx pages and I use ajax calls to post data to them.

We get lots of praise from people in secure environments who can not get access to server, but have to come up with some SharePoint solutions!

Mar 1, 2010 at 6:00 PM

Looking forward to digging in with it this week. I am in the category of those who don't have server access in a secure environment. :) Thank you for the resources and the help!

Mar 3, 2010 at 5:40 AM
Edited Mar 3, 2010 at 6:01 AM

I may have another unexpected use for jPoint. One thing I have been struggling through coming from using RDBMSs is that I am used to developing data models that go by the DRY principle. In this current project all the relevant links are actually already there in my lists in the Editor field but SPD doesn't seem to like creating a linked data source on that field. (I am asking on forums to see if this is my issue or actually an SPD issue.) So I added fields but I don't want to trouble the user who has already set this information in their own data to have to enter it every time. I am going to look at using a workflow to set this data via lookups as that is the SP way to do it. If that fails then I know with jPoint it's really simple. One query will get the data I need and then I can update the form accordingly. I'll see how this goes...

[edit] That wasn't so bad but it's not instant and I can see why people use multiple lists for things like this but those looping workflows are a beast! For web developers at least jPoint would be so much more straightforward than that (IMHO).

Mar 3, 2010 at 6:31 PM

jPoint steps:

On NewForm.aspx add Form Webpart and add code to read the form.

Now that you have form read in memory make a call to a list for lets say last item created by this user (you can use Author with userId like we saw in different post).

So now you have the form and data to fill it out with.

You can pre-populate just a few specific fields.



jP.List.getList(SiteURL, ListName);



And you can even disable those fields so user can not overwrite them or even hide the rows if user does not even need to see those fields anymore:


Let me know if this was something you were looking for?

Mar 3, 2010 at 6:34 PM
Edited Mar 6, 2010 at 6:37 AM

Yeah that is what I suspected it would be in jPoint. Nice, simple, easy. I was able to do it in a workflow for this one but I think the jPoint version will be a cleaner experience.

[edit] Just one caveat for newbies. You have to remember to actually get some list items before you access the Items data. Another post referenced this link:

There you will see before the Items is populated you need to do a call to yourList.getSPItemsWithQuery with at least a basic query.

Hmm... Currently buildQueryContent will not handle an empty query it seems. Is that correct? Perhaps a default query can be specified if none is present like 

<Query><OrderBy><FieldRef Name="ID" Ascending="True" /></OrderBy></Query>

just so one doesn't have to be set. Would that be desirable? Or would be it better to have another method that can do that like getDefaultSPItems()?

[edit 2] When getting data you need to also check for empty data just in case. I am doing something like the following:

    var result = null;

    var qry = $.nano("<Query><Where><Eq><FieldRef Name='{field}' LookupId='True'/><Value Type='Integer'>{userID}</Value></Eq></Where></Query>",{field:'Editor',userID:getUserID()}); 

    if (list.getSPItemsWithQuery(qry).JQueryData.length > 0) { result = list.getItemsFieldData(['ID','Field1','Field2',...]); }

    return result;

a convenience function on the list can help simplify that a little bit. Maybe list.dataLength?