In Sharepoint document library, when we create a new document library, the default view is 'All Document'. This one:
We can make a custom view from View > Create View (at the upper right corner of document library view). I created a new standard view and named it 'Chromed View'. I edited it, then I saw that this view only applied on current document library:
The other document libraries cannot use this view.
I develop a system that triggers document library creation from CRM (the document library's view from CRM Iframe is using that chromed view). The creation itself went well, I can create document library using Sharepoint web services. But I still cannot apply a custom view automatically for that newly created doc lib.
My question is, can we make a view that is global (not in one document library only) so that we can use that global view for any document library.
Thanks b4 for any opinion :)
You could also create a new custom document library type, with the view embedded in it. Whenever a new library is created from the new doc lib type, it will get the new view.
This is still a not truly "global" view, and you may have the same problems if the view gets changed (the view won't be updated on document libraries that have been created with previous versions of the view).
One way to do this is to create a feature with an event receiver. When a user creates a list, you can check if the list is of the proper type (101), and then add new views to it. The feature could also add this view to existing document libraries on activation. Shouldn't be too much of an effort.
The view is not truly global. As list definitions are duplicated for each instance, there are no such thing as a global view (afaik) in WSS. We could all hope that views are a part of content type in the next version.
To globally change all document libraries and to change all existing libraries you need to edit the XSLT file that is in the XSL folder in layours/templates
There are a couple of them in there but these are how all the libraries are generated with this u can basically specify how a default"" library would look. Make sure to make a backup for these files though. Also creating a new content type and copying these xlts to a different file name and then linking your content type to these instead could also be a solution so when a user creates a new library using ur content type you can make sure that they are created in a way that you want.
Related
To preface: I believe this may be impossible with OOTB solutions and if it is I have a plan B, but this plan would be much easier to implement if it is indeed possible.
Is there any way to create a SharePoint workflow that moves a file from a separate document library to another separate library?
The workflow is launched when a new item is created in a list. The item contains the information needed to find the document that it's referencing (ID, path, folder path, name etc...). Is it possible to take this information and then move the file being referenced to another library using a SharePoint workflow?
The document can't be simply copied because version history must stay with the document. I'm also unable to run the workflow in the library that contains the document because it's deciding on what documents to move based on the last modified date and as soon as the document is touched by the workflow it's been modified.
If you only want to copy files with metadata, we can use the OOTB workflow to achieve it.
If you want to copy files with version history, please check the Nintex workflow.
Nintex Workflow Move Document and Preserve Version History
Or we can create event receiver with custom code to achieve it.
Copy files between libraries by keeping versions
I'm trying to develop a Sharepoint online site to show inventory of every departments. Since I have several thousands of items, I separate the items into several libraries by departments. Each library will have the same columns.
Currently, I'm facing a problem of how to standard the new/display/edit forms for all libraries. Of cause I can use library template to do so. But what if I need to update the form, e.g. add a reference link or change the layout? Then I need to modify the form one by one for each library.
Is there any solutions that I can create one master form so that (1) it can be applied to two or more libraries, and (2) whenever the master form is changed, the change is automatically applied to the libraries?
Thanks
This is a great use case for Content Types.
At the Site Settings level, Create the columns you want. Then create the Content type you want, called "Inventory" for example. Add the columns to that Content Type.
Add the content type to each library.
Library Settings -> Advanced Settings -> Allow Management of Content Types
Remove the default content type from the library settings page
Now, you can update the columns at the site Content Type level, and it will publish to and update each library.
In Lotuscript you can manipulate design elements - create them, change them, rename them, etc.
Are you able to do the same thing for Xpages and custom controls design elements?
====================================================================
My question should have been clearer. What I want to accomplish is to copy an existing cc and give it a new name, programatically. The app will then close and reopen (or refresh or get rebuilt) so that the app can "see" the new cc. If I copy the cc it will only have one field on it. I will add custom code later. I could just create a new cc with no code in it, that would work too.
I am not familiar with the DXL exporter but I can research it. Using that can I just export the design of the cc to an XML file in a temp directory, use the transform to change the name, and then import the control?
I think the XPage or Custom Control design elements are probably under MISC_CODE or MISC_FORMAT design elements in a NoteCollection.
However, accessing that design element is the easy part. Doing a create / rename / change etc is a much bigger task.
Remember that the XPage or Custom Control XML file is only a starting point:
XPages and Custom Controls also have a .xsp.metadata file, as you'll see with source control.
Custom Controls will also have (and need) a .xsp-config file.
There are corresponding .java files for every XPage and Custom Control in the Local source folder. They're created by a builder based on parsing the XML. I don't think you'll be able to create those programmatically. I'm not sure of the impact of renaming them.
For Custom Controls, even if you can rename the .java file, it's referenced in the .java files of relevant XPages. Updating those is goiong to be a significant task.
The XPages runtime doesn't even use those .java files. Instead it uses the .class files in WebContent\WEB-INF (you need to use Project Explorer view and modify the filter to see those files). This is compiled byte code, so you won't be able to update the .class files for XPages containing renamed Custom Controls, as far as I know.
Even if you can rename the .class files, the XPages runtime almost certainly won't use them until either a Clean (which will overwrite anything you've done) or an HTTP restart. As far as I can tell they're cached.
Depending on your use cases, it's possible not all these points will be an issue, e.g. if you're modifying the XML files and building with headless designer.
I suspect this is why nothing was added to the NoteCollection object or a specific NotesXPage / NotesCustomControl API class added.
In Lotuscript you can manipulate design elements - create them, change them, rename them, etc.
This is only partially true. There is a LS API to create/alter views and outlines. Good luck with other design elements - although they're standard "notes", so you can access their items, in most cases you won't compile them and there will be some problems with signatures (real experience with TeamStudio CIAO).
Your question has two points of view - do you want to alter design elements in design process or alter running application?
To help a designer you can go the way of Eclipse extensions and enrich tools in IBM Designer to help developer. Something like TeamStudio Designer. In this case you need to look for source design elements, mentioned by Paul.
To enrich application you don't need to alter source design elements. IBM Designer transforms XML in source code to a Java code (JSF framework) - so you can generate your Java code from anything you wish. Take a look inside Local\xsp folder of NSF in Package explorer. You will find Java sources made from your XPages and Custom Controls. So if you don't need to work with design elements, go for Java components - they can be built on the fly.
And of course, there is always the option of DXL framework - so you can clone/alter design of the application through XML transformations. Good starting point: http://www-10.lotus.com/ldd/ddwiki.nsf/dx/ls-design-programming.htm
I have just started to investigate Microsoft's Entity Framework (EF) with a view to replacing our existing Linq2Sql data access library.
Whilst following some of the sample projects I came across the 'Add Code Generation Item' (context menu on the designer surface), specifically the 'EF 5.x DbContext Generator' template.
This template generates some nice simple (POCO) class objects for the model.
In my overall structure, I would like to extract/move these classes into a different project/assembly so that I can reference them from a generic repository i.e. I want to decouple the application's Data Access Layer from the EF entity data model.
Is this possible, or do I need to manually create a map for each class object (e.g. .ToDomainModel(), .FromDomainModel()).
Apologies if this is a stupid question - in my defence I am new to EF and also still getting to grips with the concept of the Data Driven Domain.
It is possible but you will lose part of the auto-magic. The auto-generated item is a T4 template. If you open it you will find somewhere at the beginning relative path to .edmx file. If you move the template you just need to update the path accordingly to point to the .edmx file you want to use for generation.
The disadvantage is that moving the template elsewhere will break automatic class regeneration when the .edmx file is saved (but I didn't searched for the solution so maybe it is possible to make it work). Because of that you must manually run custom tool (item in .tt file context menu) after each saved change to EDMX file.
Here's my situation:
I'm working in SharePoint 2007 Enterprise, I have a feature that creates a list for me when I deploy and activate it. My usual workflow thus far has been to deploy the solution, activate it, then open up SharePoint Designer to customize the list.
My customizations are typically pretty complex, but I'll keep things simple. In this case, let's just say that I edit AllItems.aspx, convert the data view to an XSLT data view, then I add one column with static text.
I've used a few different tools (SPSource, VSeWSS, SharePoint Manager, OCDExportList, etc) to extract my custom schema.xml and all the default views, but I have yet to have any luck figuring out where the the code for AllItems.aspx is now that it's been customized.
When I extract (using any of the tools above) AllItems.aspx is no different than the default. The <View> element in schema.xml is reduced to one line, for example:
<View DefaultView="TRUE"
MobileView="TRUE"
MobileDefaultView="TRUE"
Type="HTML"
FPModified="TRUE"
DisplayName="All Documents"
Url="Forms/AllItems.aspx"
Level="1"
ContentTypeID="0x" />
I'm really stuck here... I've got no clue what to do. Is it even possible? It would save me a great amount of time (and documentation) if I could include my customizations in my feature.
If there's any other info I'm missing that would help, let me know... thanks!
Latest findings:
I've found out a bit more in the past couple hours. If I save the list as a List Template, then save the .stp file locally as a .cab file I can extract its contents. One of the files is manifest.xml which contains the schema.xml as well as a few other sections.
One of those sections is a <webparts> section that has a <webpart> for each view. Each of those <webpart> elements contains a really long string of characters... no clue what those characters actually represent.
The important thing is that I think any custom views have to actually be Web Parts if deployed as part of a solution... but I'm not positive.
I have faced a similar issue a while ago. I had to create a very customized view and I had to give up the ListFormWebPart completely, and have created my own webpart to render the data.
Generally, when you customize the aspx file in SPDesigner, all your changes will be in the aspx file itself. Open it in SPDesigner and you will see there all the changes you have made. After you have converted to the XSL Data View, the standard ListFormWebPart is replaced by a DataFormWebPart, which doesn't care about the <View> tags specified in the schema.xml; Look in the aspx file itself for the ListFormWebPart.
Why not do all the customizations you want on a list, save the list as a template (it will include the associated AllItems.aspx) and then use that template in your feature to create your list? You could add the extracolumn from code (if it's dynamic and cannot be included in the template), and so on.
Yes you can. Get the Sharepoint manager tool from Codeplex
http://spm.codeplex.com/
Install it on a machine in your farm, it will allow you to browse the farm via a tree view that shows all objects.
Make the list via the Sharepoint GUI, then browse to it w/ SPM.
SPM will allow you to extract the MOSS/WSS created xml that describes the list view (it shows up in the left hand property grid), which you can then plop into your manifest.xml
I have a similar issue and have been doing a lot of research into this. The dataview web part to me is one of the most powerful components in Sharepoint. Unfortunately I have to provide my solution as a .wsp package and that means that I can not just make the site and use Designer on that site. I have taken a 2 step approach in that I used designer to create my dataview and I also edited the code of that dataview to replace the ListID and Guids to ListName and the actual list name. This allows it to be exported and used in any page/site as long as the list name is the same. I am creating a webpart page document library also in my solution and I believe I can add the pages that have the webparts to this library using the onet.xml file. I will try to get the results of that test in as soon as I can do it.