I'm learning SharePoint development.
I read some general how to build a web part, but I'm wondering what a web part is in general?
Big picture, why are they used, what problem is it solving?
Think of a Web Part as a reusable custom web control that is placed, positioned, and whose attributes are set in the browser instead of in Visual Studio. Since SharePoint places such a high priority on customization and content authoring, there needs to be a way for a non-developer to add or modify controls on the web page. Web Parts are that way.
Related
We have an idea to use ADX with MVC 5 and CRM 2013.
Is it possible?
We are doing background research on this whether to use ADX or not.
We have used ASP.NET with ADX previously.
This will help take a decision and will save our time.
Appreciate help if anyone know about this.
Adx portal - http://www.adxstudio.com/products/adxstudio-portals/
ADX offers a great product with an impressive feature list. http://www.adxstudio.com/products/adxstudio-portals/portals-features/
Like any add-on, look to see if there is something it contains that you deem as being vital and valuable enough to justify. Additionally, does your team have the ability/time to create the end product with or without ADX?
This is an opinion based question and in my opinion, none of the features alone justify the price. Especially seeing that ASP.NET + NuGet pretty much covers most of these features already.
Adxstudio Portals delivers managed forms by rendering a form in an Adxstudio Portal based on a particular form or view customization defined on an entity in CRM. Within CRM, entities can be customized and forms and views can be modified or created depending on your requirements.
https://community.adxstudio.com/products/adxstudio-portals/users-guide/managed-forms/
and
https://community.adxstudio.com/products/adxstudio-portals/developers-guide/web-controls/crmentityformview/
Above is the main reason us to consider ADX Studio.
ADX Studio, offers a good tool set to the client that has an internal developing team that will pick it up after you finish to customize it. Basically you provide some page template and the user is able to mess around with the forms to have a tailored experience (this works well when you don't have any logic on the page, just set the page and you are ready to go). Anything that is not in this category is custom made, means that you need to code it, and you will lose all the additional ADX benefits (for what concerns the read/write to CRM). Consider that a CRM developer is not a full asp/mvc developer, so anything that is more complex than change some code behind in a page template will create you problems, also all the jscript on the adx pages needs to be tailored, and you will need developers that are knowing the current web development standards, from Bootstrap to a decent js framework. Personally I'm not a huge fan, but the built-in authentication and some other features are making it a viable product. Consider that to customize it you will need someone that knows responsive design and js.
Building an MVC web application. Will be a single page app highly driven by javascript (require.js, pager.js, jquery, knockout, etc).
This application would have its own built-in pages, controllers, etc - and would need to be able to accept external plug-and-play functionality as well.
Ideally, I could just drop a .dll from another MVC web app into the main app and it would inherit not only the dropped in app's controllers, but would also bring in its web files (.htm, *.ts, *.js, *.css, etc).
Imagine having a home page with tiles for each installed dll. Referencing a new dll would add the app's tile to the home page - which is an entry point into the app.
Each plug-and-play app would need to adhere to our routing design (for MVC controllers and PagerJS).
Lastly, each app would need to be able to share user login data.
I know my questions are a bit broad, but I just wanted to get some ideas and see where it takes me.
MvcContrib has introduced Portable Area that is a set of reusable multi-page functionality can be dropped into an application to provide rich functionality without having to custom build functionality that is literally the same in every application.
This could be considered a plug-in or add-in type of functionality. The portable portion of this approach is that the area can be distributed as a single assembly rather than an assembly and a host of other files, like views or other html assets that need to be managed and maintained over time.
By making a portable area totally self contained in a single assembly, this should allow for easier reuse and upgrades to the area. The challenge for doing something like this has been how do you allow enough control over the User Interface by the application yet still allow the actual views to be packaged with the logic.
The description above is a part of a popular project in CodePlex which could help you to understand/use the technology behind the concept of Plug-able MVC application.
ASP.Net MVC Portable Areas via MvcContrib is a post by Eric Hexter that describes Portable Area in detail.
When porting a classic ClientServer Application to a web applciation (by totally rewriting it from scratch) a typical qusstion is
"How do I manage the multi form scenario i am used to?"
In a Windows (Delphi) application, such in my case, the user is using the application accessing more forms in parallel or one at a time but all of them are displayed on screen simultaenously (may be someone is minimized, othres are modal, ....).
In a web application the options are:
1) use different browser tabs
2) Have a kind of Navbar on the left and populate a full screen (vull viewport) "Panel" that contains the "form"
3) Have a "simulation of the classic behavior" as supported by ExtJS (try this example where on a same webpage multiple forms exist and they are movable like on a windows desktop
(3) is strange and it reminds me of RDP
Which alternatives to (1) and (2)?
It's important to get your basic knowledge about web-applications straight first. A desktop application has total control about what forms are shown and what happens on/to them. Web applications communicate only using requests coming in from a web-browser and responses sent back. This can be either by normal navigation to a URL, or by Ajax calls.
There are a number of options that try to translate between the form-designer way of doing things and the request-response nature of the web, but in my personal opinion, this will almost always give a result of lesser quality and will require you to delve into the translation-layer to get this or that strange artefact of it out of the way. So I would suggest to get into HTML and CSS and javascript and decent webpage design as well as building a HTTP Delphi back-end.
See also this list: What Web Application Framework for Delphi is recommended?
(Disclaimer: I'm behind the xxm project)
We have a client who is not willing to give us access to their SharePoint environment.
The work involves creating a bunch of custom site columns, custom site content types, page layouts and pages from the custom page layouts. We are going to create this in our environment and the plan is to "move" the pages to our client's environment.
The page layouts will also contain few content editor web parts.
I tried downloading the page to the disk and giving it to the client, but the downloaded page does not contain data entered in the content editor web part.
I thought of creating all the custom stuff (columns, content types, page layouts, and pages) in a sub-site and exporting the sub-site and have the client import the sub-site in their environment. At present I am having an issue but is this the correct way of achieving my goal?
Is there a better way to do this?
Thanks
I've used the export and import commands (stsadm.exe) for subsite content and it has proved to work in most scenarios. Just be aware that there are limitations which may or may not apply to your situation, which are described here:
http://blogs.technet.com/b/stefan_gossner/archive/2009/05/27/limitations-of-stsadm-o-export-import-related-to-publishing-sites.aspx.
Is using a third party tool one of your options? If it is, I would recommend a tool on Codeplex called the Sharepoint Content Deployment Wizard. I have used it to migrate content from one server to another. One downside to this tool is that it does not use webservice calls so it must be run locally from the Sharepoint server. I have used it with WSS 3.0, MOSS 2007 and MOSS 2010.
You can find the details here: http://spdeploymentwizard.codeplex.com/
HTH
We are trying to build an application which has a UI like OUTLOOK?
Something which has a left navigation pane and then right side there is a details pane.
It would be a heavy on data side. We need to access Database numerous times to access the data to be displayed.
Is SILVERLIGHT a good option which will provide RIA effect? Or Should I stick to ASP.NET building aspx pages and giving it a rich effect with Ajax?
What are different ways of handling this situation?
I've always thought ExtJS has a very Office 2007 Look and feel
http://www.extjs.com/deploy/dev/examples/feed-viewer/view.html
I will suggest you look at WPF, it will be perfect for this type of application. It does have the advantages of both ASP.NET since you can create browser pages and also the UI capability of Silverlight, some people say WPF is like Silverlight with steroids.
The RadControls from telerik have a built in Office and Outlook skin and provide all the different controls you want (grid, left panel bar, right grid, right scheduler) Their controls are available for Silverlight, ASP.Net and WPF so you can try them both out and see what works for ya.
Outlook grid example
Outlook Panel Bar Navigation example
Silverlight Scheduler
I'm using them and they're great.
I think you need to decide whether your users are OK with installing your application (WinForms, WPF etc) or if it has be run from a web browser (Silverlight, ExtJS, Ajax). Constructing an Outlook clone in a web environment is often more difficult (browser compatibility), and you can have issues with performance. However web applications are easier to update and maintain.
Consider usability too. For a desktop application Outlook may be a reasonable model to follow, but users often expect the web to work differently from desktop applications.
If you're going to use Silverlight or WPF then check out these blog posts on using the Prism framework to build a modular UI which looks like Outlook.
http://blogs.msdn.com/erwinvandervalk/archive/2009/03/02/how-to-build-an-outlook-style-application.aspx
http://blogs.msdn.com/erwinvandervalk/archive/2009/04/29/how-to-build-an-outlook-style-application-with-prism-v2-part-2.aspx
Prism (http://www.codeplex.com/prism) was designed to build just this sort of modular UI.
Ade