-
-
Seems like a Sharepoint Developers like NAnt and developers that emply continous integration (usually with NAnt) also likes Sharepoint.
Jesper Halvorsen has implemented his own publishing task, doing approximately the same as NonstopBits task.
I would really urge all Sharepoint/NAnt developers to join forces with Kris Syverstad who has been doing this for a while now, and created a GotDotNet workspace. It would be great if the community could build a complete solution both for performing setup/clean operations on Sharepoint implementations, and performing reporting from CCNET to Sharepoint project webs.
-
-
Patrick asks why Microsoft is silent on the SmartPart approach to webpart development. He gets response from Mike Fitzmaurice and Mike gets flamed in comments for beeing egocentric and authoritative. Daniel gets in the race and shows support for the smartest of parts.. In other words the heat is on!
I've been asked by customers, the community and colleagues on my opinion on webpart development for a while. Recently we were doing a presentation on the subject and I feel one of the foils fits pretty good in this discussion.
The message we convey to our customers and the community is that the "MSDN"-way of coding webparts is a completely masochistic act. As the illustration shows, the simple stuff is done by using frontpage or standard sharepoint customization (often with a bit of re-thinking and compromize). The SmartPart is the ideal choice for any webpart development not targeted for mass distribution like webparts for SAP, Notes or MS Project.
Most of the time webparts are developed for a one-time affair and its obviously bloated to write your own render method. Nuff said about that.
I'd like to turn this discussion a bit. I think the root of this is a growing Sharepoint developers community which are shown little to no real support from MSFT. Recently Steve Ballmer stated that Sharepoint is Microsofts number ONE product [through Mike] yet there are no public product roadmap, Longhorn has got a cooler developer center at MSDN, and the only developer goodies we get are through bloggers like Daniel.
Face it. People like Jan, Patrick, Kris, Mike, Maxim, Bob, Tariq, Erol and the rest of the growing Sharepoint community has contributed in a major fashion the past year. When I visited TechEd this year in Amsterdam I searched high and low for interesting Sharepoint sessions or officials, ending up with a rather "so-last-year" session with Fitz (meaning that it was kinda low-level compared to what the community was doing at the time).
Create the arena Microsoft. We're already playing.
-
-
There is a lot of speculation on Microsofts strategy and plans for workflow engines in their productlines. CaPo refers to a document from Scott Woodgate and gets interesting comments on his post.
I've been puzzled by this for a while. It's now pretty clear that BizTalk Human Workflow Services (HWS) is a dead-end. Additionally it seems highly likely that Microsoft will buy SourceCode and their product K2.NET. After all, SourceCode moved from South Africa to Redmond; say no more.
Microsoft CRM has its own workflow engine out of the box, but robust possibilities for integration with other workflow tools with only "SOAP-callable" APIs.
My guess is that K2.NET will be fronted as the "new" HWS and will be tightly integrated with Sharepoint and the Office Servers (if that's what they're gonna do), and possibly MSCRM. Windows Orchestration Engine (WinOE) will eventually be the core driver and the foundation for BTS, but also directly or indirectly consumed by other server products.
This aligns with current MS strategy for bundeling server products with OS functionality, just like they do with using Windows Sharepoint Services as a frontend for BTS and MS Project solutions.
The consequences of this is that we'll need to carefully consider where we build current workflow solutions. Building value into one of the engines that will not be continued is not desireable.
Anyways, I'm just guessing..