Comments on: The Middle Tier Manifesto: An Alternative Approach to Development with Microsoft SharePoint http://www.endusersharepoint.com/2010/04/15/the-middle-tier-manifesto-an-alternative-approach-to-development-with-microsoft-sharepoint/ No GeekSpeak on SharePoint 2007 WSS and MOSS Mon, 27 Dec 2010 21:17:12 -0500 http://wordpress.org/?v=2.8.6 hourly 1 By: Tom http://www.endusersharepoint.com/2010/04/15/the-middle-tier-manifesto-an-alternative-approach-to-development-with-microsoft-sharepoint/comment-page-1/#comment-57961 Tom Tue, 20 Apr 2010 20:28:09 +0000 http://www.endusersharepoint.com/?p=7327#comment-57961 I totally agree with this Middle Tier way of thinking. Developing everything using C++ or other such methods is not alway the best or fastest way to do things, especially in SharePoint. One of the key things about SharePoint is that a well trained administrator, or high end user can do much for themselves before they must rely on IT. And that's good for IT, as well. I wanted to have a way to color a calendar, and color a line in a list. I went to our IT developers for a solution. I was put in a que and waited for 4 months before they accomodated my request. Other requests are still waiting after 2 years. Lo and behold, I found a way to do what I wanted on my own by reading info from this site and others - all Middle Tier solutions. I put them in place without using SP Designer. What code there was, was in Jquery, or other client side coding I could copy and deploy without harm to SharePoint, and without involving IT. When I showed the developers what I'd been able to accomplish, they brushed it off and left me with the feeling it was beneath them. Yet, they never came back with their solution to help me. Is this a common attitude with the developers community, or is it just isolated? All I know is I'm thankfull to the true (felxible) developers on sites like this one that seem to truely care about the thousands of us non-developers out here who have to fend for themselves much of the time. Thanks, Mark for all you do. Tom I totally agree with this Middle Tier way of thinking.

Developing everything using C++ or other such methods is not alway the best or fastest way to do things, especially in SharePoint.

One of the key things about SharePoint is that a well trained administrator, or high end user can do much for themselves before they must rely on IT. And that’s good for IT, as well.

I wanted to have a way to color a calendar, and color a line in a list. I went to our IT developers for a solution. I was put in a que and waited for 4 months before they accomodated my request. Other requests are still waiting after 2 years.

Lo and behold, I found a way to do what I wanted on my own by reading info from this site and others – all Middle Tier solutions.

I put them in place without using SP Designer. What code there was, was in Jquery, or other client side coding I could copy and deploy without harm to SharePoint, and without involving IT.

When I showed the developers what I’d been able to accomplish, they brushed it off and left me with the feeling it was beneath them. Yet, they never came back with their solution to help me.

Is this a common attitude with the developers community, or is it just isolated?

All I know is I’m thankfull to the true (felxible) developers on sites like this one that seem to truely care about the thousands of us non-developers out here who have to fend for themselves much of the time.

Thanks, Mark for all you do.

Tom

]]> By: Kathy Boilek http://www.endusersharepoint.com/2010/04/15/the-middle-tier-manifesto-an-alternative-approach-to-development-with-microsoft-sharepoint/comment-page-1/#comment-57959 Kathy Boilek Tue, 20 Apr 2010 20:09:57 +0000 http://www.endusersharepoint.com/?p=7327#comment-57959 Marc you have put together what no one has tried to do and I and I know others appreciate it. There is a time and a place for everything and you showed that. Thanks for taking the time to write this. I am even passing this along to our SP Governance team. Marc you have put together what no one has tried to do and I and I know others appreciate it. There is a time and a place for everything and you showed that. Thanks for taking the time to write this. I am even passing this along to our SP Governance team.

]]> By: spevilgenius http://www.endusersharepoint.com/2010/04/15/the-middle-tier-manifesto-an-alternative-approach-to-development-with-microsoft-sharepoint/comment-page-1/#comment-57878 spevilgenius Tue, 20 Apr 2010 13:31:30 +0000 http://www.endusersharepoint.com/?p=7327#comment-57878 Yes, I have done this a few times but it still has the same issue of having to redeploy whenever a change is needed. For the most part I just have to write custom webparts if I need them. Mostly I am trying to learn how to override the default form templates which is working well so far. Yes, I have done this a few times but it still has the same issue of having to redeploy whenever a change is needed. For the most part I just have to write custom webparts if I need them. Mostly I am trying to learn how to override the default form templates which is working well so far.

]]> By: Marc Anderson http://www.endusersharepoint.com/2010/04/15/the-middle-tier-manifesto-an-alternative-approach-to-development-with-microsoft-sharepoint/comment-page-1/#comment-57877 Marc Anderson Tue, 20 Apr 2010 13:28:10 +0000 http://www.endusersharepoint.com/?p=7327#comment-57877 Generally, yes. Since you can do just about anything in a DVWP, you could cause yourself other problems, too, e.g., absolute vs. relative links. M. Generally, yes. Since you can do just about anything in a DVWP, you could cause yourself other problems, too, e.g., absolute vs. relative links.

M.

]]> By: Fredrik http://www.endusersharepoint.com/2010/04/15/the-middle-tier-manifesto-an-alternative-approach-to-development-with-microsoft-sharepoint/comment-page-1/#comment-57874 Fredrik Tue, 20 Apr 2010 13:20:57 +0000 http://www.endusersharepoint.com/?p=7327#comment-57874 As long as you refer to ListName instead of ListId (or figure out the list id manually) it should be fine? As long as you refer to ListName instead of ListId (or figure out the list id manually) it should be fine?

]]> By: Marc Anderson http://www.endusersharepoint.com/2010/04/15/the-middle-tier-manifesto-an-alternative-approach-to-development-with-microsoft-sharepoint/comment-page-1/#comment-57871 Marc Anderson Tue, 20 Apr 2010 13:02:54 +0000 http://www.endusersharepoint.com/?p=7327#comment-57871 You can import if you've followed some rules with your DVWP development. It's not a perfect solution, but it can be a helpful one. M. You can import if you’ve followed some rules with your DVWP development. It’s not a perfect solution, but it can be a helpful one.

M.

]]> By: Fredrik http://www.endusersharepoint.com/2010/04/15/the-middle-tier-manifesto-an-alternative-approach-to-development-with-microsoft-sharepoint/comment-page-1/#comment-57843 Fredrik Tue, 20 Apr 2010 10:51:25 +0000 http://www.endusersharepoint.com/?p=7327#comment-57843 Never tried, but isn't it possible to create data view webparts on your test environment and then import them to your production site in the web interface even if SPD isn't allowed? Never tried, but isn’t it possible to create data view webparts on your test environment and then import them to your production site in the web interface even if SPD isn’t allowed?

]]> By: spevilgenius http://www.endusersharepoint.com/2010/04/15/the-middle-tier-manifesto-an-alternative-approach-to-development-with-microsoft-sharepoint/comment-page-1/#comment-57841 spevilgenius Tue, 20 Apr 2010 10:37:53 +0000 http://www.endusersharepoint.com/?p=7327#comment-57841 Oh it would be so cool to be able to use the middle tier more often! Unfortunately for me, I am stuck in an environment where we are not allowed to use Sharepoint Designer on our production network because it was deemed a security risk with no real details as to why. We also have to 'develop' packages that can be used by other remote organizations. It is much easier to build most of what I do in Designer but then to try to import that into Visual Studio just seems wrong in so many ways. I am not the best .Net coder by any stretch of my imagination, but I try to keep things simple as much as possible and so far that has worked for the most part. Luckily in my case, we have access to the server farm and we try our best to make solutions that have a small footprint on the server. Unfortunately this model leads us to create solutions that we have to stress to the customers are not very changeable once deployed. Not that changing the solution is not possible but redeploying solutions with your fingers crossed is just not fun! Oh it would be so cool to be able to use the middle tier more often! Unfortunately for me, I am stuck in an environment where we are not allowed to use Sharepoint Designer on our production network because it was deemed a security risk with no real details as to why. We also have to ‘develop’ packages that can be used by other remote organizations. It is much easier to build most of what I do in Designer but then to try to import that into Visual Studio just seems wrong in so many ways. I am not the best .Net coder by any stretch of my imagination, but I try to keep things simple as much as possible and so far that has worked for the most part. Luckily in my case, we have access to the server farm and we try our best to make solutions that have a small footprint on the server. Unfortunately this model leads us to create solutions that we have to stress to the customers are not very changeable once deployed. Not that changing the solution is not possible but redeploying solutions with your fingers crossed is just not fun!

]]> By: Matt Bramer http://www.endusersharepoint.com/2010/04/15/the-middle-tier-manifesto-an-alternative-approach-to-development-with-microsoft-sharepoint/comment-page-1/#comment-57727 Matt Bramer Tue, 20 Apr 2010 02:45:21 +0000 http://www.endusersharepoint.com/?p=7327#comment-57727 While I cannot speak on development cycles since I'm not a developer, I can add my 2 cents in about the "Middle Tier". Plain and simple; Unlocking the mysteries of the DVWP series provided my Marc has simply changed the game for me. Ever since following and referring to the series, I have been able to jam out solutions that are running my company's project workflows. Since this company isn't considered an enterprise, then you may say they are "toy applications"; I say "They provided a solution." From what I've read over the internet and experienced myself, I'd say the Enterprise makes up of about 20% and the rest of it being small "toy applications" (Granted 73% of all statistics are made up on the spot, ohhhhh, let's say about 89% of the time ^_^) If the market only needs small applications, then it would make sense to make use the great tools available for client side development. Again, that's my opinion and I'm only referring to my experience. So far, I've been able to *NOT* deploy any custom code to my server and use all OOTB tools and I've managed to build all of our business intelligence into SharePoint. My point really is, if you are a developer, you have to realize what is available to you already. I feel like Marc's Manifesto brings up some great points. So many, I've had to read it a few times... I may be wrong but I think using a DVWP, you can make any data you have stored in SharePoint, do anything you want. Why would you not want to use that approach? While I cannot speak on development cycles since I’m not a developer, I can add my 2 cents in about the “Middle Tier”. Plain and simple; Unlocking the mysteries of the DVWP series provided my Marc has simply changed the game for me. Ever since following and referring to the series, I have been able to jam out solutions that are running my company’s project workflows. Since this company isn’t considered an enterprise, then you may say they are “toy applications”; I say “They provided a solution.”

From what I’ve read over the internet and experienced myself, I’d say the Enterprise makes up of about 20% and the rest of it being small “toy applications” (Granted 73% of all statistics are made up on the spot, ohhhhh, let’s say about 89% of the time ^_^) If the market only needs small applications, then it would make sense to make use the great tools available for client side development. Again, that’s my opinion and I’m only referring to my experience. So far, I’ve been able to *NOT* deploy any custom code to my server and use all OOTB tools and I’ve managed to build all of our business intelligence into SharePoint. My point really is, if you are a developer, you have to realize what is available to you already. I feel like Marc’s Manifesto brings up some great points. So many, I’ve had to read it a few times…

I may be wrong but I think using a DVWP, you can make any data you have stored in SharePoint, do anything you want. Why would you not want to use that approach?

]]> By: Mike Oryszak http://www.endusersharepoint.com/2010/04/15/the-middle-tier-manifesto-an-alternative-approach-to-development-with-microsoft-sharepoint/comment-page-1/#comment-57710 Mike Oryszak Tue, 20 Apr 2010 01:01:08 +0000 http://www.endusersharepoint.com/?p=7327#comment-57710 Back in January there were some heated debates about the use of jQuery and whether it had any place in a solution provider's toolkit. I wrote an article about SharePoint Dev and Customization Paths (http://nextconnect.blogspot.com/2010/01/sharepoint-dev-and-customization-paths.html) and I think it applies very well to this discussion. I believe in having options and applying the correct path for a given problem. Not every problem should be built with managed code, and in some cases or environments ad-hoc customizations are not appropriate. More than anything the architect needs to be educated in the decision points and needs to work to help educate the decision makers. I have been in a few environments where there was a strict rule that there can be no server solutions. To me that is just as wrong as an environment that promotes a strict rule of no SharePoint Designer customizations. Understand the problem, and select an appropriate solution. Don't let your preferred approach dictate a solution. Back in January there were some heated debates about the use of jQuery and whether it had any place in a solution provider’s toolkit. I wrote an article about SharePoint Dev and Customization Paths (http://nextconnect.blogspot.com/2010/01/sharepoint-dev-and-customization-paths.html) and I think it applies very well to this discussion. I believe in having options and applying the correct path for a given problem. Not every problem should be built with managed code, and in some cases or environments ad-hoc customizations are not appropriate. More than anything the architect needs to be educated in the decision points and needs to work to help educate the decision makers.

I have been in a few environments where there was a strict rule that there can be no server solutions. To me that is just as wrong as an environment that promotes a strict rule of no SharePoint Designer customizations.

Understand the problem, and select an appropriate solution. Don’t let your preferred approach dictate a solution.

]]>