When developing web parts in SharePoint can I inherit from the existing web parts and override their methods?
Or do I always need to start from scratch.
Many Thanks
If they are not sealed, you can inherit from them. In practise, It might work or not depending on how the web part you want to extend.
Most (all?) OTB parts are sealed.
A new toolbar with icon/no buttons sounds more like a design solution. Place the topnav placeholder in a invisible panel at the bottom (so page doesn't crash) and modify the rest visually (css+firebug) . Assuming I am not misunderstanding what you mean.
Its pretty easy to get started with webparts, http://blah.winsmarts.com//2006/05/14/writing-custom-webparts-for-sharepoint-2007.aspx should show you how. From there you should be able to write an RSS reader easily.
Related
For our Xpages application stack we have to create cca. 100 controls that will cover our new UI parts/helpers and some additional services. These controls are meant to be very general and have to be used by many Xpages applications. Now question is how to share these controls among applications(databases). Controls need some managed beans to work, also some CSS, JS and images. To copy the whole stuff into each application and maintain it somehow is not the way (even design inheritance doesnt help here). What's more ... mixing these 100 controls among application specific controls is real hell as controls doesn't support any namespaces or some packages grouping (like java in Package Explorer), so at the end we have very long list of controls in DDE which is nightmare to navigate and work with.
We tried to use Extension Library approach and followed this tutorial
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Master_Table_of_Contents_for_XPages_Extensibility_APIs_Developer_Guide
... but honestly I tried 3 times on my computer from scratch and even example project from tutorial didn't work properly and still caused some errors in update site project. My colleague also tried this on his computer with no luck. And entire process as described in the article above is set of many java classes, XML and configuration files even for small control (eclipse plugin project -> feature project -> updated site project and then you have to install this update site test it and when bug occurs you have to run another cycle ...). Comparing to e.g. this http://tapestry.apache.org/component-classes.html its extremely heavy weight approach in Xpages.
So my question is, is there any other approach that can help us in this area to share controls among applications? Or is there any update expected in this area for upcoming Notes release e.g. R9.1 ?
the most efficient way to share controls is an extension library. It does come with a learning curve. You could use Nathan's XSP Starter Kit to ease your pain. Alternatively you can use the import/export plug-in from OpenNTF to move controls (and their supporting files) around.
In any case: XPages custom controls do support name spaces and grouping -> just have a look at the property panel of a control. You can define:
the namespace (defaults to xc, but you are free to design your own)
the group it should appear in
icons
how it looks at design time (to hide the inner workings)
So step 1 is to group and clean and then think about the distribution. Extlib definitely would be best.
There is good ol' method for sharing design elements in NSF: templates. You can make your database a template, and then inherit just specific design elements by copy/pasting them at designer level. In design element's properties view, Design tab, look for "Inherit from the design template" property. It contains template name from which you copied the element. Watch out for the property "Prohibit design refresh or replace to modify", it should be off.
This has some consequences when deploying the application to production, though, so please, read the documentation/help about template inheritance. Especially combination with XPages/custom controls requires the template to be built and signed.
We use it to share custom controls like application layout and picklists with no problems.
I am kind of new to SharePoint. I am learning it on the go and learned about the concept of pagelayout and publishing features on the site. But I am not really 100% sure what is the difference between a WebPartPage, SitePage and PublishingPage. I kind of know what all these pages be used for, but what I not get is: why do they need to separate all these pages?
I think we can just get a publishing page and have all the feature there including webpart and everything else (with our choice of PageLayout). However I dont see a way to use a pagelayout on a particular SitePage.
Is there any particular reasons for using either one of them? Even though it seems like one of them can serve as all of them?
You should use page layout when ever you know the page structure. For example you are running an online news paper. You want to show the news to the users into three columns. First column is for menu, second column is for news content and third column is for advertisements. Now in your daily usage this layout is common. So you can use this page layout for entering the news. After creating the page layout you can make it as a default to your pages. Page layout is nothing but the structure of a page simply!!
A webpart page does not have a field for content directly on the page like a SitePage has. A Publishing Page is like a SitePage, but requires extra fields for dealing with the publishing extra features.
Using a single layout for all three risks being confused as to why one page does not work the same as another when it has the same layout (the difference would be the underlying features are different.).
I will make a comparison with cars. There are three type of cars, each is better suitable for a certain purpose: tractors for farming, buses for public transport, light cars for private transport. You could use a tractor for all the purposes above but it's not ideal.
"One of them can serve as all of them". This is not true in their current implementation. I'll give you one example: prefer Web part pages against Publishing pages to better control content added by contributors in an intranet. There are many other examples.
Can you (partly) hide the design of your XPages application when distributing them and how should you do so?
Patrick we hide the entire design for our IQJam and IdeaJam evaluations and all works fine. Not sure about how to hide only "portions" of the app.
Not possible to partly hide specific objects, use these steps to hide the application design completly
Create a two new templates (ntf's) from your nsf application
do replace design using one of the templates to the other with the checkbox "hide forumlas and "lotusscript" ticked
Did not test it for myself, but I would try to pack .class and .xml definitions of code generated for XPages (generally, content of WebContent\WEB-INF folder) into single JAR and deploy it to another database. This would work very well in case your code relies on views and forms in different database so you need not to bother with hiding regular Notes design elements.
There is still the option to decompile such classes what will reveal all bindings/scripts and component names, but at least you make it hard for someone.
Is there a way to extend the SPGridView control in a webpart such that a user can select the columns that they want to display? Kinda like when creating/modifying a view for a list?
Thanks
SPGridView is not sealed so certainly it can be extended with this functionality. You would need to build your own data store of what users have chosen (a SharePoint list should suffice), make the UI modifications, etc.
One thing I've found when trying to extend the provided SharePoint controls is that even though most aren't sealed, often they aren't designed to be extended either. In some cases the members are obfuscated as well which in some cases can put an end to extension plans.
Make sure you research this as much as possible with some quick proof of concepts before devoting to this development. You may find it's necessary to write your own control from scratch (or find another standard ASP.NET control that provides this functionality and hook it up to a SharePoint data source).
Has anyone got an thoughts on how to handle theming a WSS site for a single user who is visually impaired ... she uses high contrast settings for Word, etc.
But still leave the usual theme for everyone else
That second link on choppen's answer is one of the craziest/most clever workarounds I've ever seen haha.
By all means if you don't have much programming knowledge, use that idea.
Onto coding, you have different ways to achieve that, but without going into features and overriding sharepoint's render engine / site definitions, HttpModules and MasterPages sound more reasonable for this, MasterPages are even easier.
Have your code hooked in the Page_Load of the MasterPage and check if the SPContext.Current.Web.CurrentUser.LoginName is your user and then append to the head object a secondary theme link: <link href="/highcontrast.css" etc />
Remember if you put .NET code in the MasterPage you need to allow it on the web.config with the PageParsePaths. With a HttpModule override the Page_PreInit event in the Application_PreRequestHandlerExecute and you should be good.
These posts may give you some ideas:
http://sharepointmakesmecry.blogspot.com/2009/01/sharepoint-audience-targeted-branding.html
http://sharepointmakesmecry.blogspot.com/2009/02/user-centric-themes-sharepoint-branding.html
If the layout is done through css create a custom stylesheet for her and configure her browser to use that sheet for the specific sharepoint site. The following link may help.
http://www.microsoft.com/enable/training/ie6/formatpage.aspx