HELP. I accidentally deleted a bunch of xpages and custom control out of my database and have no backup. is there any way of recovering those elements?
Presumably you don't have source control enabled. If not, there's one way, best done on the same PC where each design element was last edited.
Create a brand new XPage with the same name.
Go to the source pane
Right-click and choose Compare With... > Local History
If it was last saved recently on that PC, you'll see the previous version.
For the future, I strongly recommend using Source Control and outputting to the On Disk Project and committing frequently to a source control repository. I did a session and a Notes In 9 a few years ago on source control and the Show and Tell slides on my blog (accessible from your favourite search engine) show how to install Redmine (courtesy of Declan Lynch) or Stash (courtesy of me). Alternatively BitBucket allow private repositories accessible for up to five users. This is one of those cautionary tales of why source control is relevant even if you're not working in a team. There are DXL rouond-tripping issues with some edge case traditional design elements, which is another reason I tend to keep my XPages UI in a separate database from my design (which has the views, forms, agents etc).
There is no undelete for design elements (or documents). Sure you don't have a backup somewhere?
This is where source control is handy...
Sorry...
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.
When using the Ext.Lib Name Picker control connected to the NAB, the default is to view the first 50 entries from selected view (depending on whether groups/Persons is selected in property).
But there are no scroll/paging buttons on the dialog.
If I want to pick an entry from the NABPicker and the entry is after the first 50 I must use the Search button to find it.
Is this working as designed or a feature not yet added?
/Mike
You might be interested in using the viewpicklist control from openntf instead, link
It is very felxable, just set it to use the names.nsf and whichever view you need.
As far as I know this is working as designed. The server only returns a set number of entries so that the amount of data transfered when opening the Name Picker dialog box is kept nice and small, this way the dialog box opens faster.
You can increase the number of entries returned by increasing the maximum limits in the server document and internet site document and then increasing the maxRowCount attribute on the picker but you will seriously affect the performance of your application and it is not recommended.
Hopefully in a future release of the control they will add some sort of ajax based scroll similar to the inbox scroll in iNotes.
Mike:
I think the answer is "both". Working as designed and feature not added yet...
The Ext Lib is a open source initiative designed to support the simplistic Discussion, Team Room, and Document Library applications. The designers have limited experience with more complex applications and clearly limited exposure to large address books in their development arena.
The NAB pickers are a source a major disapointment to those of us trying to build larger scale applications. Perhaps at some point it will become a usable component but is is only marginally usable at this point.
/Newbs
I am new to Sharepoint and I want to make sure I am on the right path.
I am in a highly restricted environment and would rather do this in Visual Studio but am currently in the position where I have to try to get this to work using just the web interface and Sharepoint Designer.
I have created multiple lists that I plan on using in a relational way. I have designed this to mimic a relational database.
I have been able to link these lists for multiple item views and single item views, but need to be able to create items and modify items and so I need to be able to also link these lists and use them in a form.
Is this even possible?
If not, how do I handle updating these items?
Lastly.....
Am I going about this all the wrong way?
Thanks!
Tim
It is possible to do so using visual studio, not sure about SharePoint designer. I've been doing something fairly similar for a client myself however I am able to use visual studio to develop my features and even then it's been a pain.
Part of the issue is that various controls in SharePoint make the assumption about query variables and their meaning to the control (the ListFieldIterator comes to mind on this one). Trying to edit two different list's items on a single page is possible but I don't think it could (or should) be done through the desinger.
Can you get away with two separate forms/pages? If so that makes life much easier where you could do some kind of linking/forwarding between the pages. If you have to have a single page that represents both lists and their many items things get much more difficult. For the later you will almost certainly have to use Visual Studio since you will have to handle quite a bit of the server side logic.
Depends on how restricted you are. If you have access to the server via RDC, you could create these lists bases on a custom schema. All of this can be done using notepad.
A possible solution (that i've heard of but never tried):
a) Create your feature folder, and 2 schema files
b) Get a copy of a basic list schema, engineer it to match your requirements.
c) At the bottom of the schema, you can specify which aspx page is called when i) editing ii) viewing the list. Look at the default out of the box page that is usually referred to, make a copy (customblabla.aspx) and point your list schema to that file (obviously store it along with the out of the box aspx file.
Since you have control over this aspx file, you may able to tweak it do exactly what you want.
Sorry if this doesn't work...
Whenever source control in Lotus Notes development is discussed, it is said that an export-import cycle of DXL data doesn't give you the same design as you started with - thus any system relying on DXL will fail.
I have no reason to doubt this, since the DXL format seems to be a moving target and constantly a step behind what the Domino Designer can express, but:
Does anybody have a specific example of what DXL cannot express?
You can use DXL for Source Control right now if you don't want to actually edit anything out side of Domino Designer. Do this by exporting and importing elements as raw NoteFormat.
For DXL in a format that you can mess about with outside of DD you can trip up in quite a few places. I've not done anything too aggressive with DXL, so others might be able to give you better specifics. Quite a few are discussed here
The openntf project Design Catalog can be used for version control. www.openntf.org/projects/pmt.nsf/ProjectLookup/DesignCatalog
At lotusphere the lotus911 people mentioned they used the Design Catalog in combination with Trigger Happy. www.openntf.org/projects/pmt.nsf/ProjectLookup/Trigger%20Happy
I know there was an issue with Web Service script code not being exported in DXL. I'm sure that's only one of many. IBM has stated they have a goal of "someday" making DXL design exports 100% "round-trippable", but even with 8.5 are not there yet. There is a good discussion here, with postings by developers of design elements which do not export in full fidelity.
We had a need for a document management solution and were hoping SharePoint 2007 would satisfy our needs. We felt our needs were relatively simple. We needed to manage versioning, have searching capabilities, and having an approval workflow.
SharePoint handled these three aspects great out of the box.
However, we also require that the footer on the Office 2007 (Word, Excel, and PowerPoint) documents reflect the document version, last person to modify, and last modification date. These things can be done with office automation, but we have yet to find a complete solution.
We first tried to do it on the checking-in and checked-in events and followed this path for a while, however, the complication we ran into was after we made the changes to the document we had to no way of preventing the save from updating the version number. This resulted in something similar to this:
Document checked-in – the document version should be v0.1 however it is v0.2 because we save the document after the footer is replaced. If we look in the document history we there are 2 separate versions v0.1 does not have the footer v0.2 has the footer but it says v0.1 as that is the version the document was when it was replaced.
This is an unacceptable solution for us as we want the process to be completely handled on the user side so they would have full control to revert back to a version where the footer would be incorrect and not contain the correct data. When we attempted to create a custom approval/check-in workflow we found that the same problem was present. The footer is necessary so that hard-copies can be traced back to their electronic counterpart.
Another solution that was proposed to us was to build plugins for office that would handle the replacement of the footer. This is inadequate for our needs as it requires a client side deployment of our plugins which is undesirable by our clients. What we are looking for is a clean solution to this problem.
Here is a blog post which seem to be exactly the solution of your problem.
Basically they create a custom field in the document library and use event receivers to keep the current version of the document in this field.
The "trick" is that on the client side this custom field shows up as a property of the document the value of which you can easily embed into the document's contents.
I'm not sure why changing the field won't increase the version of the document, but I guess it is because you're only changing metadata, not the actual document.
They do use a little VBA script which runs on the client side, but it doesn't require any client side deployment as it is downloaded with the document. However I'm not sure if any security settings changes on the client side may be needed to allow the script to run.
Does this information need to be in the footer? A lot of the information is available within the Office 2007 application. If you click on the round button in the upper left, and select "Server", you can view the version history, a lot of the other properties are available by clicking the round button and opening the "Prepare" menu, and selecting Properties.
If this information must be displayed in the document footer I would investigate creating a custom Information Management Policy. This may be a good place to start.