When developing in MOSS I would be interested to hear peoples views on whether they choose to wrap functionality in web parts or to create .aspx pages and deploy those to MOSS and how best to make that decision.
Web Parts are reusable across multiple pages. So if I develop a UI that is only usable once, I create .aspx pages. But if I need something that is usable on multiple pages or if I don't know/can't control where it will be deployed to, I create a Web Part.
Related
I'm currently working on a CMS for meteor (basically a WordPress-like).
I have a simple question about the design of this CMS.
Should I divide my CMS in two application :
-One part for the viewed content (site, template, viewer plugins)
-Another one for the administration part (statistics, web mastering, post and page creation, etc)
Or,
Should I make an all in one application using different routes and security levels.
From my point of view both have pros and cons.
Divide :
Share the CMS between several servers.
Possibility to manage different websites with only one administration application. Looks like a network.
-Using administration without the viewer app.(Headless Drupal)
-Using the full meteor potential for big application.
All in one :
Smaller application, template more adapted to the administration panel.
Easier to handling it.
-Blog oriented.
I'm really interested by your ideas and opinion.
Thanks.
I'd suggest splitting it up between viewers and admin. You don't want viewers of the site to have to download so much extra code. Both parts can share the same database.
I am an experienced .NET Developer acting as interim SharePoint Developer, and am new to SharePoint. After determining that I need to go with an application page instead of a site page for a new project due to it's complexity and need of custom code behind. Before developing the entire solution, I wanted to tie up the loose ends of my understanding of application page deployments. I need to add this page as a URL on the left side of a Site Collection page (kind of like what happens when adding a subsite to a site page.) I have read about the modules, which seems extremely hacky to me. There must be a better way to develkop a custom page on top of SharePoint without the page being accessible to anyone on the entire site.
EDIT
The application I am wanting to develop on top of SharePoint exists purely for data entry and reporting purposes.
Have you considered using a Webpart?
With a visual webpart which is essencially a usercontrol wrapped in a webpart you can add as much complexity as you want and you also have code behind to hook to events etc.
The benefit of using a webpart is that you can then drop it on a page, and use all OOB sharepoint access controls.
You mention that you want to develop a data entry reporting app. So something you can do is to create a subsite. Look all access to modify pages except to owners. Create all your screens by adding pages to the subsite and dropping webparts on it with the logic you require for each screen.
Also make sure you deploy the werbparts via a web feature that only is activated in your subsite, this way the webparts are only available in that particular subsite.
I realise that Sharepoint in asp .net based but I have a PHP application that a user wants me to include in a Sharepoint site.
So is it possible to use PHP code inside sharepoint?
danit, when you say 'include' in the site, would it mean to be part of the site chrome (like inside the same menus etc) or just live connected with links would suffice?
I ask that because you can run php code under an IIS site but that would only keep the pages separated inside the same virtual host. if you need to actually join the functionalities you can:
Fake it with an iFrame (Page Viewer Web Part pointing to the php site for example).
you'll have to use some interop like webservices. It really comes down to what you want to do and not to if it is possible.
This is also possible by creating a web part page and adding a page viewer web part. You can link to the page, making it visible within the Sharepoint site, but it won't offer any interaction with Sharepoint itself.
Sharepoint treats the page as a shared document, however, so you can restrict access to it. I have done this in order to offer access to 'view only' content such as reports, but you can also use it for custom php apps that rely on a database other than the one(s) Sharepoint is using.
We've been asked to create a web application. One part of the specification is that in future, it can be integrated into Sharepoint. The last version of this app was written in PHP and "integrated" by means of an iframe embedded into Sharepoint; not ideal.
I'm looking to understand the use of Sharepoint in this context. I believe that you can write Sharepoint Applications which are more "native" to Sharepoint than the rough-and-ready iframe approach I discussed before. How easy is it to take a standard ASP.NET MVC application and fully integrate it into Sharepoint?
Does anyone have any thoughts, experiences, or resources on this matter?
I think the first question is what kind of integration with SharePoint are you trying to accomplish? The simplest is to use the Page Viewer webpart (i.e. iframe) method. You can also write custom webparts that show data from your custom application. That's a form of integration. The ultimate form of integration, of course, is to make your application run inside of SharePoint. That leads to my next point.
SharePoint (as of version 2007) is essentially a giant ASP.NET framework. So you can theoretically use it to host any ASP.NET web application. I have actually done it before and it works. However, that was a plain old ASP.NET webforms application (not MVC). If this is what you are trying to do, you definitely would need to rewrite your php application in ASP.NET.
In Sharepoint there is a Page Viewer webpart using which you can load a different url. This way you can easily "integrate" your application to sharepoint site ;-)
But if you are really looking at Re Engineering the application in SharePoint then its a different story. You have to study the current application and then develop it in SharePoint.
This fellow has an approach to writing PHP for SharePoint. A key statement:
There are two big tricks – getting the
XML right and using NTLM
authentication.
We got an requirement for implementing captial expenditure lotus notes application in sharepoint. It's having nearly five massive forms with all expense calculations and workflows.
What is the suggested approach in sharepoint to implement this?
I would agree that creating a custom ASP.net/SQL server web app would be the way to go if you have some ASP.net programmers available, though I'd recommend against embedding it via a Page Viewer Web Part. You can integrate ASP.net web apps directly in SharePoint, no embedding required.
If you don't have ASP.net programmers available, you can certainly do it in SharePoint and it may not be painful. The key issues are where you need to store your data and how relational the data needs to be. If the requirement is to store data in a relational DB, it becomes complicated to do it in SharePoint.
On the other hand, if you can imagine recreating your application's data as a collection of Excel spreadsheets, then it will be pretty straightforward to do it in SharePoint. In the simplest scenario, you could do all "development" using the SharePoint web interface. You would create a custom list in a SharePoint site for each expense form, then customize the site's default.aspx page to display a link the newform.aspx for each list. If the wokflows are basic notification/approval types, then you can also attach SharePoint built-in workflows to the lists via the web interface.
If you need custom form layouts, custom workflows and dynamic data filtering, then you could use SharePoint Designer to accomplish a great deal of design and development. Without more information about the existing application and workflows, it's impossible to say exactly how you should do it. But make sure you consider what parts of the existing application are requirements and what parts are just legacy functionality. If you can simplify the application, this is a great opportunity to do it.
While you can do it in SharePoint, it will be painful. You may be better off implementing the application as a stock ASP.net/SQL DB application and embedding it into SharePoint with a Page Viewer Web Part.
You can also skin your custom application to look like SharePoint using one of the SharePoint master pages as a template and link to it from your portal.
For added SharePoint integration, you can use Data View Web Parts or the Business Data Catalog (MOSS only) to query your expenditure application database and embed small reports and key performance indicators throughout your portal.
Alternatively to a Custom web app:
Create custom web controls implementing the forms and kicking off the workflows with custom layout pages to host the controls?
A site definition (just feature to add the pages+layouts at a pinch) to host the created pages "just so" in order to rely on "form1.aspx" being available always.
I would not try to "push" OOTB SharePoint functionality envelope to avoid creating custom code. Easier by far to
If you are going to do extensive workflow work in SharePoint be sure to consider buying an add-on like Nintex workflow or Blackpoint. It is almost always worth the expense over creating workflows with Visual Studio or SharePoint designer.
It's not easy to implement a solution for this in SharePoint, but we have a SharePoint App we're releasing in March 2014 which is a great capital expenditure workflow solution. http://budgetworkflow.com