XPages Design Refresh - xpages

I have a question regarding the design refresh/replace mechanism. Are XPages and Custom-Controls replicated?
In the Documentation they are not listed as component. However, in the confirmation dialog they are listed:
If not, how can I distribute XPages between different database?

Yes, XPages and Custom Controls are part of design refresh/replace mechanism. In general all design elements visible in Designer/Applications are part of it.
You are right, those design elements are not listed in documentation (neither in version 9) but should be.

Related

Notes : Is there any good tool to export design elements, especially for XPages and the custom control to write the design spec document?

I created lots of XPages and the custom control in new application. Then, I need to write the design spec documents. Is there any good to help it? "Design synopsis" menu in Notes seems not to export XPages design information.
When you connect XPages to an on disk project (ODP - see the help for that), you get a directory with design elements. XPages and controls are XML files, so you could use xslt to report on them.
Hope this helps
If your business logic is in Java, you can generate a Javadoc of the classes https://www.intec.co.uk/generating-javadocs-for-xpages-applications/.

XPages: where to get detailed documentation

This is not a technical question, but rather an inquiry on how to get better information regarding the huge numbr of parameters and properties of the various controls you can put in an XPage.
A concrete example:
I have a button which had a property save=true in its event Handler. I added some code in the postSave event, so a lotuscript angent could do some processing, and I started having save conflicts. It took a while but I managed to figure out that the save=true in the event Handler was causing the issue.
I like to know my options, so I wanted to look at what exactly that property ws doing (although the name kinds of give it), but that's when it hit me: where do I look for that kind of information?
Is there a site somewhere that lists all properties we can add and a description of what they are doing?
Maybe my Google skills are not the best, but I couldn't find anything yet...
The three IBM Press XPages books (Mastering XPages 2nd Edition, XPages Portable Command Guide and XPages Extension Library) are key to understanding the implications of the properties. There are the equivalent of Javadocs for controls (here's the link for the XPages Extension Library one), but they're not intended to go into the kind of depth to identify the problem you hit.
These might be useful:
http://xpageswiki.com/
http://www-01.ibm.com/support/knowledgecenter/SSVRGU_9.0.1/com.ibm.designer.domino.ui.doc/wpd_controls_cref.html
Howard

Is there a clever way how to share custom controls among Xpages applications?

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.

How can you (partly) hide the design of your XPages application?

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.

SPGridView - User selecting the columns

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).

Resources