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
Related
I want to know some way to extract the entire script from all design elements, forms, agents, views etc. I know that in MS .NET we use reflection to get the entire code, classes, functions, properties, everything. I wonder if this is also possible using lotus script or any third party tool. In fact, my basic requirements is to search for anything in the entire script in the Lotus Designer using Ctrl+F but that doesn't help, whereas in Visual Studio.NET one can easily search the project or even the entire solution for the specific keyword.
Thanks,
baburman
You can search for every string in database's code in Domino Designer at menu entry
Search / File...
If you still need to export all LotusScript code of a database,
execute menu File / Application / Design Synopsis... or
export database design as DXL
To remove the stale object issue(ie..when we run the test script for multiple input,it fails for the second iteration as the object is not cleared at the end of each run)in my script, I have added always search configuration in the designer file. After this my script runs successfully on multiple inputs, but if there is a need to add some objects newly to the same designer file then my designer file will be regenerated and the Always search configuration changes will be lost.
Is there any way to retain the always search configuration remain in the designer file ever even when the designer file is regenerated?
When you generate a UI map there are actually two files that come with it. Firstly, as you've discovered, there's a generated file with all the ugly code that's generated by the coded UI test builder. Of course, making any changes to this outside of the code will regenerate the file. The second file is a partial class that accompanies the generated designer class. This file does NOT get regenerated but as a partial contains all the same object references and properties as the designer file (it just looks empty). You can reference the control you want to add this property to here and it will not be regenerated.
The other alternative to this, albeit probably not a good idea, is to put
Playback.PlaybackSettings.AlwaysSearchControls = true
inside of your test method/class initialize/test initialize. This will force the test(s) to always search for each and every control. As you might imagine, this can have a significant performance impact though when you're dealing with large UI maps or particularly long test methods.
You might also set the control object's search configuration to always search. Keep in mind that this will do searching for this control and all of it's children so I would not advise putting it on a parent with several children, such as the document.
aControl.SearchConfigurations.Add(SearchConfiguration.AlwaysSearch);
I have noticed that lately our xpages application build/compilation time has gone drastically up. It can even take almost whole minute to clean application.
It is quite complex app with some controls (custom controls and java controls) and a lot of legacy code (js, ls, java), but similar app build in pure ecplise with the same amout of java code (which is the only part of this app that changes) cleans in less than 3 seconds ...
I have done a bit of research with rcp debug console and noticed that while cleaning there is some insane traffic that sums to 15000 transactions (and this database has only like 300 design elements that contains code at all!)
The log looks like this repeated over and over again:
...
[1240:0007-03E0] (13586-124 [14561]) OPEN_NOTE(REPC12579BB:0033C2FE-NT00003052,00400000): 0 ms. [48+17446=17494]
[1240:0007-03E0] (13587-124 [14562]) OPEN_NOTE(REPC12579BB:0033C2FE-NT00006C12,00400000): 1 ms. [48+32118=32166]
So my question is:
Does this mean that xpages builder is really badly written or maybe I do not know something?
Are you doing Project - Build or Project - Build All. If the latter and you have multiple NSFs open, then the build will run for all apps. You can close the apps in Package Explorer.
When you say there are 300 design elements, is that the number you see in the Applications Navigator? Bear in mind that's just a drop in the ocean of the actual files being built. Package Explorer will show there are additional Java and xsp-config files for each XPage and Custom Control. These are the Java classes compiled down from the XML markup you see in the XPages and Custom Control design elements. But this is not all that gets built. The server or local database cannot run .java files. It needs to run .class files compiled for the relevant platform. In addition, there are other .class files that need incorporating into the application at compile time, which can be seen by selecting Project - Properties in the Package Explorer view. If you have localization, there are still more files for each language for each XPage / Custom Control. And of course there are files like xsp.properties, an activator .java file and .class file.
The XPage builder may seem badly written because these files need creating. But it is actually very clever, because we don't need to write Java and we don't need to define all the relevant Java files the application is dependent on. We don't need to create a new XSPInput or whatever the Java classes are for the various controls. We can just drag and drop, set the properties from pretty panels which give us drop-downs or Boolean selectors etc. Without those the build time for the app after each save would be quicker, but the development time would be slower.
Its appears after all that there is a solution to build time problem - its the new Domino Designer 9. After upgrading to public beta version the build times dropped drastically (to just few seconds)!
**I am using the following code,**
var db=session.getCurrentDatabase()
var nc:NotesNoteCollection=db.createNoteCollection(true);
nc.selectAllDesignElements(true);
nc.buildCollection()
var filename = "d:\\dxl\\xpDXL.dxl";
var stream:NotesStream=session.createStream()
if (stream.open(filename)) {
stream.truncate(); // Any existing file is erased
var exporter:NotesDxlExporter = session.createDxlExporter();
stream.writeText(exporter.exportDxl(db))
}
** It is not exporting the designelements. But in DXL, It has the documentcollections.**
You are creating a NotesNoteCollection called nc but you end up exporting db. So change stream.writeText(exporter.exportDxl(db)) to:
stream.writeText(exporter.exportDxl(nc))
The XPages design elements in DXL are a headache to use. You are better off using the import/export plug-in from OpenNTF. It uses the Eclipse VFS to go after data in native format. So images are images, forms are DXL and XPages are their source. The plug-in contains the source code, so you can see how it is done.
The other option is to link a NSF to an onDisk project (the step necessary for version control) and just look inside the directory.
XPages design elements are a little problematic if you want to deal with them outside of designer: if you inject the source somewhere else you lack the compiled Java. If you are looking at documentation or variation management Designer and VFS (Virtual File System, Java Interface IResource) is our best bet
Maybe this is an security issue: You need at least designer access to your database to get design elements in a DXL export via XPage.
Even public access elements are not exported.
Hope this helps
Sven
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.