Search
Categories

Entries in SNTT (7)

Thursday
11Feb2010

Complete Turnkey NSF to Transform DXL into XPage Syntax

I posted an entry earlier this week on an update to the stylesheet I created and demonstrated at Lotusphere on how to transform Domino Form, Sub-Form and Shared Fields DXL into XPage syntax that could be copied and pasted directly into the XPages source tab in the Domino Designer client.

I had updated it to include the processing of Sub-Forms and Shared Fields.  The problem was that it placed the fields from the sub-forms and shared fields at the bottom of the XPage instead of in-line where the sub-forms and shared fields appeared in the original Domino Form design.  Well I'm happy to announce two things.

  1. I have updated the Stylesheet so that it processes Sub-Forms and Shared Fields In-Line.
  2. I created a compete turnkey Notes based application that allows developers to complete the transformations and save the results.

In updating the style sheet I was not pleased with the procedure for having to select the design elements from the dialog box in the designer client.  You couldn't tell from one selection to the next what you had selected and the results were not saved, but displayed in the browser.

In the turnkey Notes application I have made available on my download site today I have created a Form that allows developers to choose an application from their local system or a server, select the Forms, Sub-Forms and Shared Fields to be transformed and simply click an action in the action bar to perform the transformation and save the results in a document in the application.

Everything is included in the application.  Nothing else needs to be downloaded.

The individual stylesheet is available for download as well if you don't want to download the complete application.

Here is a summary of the new steps.

You will need an 8.5 or 8.5.1 system.

Download the application from my website to your local data directory and sign it with your ID

Open the application and click on the "Create New Exporter" action in the action bar.

 

This will load the following form where you can select the design elements to be included in the transformation.  The ConvertForm stylesheet is currently the only one included but this design allows for any number of stylesheets to be added and used.  Once all the elements are selected click on the "Run DXL Transformation" action in the action bar.

 

This will transfrom the selected elements and save them in a docment in the "Transformed XPage Results View"

This document can be opened and the XPage syntax copied to the clipboard using the button in the form.

 

Then open an XPage in the Designer client and replace the existing XPage code on the source tab with the code from the clipboard.

And thats it !!

I have implemented this solution so if there are additional stylesheets I (or you) create in the future they can simply be added as an additional stylesheet to choose from in the stylesheets view.

As always I appreciate any feedback ya'll might have on additions and improvements.

Again the complete turnkey application can be downloaded from here.

Thanks !!!

Wednesday
04Nov2009

New 8.5.1 Design Feature Cleans Up XPage Design When Using Custom Controls

If you have done any XPage development at all you know the power of using custom controls in your XPage design.  One issue though is if you are using many custom controls on an XPage it is difficult to tell where the XPage design elements start/end and the Custom Control elements start/end.

Version 8.5.1 introduced a new design element that slipped under the radar, but I have found very useful in upgrading my XPage application designs.

This is the new Design Definition property when creating Custom Controls.

As an example look at the design of the following XPage in the XPage design editor.

 

This is an XPage that is made up of 5 Custom Controls.

  • A Header
  • Name Fields
  • Address Fields
  • Buttons
  • Footer

Just looking at the design does not tell developers that the elements are Custom Controls.  Plus if this was a large input design, with a big graphics header, designer screen real estate could become a premium.

So what if you could just indicate in the XPage design that there was a Custom Control included without displaying the Custom Control contents?

This is what the new Design Definition Custom Contorl property brings to the table.

To use this new property edit the Custom Control in an 8.5.1 Designer client.  In the Properties view of the Custom Control click on the new Design Definition tab.

This opens an editor that prompts you to "Enter custom XSP markup:"

The XSP markup that is entered in this dialog will be displayed in the XPage design interface instead of the defined elements of the Custom Control.

So here in the Header custom control instead of displaying the company name with the large font I simply want to indicate that this is now a place holder for my Header custom control.

I input the following XSP markup in the Design Definition property

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">


<xp:panel>Header Custom Control</xp:panel>

</xp:view>

The code has to be valid XSP markup so it starts with the xml declaration tab and the XSP view tag.

The only other markup added is the XSP panel control with text in between the tags that will describe the functionality of the Custom Control.  Now when this custom control is added to an XPage design instead of seeing all of the Custom Control elements designers will only see the panel with the added text.

Tip:  An easy way to make sure you get the correct markup is to add the control to be used to the design view, then switch to the Source view and cut/paste the correct syntax.

The completed Custom Control looks like the following.

When looking at an XPage design that includes the Custom Control it now looks like the following.

This allows developers to know that there is a custom control there but without taking up a lot of design real estate.

If the same technique was added to the other Custom Controls that make up this XPage design, it would look like the following in the XPage designer

   

Each of the Custom Controls can be double clicked upon to launch the Custom Control editor to change the contents of the Custom Control.

Nothing changes about the features and functionality of the added Custom Control, all of it properties are still available in the XPage design, it simply un-clutters the design interface.  There is no change in functionality when the XPage is rendered in the Notes or Browser client

You can use any valid XSP design element in the Design Definition property of the Custom Control but as you can see in the following graphic, the Panel control provides a nice placeholder to be displayed in the XPage designer.

You do not have to implement this feature in every custom control added to the page, they can be mixed and matched as the developer requires.

An excellent resource to see how this new feature is implemented is the 8.5.1 Discussion Template.

A special thanks to Steve Castledine for helping me understand this new feature. 

The example applciation that I use here can be downloaded from my website here, but the Discussion Template is a better example once you understand how this new feature is being used.

Thursday
29Oct2009

XPages Using Domino Designer Course Updated for 8.5.1

The distance learning course from TLCC "Developing XPages Using Domino Designer 8.5" has been updated to include the features and functionality available in version 8.5.1.

Some of the additional topics added are;

          o Developing XPages for use in the Notes client
          o The changes in the XPages editor in 8.5.1
          o Compiling and signing XPages
          o The new Hidden Input Control
          o Changes to the View Control
          o Changes to Custom Controls
          o Using XPages in Composite Applications

The course is designed such that it can still be taken by developers using 8.5.0 OR 8.5.1 as the updated material is in it's own module and referenced in the core material.  All existing students are entitled to this update.

A complete course description and details can be found here.

Wednesday
23Sep2009

Creating a Dynamic HTML Table on an XPage

At first glance this seems like an exercise in can it be done versus should it be done.  So lets review our options for "dynamic" output of data on an XPage.  There are two controls you can use

  • View Control
  • Data Table Control

 Both of these controls use a repeat control to display the contents of a data source.  Using the View control for view data is a no brainer, but what about other data?  In one of my previous articles I demonstrated how to use XML as a data source and I used a Data Table control for the output.  One of my issues with using the data table control is that in version 8.5.0 there is no easy way to add column headers to the Data Table so your data is just listed there without the benefit of labels and sometimes formatting the elements of the data table can be challenging, for example you can not select a table row for formatting only the columns.

So wanting to have some more control I decided to see if I could combine an HTML Table with the Repeat control so that I could have a dynamic HTML table that could be used for view content or XML content or down the road "other" data sources.

The tricky part was that I only wanted to repeat the table row and there was no way to do that in the UI.  So I used the following steps to combined the two.

Create a new or modify an existing XPage.

Add a Table control to the XPage with at least two rows and however many columns you need to display your data.  The first table row will be used for the column headers and the second table row will be used to hold the repeated elements.

Next Add a Repeat control that uses the included Domino View as a Data source and sets a value for the collection name that we can use with the repeat control.

 

 Next add a computed field to the repeat control to repeat the view data for the first column.  For the value of the computed field use the variable name set in the repeat control which will allow you to choose one of the columns from the view source.  At this point the XPage Design mode will look like the following.

 

Now we need to combine the two elements so that the table row is repeated for every row in the view.

Switch from the Design mode to the Source mode.  The code should look like the following.

Here is the tricky part.  You need to edit the source code to surround the table row element with the repeat control and pace the computed field inside of the table data element.

The second table row is what we want to repeat so I manually edit the source code so it looks like the following.

The repeat control now surrounds the table row element to be repeated and the computed field resides in the table data element.

This is what it will look like in Design mode.

Now you can add the table header values and the additional computed fields to finish out the design so it looks like the following.

When it's rendered in the browser it will look like the following

 

A pager control can be added to page through multiple records.

The Pros of this technique are

You now have more control over the formatting and layout of the table

Works with view data or XML data

The only con is that once you modify the source code then the Repeat Control no longer is editable in the Properties tab of the designer UI and changes will need to be made via the source view.

I'm going to be using this technique as the basis of my next two articles so I wanted to lay it all out here for you.

As always the complete source code and example application can be downloaded from my website here

Just click on the downloads link and download the XPages Playground application

 

Thursday
06Aug2009

Using XML as an XPage Data Source

In my previous article I demonstrated how to take an XML stream (in that case an RSS feed) and transform it on the fly using XSLT. This same technique can be used to display Domino data as well.

So the first question is why would we use an Domino XML Data Source instead of a standard view design? I'm glad you asked. A couple of reasons.

Views can be limited to the amount of data that they display in the alloted columns. Using Java and LotusScript developers can write agents that returned well formed XML that can be consumed by both Domino and non-Domino systems.

There is currently an issue with XPages consuming web services when the XPage and the Web Service is hosted on the same Domino Server. If hosting the Web Service and the XPage on separate servers is not an option, then the Web Service logic could be coded as an agent that returns well formed XML that could then be consumed by any system, Domino and non-Domino alike.

Back to the issue at hand. In this article I will demonstrate two ways to display XML data as a data source on an XPage.

  • Via XSLT
  • Via an XPage Data Table

 

Transforming XML on an XPage via XSLT

This first technique is identical to this previous article on the XPages blog, except that is uses a Domino Agent to supply the XML instead of an RSS feed. So that it is easy for you to duplicate the examples I will be providing I'm going to use names.nsf (local or server) as the data source. This way you can test the example code with "real" data at your house

The following image demonstrates the output of reading an XML data stream, transforming it on the fly with XSLT and displaying the results (there is nothing wrong with your eyes, I just blurred the details as my mom didn't want her email published). The name of the XPage is XPageWithTransfomedDominoXML.xsp in the XML Playground application you can download from here.

The output is produced by running an agent called javanames.xml and applying an XSLT called names.xsl

The Pros of this solution are

  • Works well with small data sets
  • Results are dynamic
  • All document data is available, not just the view data


The Cons to this solution are

  • Not easy to apply paging
  • All formatting has to be done via CSS added to the transformed output (not a huge con, if you use css classes)
  • Must know how to write an XSLT transformation stylesheet.


If that last bullet point applys to you then your question is "Paul, can't I produce these same results via standard XPage controls?" and the answer to the question is yes you can !

Displaying XML data on an XPage using a Data Table control

The following image demonstrates the output of reading an XML data stream, parsing it with the Java 6 XML parser and displaying the results in a standard XPage Data Table control. The name of the XPage is XPageWithXMLDataSource.xsp in the XML Playground application you can download from here.

This technique is accomplished using the following procedure

  • Parse the XML and store it to a session scoped variable in the XPages afterPageLoad event
  • Add a Data Table control to the XPage
  • Add columns to the Data Table for each element of the XML to be displayed
  • Add computed field controls to the Data Table columns to display the parsed XML
  • Add a pager control to the Data Table for paging purposes


The XPage in design mode looks like the following;

In the XPages afterPageLoad event add the following server side JavaScript to read the XML stream and parse it into an XML document to be stored in the session variable.

//Create the XML Document
var parsedxml:org.w3c.dom.Document = null;


//Create the Parser Factory and document builder
var domfactory:javax.xml.parsers.DocumentBuilderFactory = javax.xml.parsers.DocumentBuilderFactory.newInstance();
var xmldocument:javax.xml.parsers.DocumentBuilder = domfactory.newDocumentBuilder();


//Read the XML from the Domino Agent
var parsedxml = xmldocument.parse("http://localhost/dotoxp.nsf/javanames.xml");


//Store the parsed XML to a session scope variable.
sessionScope.put("names",parsedxml);

Add a Data Table control to the XPage with the following properties.  Notice the "Index name:" variable as it will play an important part in the column formulas.

The Iteration formula (determines how many elements the data table displays) the following Server Side Java Script is used to read the parsed XML variable, read the fullname node list and return the elements of that node list.

 

// Read the parsed XML from the Session scope variable

var domdoc:DOMDocument = sessionScope.get("names");

//Create a node list of all of the fullName elements from the XML Stream

var dtnames:DOMNodeList = domdoc.getElementsByTagName("fullname");

// Return the entire node list

return dtnames;

 

The Data Table control includes a repeat control that repeats the rows for every element of the data source.  Add columns to the Data Table control for each element of the XML stream to be displayed

 In each column add a Computed Field control using the following Server Side JavaScript.  This script will read the parsed XML session scope variable read the specific XML element by tag name, get the current node based upon the row index and then display the value in the column.  This will be repeated for every element in the XML data source.

 

Pros of this technique

  • Any XML data source that can be read by URL (even non-Domino data sources) can now be used as data sources on an XPage
  • Any of the XML "nodes" can be displayed (all or one)
  • Pager control can be added to the Data Table Control to "page" through the data
  • CSS formatting can be applied to XPage controls via the designer UI

Cons of this technique

  • Currently the data table does not display column headers

 

So now you can start using any accessible XML data stream in you XPage development. 

Don't forget you can download the complete XML Playground application with the included XPage solutions here.

 

Friday
31Jul2009

Displaying Transformed XML on an XPage via XSLT

As I mentioned in my first article I have been a huge fan of XML and related technologies since XML first came on the scene. So any time I have an opportunity to incorporate XML into my development and it meets a particular need, then I get pretty excited.

So in searching all of the excellent resources on XPages I hadn't yet come across a technique for transforming XML on the fly with an XSLT stylesheet and displaying the results in an XPage. This technique will allow you to use any XML data source (via URL) and transform it with a stylesheet stored in the Domino application and display the results anywhere on your XPage. So a picture being worth a thousand words the result would resemble the following.

 

 

In this particular case I am reading the XPages Blog RSS feed and transforming it into HTML links via XSLT and then rendering the results in the XPage inside of a Panel control.

So here is the walk through.

Design Elements

  • URL of XML (In this case it can be any web sites RSS feed URL)
  • URL of XSLT (Stylesheet included in the sample application)
  • XPage with Computed Field using Server Side JavaScript

Create a new XPage or edit an existing page. Add a computed field to the page. My design looks like the following

 

On the Value tab of the Computed Field controls Properties tab, change the Bind data using to JavaScript. Click on the Open Script Dialog icon to open the Script editor to add the Server Side JavaScript code.

 The following is the Server Side JavaScript code that reads the XML RSS Feed, reads the XSLT stylesheet, creates the result object, performs the transformation and renders the results onto the XPage. 

var xmlSource:javax.xml.transform.Source = javax.xml.transform.stream.StreamSource("http://xpagesblog.com/xpages-blog/rss.xml" );

var xsltSource:javax.xml.transform.Source = javax.xml.transform.stream.StreamSource("http://localhost/XPagePlay.nsf/newsstyle.xsl" );

var result:javax.xml.transform.Result = javax.xml.transform.stream.StreamResult(facesContext

.getResponseWriter());

// create an instance of TransformerFactory

var 

transFact:javax.xml.transform.TransformerFactory = javax.xml.transform.TransformerFactory.newInstance( );

var 

trans:javax.xml.transform.Transformer = transFact.newTransformer(xsltSource);

//return result;

trans.transform(xmlSource, result);

 

 Thats all there is to it.

This technique takes advantage of the fact the during XPage development we have complete access to the entire Java 6 JDK, which includes the XML parsers and transformation engine.

The first line of code reads the RSS XML.  Note that this could be ANY xml.  This example is using RSS because it is readily available for demonstration purposes, but this could be any XML from an accessible web site including a Java or Lotus Script agent on a Domino Server.

The second line of code gets the XSLT stylesheet. Now the Style sheet is specific to the XML source that is being transformed.  In this case the referenced stylesheet will ONLY transform RSS feeds.  But you could write XSLT stylesheets to transform whatever XML you are consuming.

The third line of code creates the transformed results and sets the output to the XPages responseWriter.

Next we create an instance of the transformation factory.

Finally the transformation is performed with the results being written to the XPage.

Using this technique developers can include Domino and non-Domino data sources represented as XML and transformed on the fly to be rendered in the XPage.

I have included an application (XPages Playground) with the complete solution on my web site

In my next post I will show how to use raw XML as a data source and output the results to the XPage.

 

Thursday
23Jul2009

Transforming Domino Forms into XPages via XSLT

I have been working with XML/XSLT for a long time and it is one of my favorite technologies to work with.  When developing XPages from existing form designs, or even ones I created to be the data source for a new XPage, there were a couple of things I noticed.

  1. The fields are always added in alphabetical order versus the order they appear on the Domino Form design.
  2. You have to change the control type to match the one on the Domino form when you drag the fields on the XPage from the data palette or they are all added as Edit Box controls
  3. Computed fields are not brought across at all.
  4. There was no way to create Radio or Checkbox keyword fields dynamically
  5. Keyword field values were not brought across at all

So, I found that every time I was adding fields to an XPage I had to

  1. Reorder the fields and Lables in the Table
  2. Add the Computed fields
  3. Change the controls that should be Radio Button and CheckBox controls manually
  4. Populate the choices for the selection type controls.

Ok, so first off let me be clear.  These are NOT difficult or time consuming tasks.  But my theory was if I didn't have to do those things every time then I could concentrate on the development of the XPage logic and not what are mostly mundane tasks.

So here is the premise.  The Domino Form Design can be expressed as XML (DXL officially).  An XPage is nothing more than well formed XML (JSP/JSF syntax).  So why not simply use XSLT (That's already built into the designer client) to transform the Domino Forms DXL output to the XPage XML output on the fly.

So I wrote an XSLT (XML Stylesheet Trasformation) file that will perform the transformation.

One aspect that I like about this current solution is that the XSLT file is installed on the file system and only needs to be accessible by the Domino Designer client.  You then use the existing Tools menu in the Designer client to perform the transformation.  No .nsfs to install, no code to sign etc. 

The following walk through demonstrates how this will work.

Download the XSLT Style sheet from here

Copy it to your <notesInstall>/data/xsl directory

Open the Domino Designer Client

Open the Application that contains the Domino Form to be Transformed

Form the menu choose Tools | DXL Utilities | Transformer...

This will open the DXL Transformer Dialog.  Check one of the forms in the forms list on the left.  Select the "DominoDBDXLtoXPage.xsl" stylesheet from the list on the right(This is the file you downloaded and copied into the data/xsl directory).  Leave the Send output to defaulted to "Display".  Click the "OK" button.

 

This will open the transformed XPage in the Browser (But it will not be displayed as an XPage.  You will see the following in your browser.

 

Right click on the Web Page and choose to view the page source (which is the XPage xsp code)

Select all of the code (ctrl-A) and then copy the code to the clipboard.  Close the View Source window and the web browser window.

Back in the Domino Designer, create a new XPage in the same application that the original Domino Form was transformed from.

 

Switch to the "Source" view.  Delete the Existing Code

 

Paste in the code from the Clipboard.  Hit CTLR-SHIFT-F to format the code.

 

Switch to the Design view to see the controls in design view.

 

Preview the the XPage in your default browser to test the XPage.

The results of the transformation is that a document data source referencing the current application and the selected form are added to the XPage.  A Table is created with a Label created from the field name and a control with the same name and type as from the Domino Form.  Default values are brought across for editable fields.  If it is formula based it is brought across as JavaScript comments so the original logic is retained.

All Static keywords (both values and aliases) are brought across for all the selection type fields.

If there is a control you don't need then simply select the table row in the Outline view and delete it from the right click menu.  My experience has been it is easier to delete the controls I don't need than add the individual computed fields in manually.

It's not perfect and it does not duplicate all of the form logic 100% but gets a lot closer.  I figure the less time I spend editing the more time I have for development.  Work smarter not harder.

My disclaimer (there is always a disclaimer) is that it's still a work in progress.  I will eventually put a UI on it and create the XPage XML from a form where developers can choose what they want to include, change switches etc.  But for now it is a handy tool in my toolbox.  I hope it will help save some XPage developers some time.