More thoughts as I sat in XPage kindergarten today waiting for the bell to go.....
The Good: Diamonds Are A True Gem - Yesterday I spoke about the VERY VERY large number of components that can go into an Xpage design. It turns out that many of these attributes have little diamond icons next to them. In fact I would guess there are probably more diamonds contained in the XPage UI than there are in all the South African diamond mines combined. The diamond icon is used to denote each place in which a value can be provided either as a literal value or computed. So what this means is that it is now possible to dynamically set almost ANY attribute on an XPage design at run time. Ever want to set the width of a column or the column header label dynamically? Well now you can. Every want to dynamically disable (or even just disable) an edit control based upon another field value, well now you can. Ever want to change the color of text based upon the values on a form, well now you can. Did you ever wish the hide-when formula was a display-when formulae, well now it is. The formula language use to control these values is SSJS so you can make these formulae as complicated as you wish/need. If you are like me and you go out of your way to build a design element once in a way that allows it to be consumed by other other applications without the need to change any code then these diamonds are going to be a big help. Equally, if you like what Notes provides out of the box but just need to change one or two little things then diamonds can also be a big help.
The Bad: What Goes On In XPages Stays In XPages - A lot of the new features found in XPages such as diamonds could be of almost as much value in non-Xpage design elements. There is no sign at this time that any of these capabilities are likely to be added to existing design elements such as Pages, Forms, and Views. These may come at a later stage, but I would not be holding my breathe waiting. Notes 9.0 should provide a good insight. Watch to see the extend to which non X-Page design elements get enhanced. Idea Jam has hundreds of ideas about how. If they don't make it into this release they may never....
Random Thought: Does anyone know the history of XPages and where this design element came from? It strikes me that this design element has been developed in too great a level of detail to be a mere 1.0 release.
|
XPages - The Good, The Bad and the UGLY - VII
|
Slowly but surely this XPage stuff is starting to make sense. A far cry from where I was this time last week...
The Good: This Thing Is BIG I am in total awe in just how much stuff is in this XPage thing (including Custom Controls & Themes). Its so HUGE that my tiny little brain still has no idea how to even conceptualize much of the stuff that is in there. Every time I open a door its like it opens into hallway with a whole bunch of more doors (a bit like a scene from The Matrix). Take for example Custom Controls I spoke about yesterday. Custom Control properties has ELEVEN tabs each with their own sets of properties and values. One of these is the Property Definition tab that is used to define the properties. Once you have properties defined you are then provided with a property tree allowing properties and groups (no idea what they are) in a hierarchical relationship. For each property there is then another panel with THREE MORE tabs that then allow you to define attributes for the property. Amongst the things you can define for a property is the data type. All the basic ones are there such as string, int, boolean, and double. But then you can pass parameters using a whole swag of complex types (ACL, ACLEntry, Action Listener, DataSource, LinkResource....), Converters, Data Sources, Simple Actions, and Validators. Dont ask.... I haven't a clue about half this stuff.. So if that is not enough you can also then chose from a large list of editors (think controls) that can be used to edit the property value when it is included in another custom control or XPage. I imagine I could get lost in just this one little area for weeks. So if you're the type of developer that likes feature rich design elements I would estimate Xpages alone has more in it than all the other Notes design elements combined.
The Bad: This Thing Is BIG Just as the sheer magnitude of an XPage definition can be seen as a huge plus, it can equally be viewed by others as a minus. I can see a lot of Notes developers (like me) being intimidated. At this stage I expect it will take months just to get a basic working knowledge of this beast and perhaps years to truly master (if ever). Notes Developers who come as far as Forms, View & @Formulas are unlikely to make a quick jump into XPages (if at all). I suspect even a lot of Full-time Note developers who use LotusScript will be intimidated and bawk at taking this on. Training, documentation, and access to mentors will all be a big help to overcome these hurdles. It's perhaps a good thing you can still build your apps the same you always have in the past as I suspect there may be more than a few who will.
Random Thoughts: A lot of my thinking is still stuck on this programming language thing. I promise I will move on eventually but I think it important to think through before heading off in a particular direction. Ready... Fire.... Aim.... I posted an idea on idea jam that so far has received almost as many comments as it has votes. There are some great comments in there too. The views vary considerably, which is what I expected. It is early days but I am very curious about how Xpages will pan out. I have said for a long time that 8.5.1 could very well be one of the most pivotal releases of Notes yet. And this may well still prove to be the case (even more so than 9.0).
I don't understand the technology behind how XPages is implemented but, it seems IBM may have had the choice to use LotusScript as its server sided programming language for XPages. Instead it chose to use a programing language not found in Notes development before (SSJS). Me thinks they have a plan. It could be that this is being done to allow IBM to better integrate its entire product line. Yes it may be that IBM unofficially retired LS after Notes 6. But then I think IBM tried to retire NSF for DB2 and even the entire Notes product for IBM Workplace around this time too. But we didn't all get the memo, proving it is not always about what IBM wants but also about what market forces allow. I can see a lot of smart people doing some really cool stuff with Xpages. But how many will stay behind, that is the question? The people who read this and other Notes blogs, use Idea Jam etc are probably the ones most likely to make the jump. Perhaps two forms of application development will evolve both within the same NSF container. If that is the case it will be a shame if there are not migration tools available to migrate forms, views, agents etc into XPages. There is a huge opportunity there for someone....
As for me.... I'm inclined to think I will be making the jump and hopfeully fully emersing myself in this new XPage technology. Assuming I am allowed -- I doubt I could stay in the old world, especially if IBM was doing little to enhance it. If only those Lotus911 guys would slow down so I can catch up.
|
XPages - The Good, The Bad and the UGLY - VI
|
Week 2 of xpages kindergarten has started on a much sounder footing than week 1. Still finding heaps of cool things and a few not so cool things....
The Good - Custom Controls: The coolest thing I have found so far about xpages is in 8.5.1 so we will have to wait. The 2nd coolest thing I have found so far is custom controls. These things are absolutely awesome. Think of the like subforms on steroids. They are way cooler than subforms for the following key reasons:-
- An xpage can provide the functionality of a form, view, and page. So in some ways a custom control is also like hiving a "subview" or "subpage.", a way to define a common set of visual elements that can be included on a group or all design elements in your application. Do you have a set of actions you would like to make available on all (or some) of your views then think custom control.
- Unlike subforms, it is possible to include the same custom control more than once inside the one xpage or custom control. This is a characteristic that is especially useful when using the repeater control (another day).
- The really cool thing about custom controls is that you can define parameters that are passed from the parent object (xpage or custom control ). This allows the custom control to modify its behavior based upon information passed in from above. Think now about having a super-control in place of a number of less powerful controls. Just like widgets, plug-ins etc, xpage developers are going to be building and sharing all manner of custom controls that will allow generic functionality to implemented with a simple drag/drop.
I expoect the use of custom controls will very greatly. Just like LotusScript and subforms today we will have unstructured developers who do not use them at all and we will have structured developers (e.g. OOP) that will create xpages that consist almost entirely of custom controls whose behavior is controlled via parameters.
The Bad: Screen Hog: Xpages are a real screen hog when they are loaded in the new DDE. There is so much information contained on an Xpage that IBM gives us a total of nine panels that we can use to manage their design. On the left we have the traditional bookmarks for databases and design elements. Below that is a new outline panel. In the middle we have the xpage code itself which is shown in design and source format. below this are three panels showing Properties, Events, and Problems (another day). To the right we have our controls toolbox and a Data Source panel. Even then the properties box often tries to display more information than will fit in the space allocated so I find myself wanting to resize the window to avoid the need to scroll. This makes my xpage even smaller.
On a typical SXGA monitor (1280x1024) the amount of space left to show the xpage is probably less than 50% of the total space. On an XGA monitor (1024x768) it is even less. If you find yourself doing a lot of xpage design and you don't yet have a high resolution monitor I expect you will soon be demanding one. I went all the way and purchased a 30" wide-screen monitor at home. I can justify it to myself (and my wife) because it is a huge productivity aid when developing xpages in particular,
|
XPages - The Good, The Bad and the UGLY - V
|
It is still early days in my Xpages learning but one thing has already become very clear. Xpages development is crying out for a framework even more so than LotusScript. It is not yet clear to me how much of my time moving forward is going to be spent doing Xpages development, but the extend to which I do I just know a lot of my time is going to be consumed collecting code from all over the place and consolidating it and combining it with my own code in a way that will allow me to continue to do Rapid Application Development.
It is now clear to me that I need two separate framework. The existing one that is OOP LS based and will support all non XPage development and a separate one that will focus almost exclusively on Xpages and SSJS (and possbly Java and even LS at a later stage). My goal is to at least have a beta posted on OpenNTF sometime soo after 8.5.1 is released.
The current .Domino Framework proect is likely to be extended but will focus on non-XPages development. How much will depend on how much non-Xpages development gets done in the future.
I have now created a community on bleedyellow.com. Anyone who would like to get involved in any way is encourage to join this community (it is moderated but I have super low standards on membership -- If you drink beer or even if you write some form of Notes code your are a shoe in to be accepted). Contributions can include ideas, enhancement requests, code contributions, rolling up your sleeves and building the code, or just telling us what we are doing wrong.
|
New OpenNTF Project - xDomino Framework
|
.Domino Framework 1.0 has been released on OpenNTF under the Apache License (which basically means anyone can use the code for whatever they want). This project was thirteen years in the making. It contains a collection of tools, code, and information to assist Lotus Notes developers build Notes applications.
Resources:
.Domino Framework Project (Download)
.Domino Framework Wiki
.Domino Framewrok Web Site
.Domino Framework Blog
.Domino Framework Community
Points of Note:
- The framework is not an application template. It is a component library. Copy/paste the needed components from the template based upon your own application's needs. A separate application template will be release soon with core components likely to be used in building a new application.
- Application code is separated into a presentation layer and a business logic layer.
- The presentation layer is targeted at Notes 6.0+ and contains forms, views etc. to support generic functionality common to many Notes applications.
- The business logic layer consists of a collections of LotusScript libraries containing 100+ classes that can be used directly or extended by your own applications.
- The framework is specifically designed for Object Oriented Programmers but much of the code be adapted/used by procedural programmers.
- The framework has been designed to allow you or your organization to customize and/or extend.
- The focus of the framework has been Notes client development. There is some stuff there for Web development but not a whole lot.
- The framework is the basis for EVERY notes application I have created or significantly enhanced over the past two years. I estimate its use makes me almost twice as fast developing Notes applications.
What is the significance of a 1.0 release?
- A number of beta releases were made available as a way of testing the water as well as allow other Notes developers to make use of the code sooner.
- Like many 1.0 releases it is going to have issues. Much of the code has been tested in production applications. There are still parts that were started but never finished and/or fully tested. I have left this code there because it may still be of value to others. Over time I would like to think I will get the chance to finish these parts off in later releases.
- I no longer have the need to focus on Notes 6 development. All my Domino Designer clients are now either 8.5.0 or 8.5.1 (beta). I wanted to publish this initial release with code that would run on every version of Notes from 6.0+. I may never get a chance to go back and finish it.
Brief History
I started collecting code for .Domino Framework in 1996 when I first started doing LotusScript programming. Before that I had kept to forms, views, agents and @formulas (yeah I was one of those Notes developers!). I had a research and knowledge management background and quickly collected and stored lots of stuff to help me while I was learning. I soon had so many code samples, samples databases, and bookmarks to Web sites etc. it was getting hard to find specific code as I needed it. This was slowing me down. So I started to build a Notes database I called "Code Central" to hold all this stuff.
During the Dark days of Notes 7 and IBM Workplace I thought it was a smart career choice to move away from Notes. I was presented with a great chance managing a team of C# and .Net developers. This is where I learnt to understand and appreciate the power of OOP. I was particularly impressed with Microsoft's .Net Framework and how it took VB.Net (a language very much like LotusScipt) and took it a whole new level.
Two years ago I found myself back doing Notes development. IBM seemed to be interested in Notes again (yeah). Only now I was convinced OOP represented the future and I needed a framework to elevate LotusScript and my productivity. IBM didn't seem to be doing much with LotusScript (boo) So, for the past two years I have rewritten Code Central from the ground up as an OOP framework.
Contributions
My many inspirations for the .Domino Framework come from hundreds of people in the yellowverse that published code or ideas into the public domain. Unfortunately due to the way the code was developed I lost details about the original sources for a lot of the stuff I had collected. Sorry, I never intended to share this... I have since written almost every line of code in the framework myself to suit an OOP style and to ensure the general style and my own best practices are implemented. Where I can I have tried to identify sources of the original code or ideas upon which it was based. Please,please, please... if you see anything in the framework that you feel you may have played a role in at some time please let me know. It is not my intention to lay claim to anyone else's ideas and I will happily acknowledge your contribution. Even if I never saw your code I don't mind acknowledging your work.. As I have said, I believe I have painfully written each line of the code eventually implemented., but just in case, let me know.
I do want to acknowledge several people who did not participate directly in this project but have provided signifcant indirect contributions (in alphabetical order).
Ben Poole: Ben was kind enough to provide me with an early 1.2 beta of his OpenNTF DominiWki project. I have modified some of Ben's code to suit my own needs but the credit for all the code in the .Domino Framewok Wiki belongs to Ben and his great project. (Note to self: I need to share with Ben some of the changes I made).
Chris Blatnik is one of the Notes UI gurus. I have tried to follow his many ideas. Its not great but the .Domino Framework is distinctly less ugly than the original Code Store.
Damian Katz
did much of the early pioneering work on accessing design elements from
LotusScript. I studied this code carefully before building my own
solution.
Jake Howlett:
has been one of the largest contributors of code to the Notes community
via has codestore.net site. I have followed this site and blogs closely for
ideas and information on how to solve common Notes problems.
Julian Robichaux: I decided to replaced my own error logging solution with Julian's OpenNTF OpenLog project. In my early days I used Julains nsftools site a lot for examples of LotusScript code I could use. I have also incorporated Julian's LS2HTML applet as a developer tool within the .Domino Framework.
Nathan Freeman and the entire Lotus911 team have consistently developed pioneering work in the Notes arena and I have tried where I can to incorporate some of their ideas in the framework. Nathan, Tim, Kevin et al have read my stuff and frequently comment on my work and crazy ideas. Lotus911 also provide the bleedyellow blog site and Lotus Connections community I have been using for this project. Much appreciated guys.
Finally to all those I have not mentioned I would like to thank the entire yellowverse and your willingness to share code and provide comments and feedback to my own blog. These have all been a big help in improving my own limited understanding of Notes development. Even you Java guys!!. I still have a long way to go but I am hoping by publishing this framework I can provide something back to the community as a small thanks for the help I have received these past 13 years in making me a better Notes developer. There has been a lot of yellow blood spilt over this project... Please enjoy.
|
Domino Framework 1.0 Released
|
I don't normally plug my own ideas on ideajam, but this is one I would like to encourage notes developers in the yellowverse to cast a vote. As many of you know from reading my blog I am in the process of learning how to develop xpages. It is still early stages for 8.5, xpages ,and server sided Javascript but I am interested in getting and early indicator based upon your own experiences and insight as to whether or not xpages is likely to change Notes developer programming habits away from LotusScript towards Javascript. Away from forms, views, pages and outlines to xPages. IBM may or may not care but I am certainly interested. It will help me decide what I do next with my OpenNTF project .Domino Framework. Do I continue to focus on LotusScript, do I turn my attention exclusively to xPages and Javascript, or do I focus on both?
|
LotusScript v JavaScript
|
Week one completed.. What an amazing learning experience filled with many emotional highs and lows.....
The Good - Outline panel: In my last blog I talked about the drag/drop capabilities for editing Xpages. John Head made some excellent points in response about how he uses the Outline panel almost exclusively to rearrange the content of an XPage. I didn't even realize the outline allowed you to do that. But sure enough, you can even use drag/drop within the Outline to rearrange controls etc. I had already found the Outline to be useful as a way of quickly navigating between controls, so this makes the outline even more useful. There still seem to be some clunky things when using outline this way.
The Bad - Designer Stability: This may be just an issue with the configuration I am using (feedback wlecome). But I have certainly struggled with keeping both my Notes and Designer clients fully operational when doing extended design work with XPage components. I seem to have to restart my clients 3-4 times a day. I don't recall having these issues when I was editing other design elements. The good news is that the 8.5.1 (beta) clients seem to be more stable than 8.5.0 (at least when editing Xpages). What I also have found is that it is sometimes not too hard to make a change to an XPage that causes an error to occur on the HTTP server preventing my Xpage from displaying. Even when I try to undo the last lot of changes the Xpage will no longer display. This may just be me fumbling along, but I often found myself having to recreate my Xpage again from scratch as a way to get it to display again.
Random Thoughts:
After my first week of Xpages development the one things that strikes me more than anything is just how different XPages is from the rest of Notes development. I have drawn more from my experiences with ASP.Net development this week than at any other time whilst doing Notes development. Xpages do not appear to be able to incorporate components from existing Notes design elements . And the only design element I found so far that can consume an XPage is a frameset (see my last blog). Information can be imported from views and forms but Xpages is like a separate product within a product. The page lifecycle is completely different (and vastly superior). The programming language choices are distinctly different. No LotusScript or @Language but a new variation to Javascript that inherits some of LS and @. As Nathan T Freeman keeps pointing out to me, it is still an NSF and I get all the things like security, encryption, replication etc. But I do still wonder where this all may lead... The extent to which I adopt XPages will be dependent on three things:-
- The extent to which I can remain as productive when developing with XPages as standard Notes development. This is the key reason I like Notes and why I can earn more than the minimum wage... I can build applications so much faster than with non-Notes development which makes me look good - i.e. Notes makes me shine.
- The extent to which the Notes community adopts XPages. Without doubt Java is a superior programming language to LotusScript and yet it is not lost on me that in all the years since Java has been an option for Notes development so few Notes developers have adopted it. IBM have tried to push Notes developers to its vision of the future using product offerings such as Workplace, NSF2DB2 (the big thing in Notes 7), Websphere/Component Designer, Expediter etc. and there has not exactly been a stampede to adopt any of them. We all bleed yellow right! Even if I loved XPages to death (not quite there yet) and wanted to program using nothing else there would be little point to me doing so if everyone else I worked with didn't do much the same and/or each of my next few contracts were with clients that hadn't decided to make the jump.
- What my clients direct. Regardless of any of the above, if the people who pay me so I can put food on the table direct me to either use (or not use) Xpages I am probably going to do as I am directed. There is a very practical side to this debate!!!!
|
XPages - The Good, The Bad and the UGLY - IV
|
|
It came down to the wire but I managed to complete my first xpages project in the week I had allocated myself. The project was to take an application that include the use of the Java view applet and replace it with a more user friendly XPage view control. The complication was not how to display a view on an XPage, that took minutes (yes even for me!!!). The challenge was that when documents were selected in the view I needed to launch the first attachment into a frame to the right of the view.
I am sure someone will correct me, but I could not find any way of forcing an XPage to launch a designated URL into a specific area of the XPage (e.g. a panel). The only command I could find to launch a URL was facesContext.getExternalContext().redirect(url). No matter where I placed this command it seemed to replace the entire contents of the XPage with the URL. If the XPage was inserted inside another Xpage it would replace the outer most Xpage. All other redirects seem to launch Xpages only. I also tried using AJAX to retrieve the URL and then place this inside the innerHTML of the panel via JavaScript, but this also failed when the amount of HTML got large.
My gotcha moment came when I decided to try launching the XPage inside a frameset. The application was originally designed using a frameset and I found I could simply replace the frame that had a form with an embeded Java view applet with a URL that pointed to my XPage (Designer does not yet support XPages as a named element). I had to redesign the view in my Xpage view control so that the linked column was now generated with html that provided the link to the first attachment in each document (column formulae) and hey presto it worked. It vseems that by using framesets you can essentially combine older legacy components with the newer XPage components.
My challenge for another day will be to figure out how to get twoxpage controls to talk to each other across the frames....
|
XPages: Launching an attachment into a frame
|
Mary Beth Raven recently posted an interesting article in which she provided some insight into the Release process for 8.5.1and the steps such as string freeze and pixel freeze needed to control quality of the released code. I thought I should take a leaf from IBM's book and introduce similar controls for my own OpenNTF project....
I am therefore pleased to announce that as of last night .Domino Framework 1.0 has entered string freeze.... Those of you have that have seen the betas up close will know this project is largely held together using mirrors and bits of string. We believe that freezing the string will lessen the chance the code will break prior to delivery.
Tomorrow evening the software will enter pixie freeze... I will be sending a team of pixies up to the north pole to gather pixie dust. The hope is that sprinkling frozen pixie dust on the code will make all those remaining bugs disappear prior to release.
The gold code will be posted on OpenNTF over the weekend. I would like to than the millions of .Domino Framework design partners who particpated in our extensive early release program. This project has been 10+ years in the making and I hope that it will assist at least one other Notes developer out there in the yellowverse.
|
.Domino Framework enters string freeze
|
Progress is slowly being made and my perceptions of Xpages are constantly changing (not always in the same direction)....
First I wish to revise my statements from yesterday's blog about Server-Sided Javascript. Tim Tripcony wrote an excellent article in which he pointed out some of the inaccuracies in my characterizations of server-sided Javascript. It seems that server-sided JavaScript should largely be considered a distinctly different language from client-sided (traditional) JavaScript. They both just follow the same general language syntax (just as LotusScript and VB.Net do). It's a shame IBM chose to use the same name rather than coming up with a new name like LJScript of LotusJScript for this new language to make that distinction. So I was wrong: Server sided JavaScript is (or can be) strongly typed. Tim has also suggested how the JavaScript characteristic of closure can be used as a way to implement a level of OOP. There are in fact a lot of discussion in the wider development community about Javascript and OOP. Much of this exploits JavaScript's ability to define objects and then extend them using the proptotype statement. Combined with closure this provides various techniques in which classes etc can potentially be implemented/simulated. I would still rather see native support for OOL built into the programming language. And perhaps given the way IBM have implemented server sided JavaScrript it may be that in time IBM will add these concepts directly to the language. If they don't, you can expct to see a .Domino Framework 2.0 that does!
But every time I look at the issue of programming language support I still keep coming back to the one question. What is it that IBM is planning to do? I may not agree 100% with their plans but at least if I know where they are heading it might force to me jump off the fence. e.g. If IBM's focus in the short-medium term will be to extend the capabilities of XPages and do very little with the other design elements then Notes developers would be smart to do the heavy lift of learning how to build applications with XPages. If IBM's plans for programming language support is to extend server-sided JavaScript and leave LotusScript as it is (including leaving it out of XPages).then it would be better for LS developers like me to focus on learning/using this new language and largely forgetting about LS. If this isn't clarified clearly I suspect a lot of developers will be tempted to sit on the fence. LotusScript, Forms, Views, Outlines, and Framesets are all within most Notes developer's comfort zone. XPages and server-sided Javascript involves a lot of "pain".
So on to today's observations.....
The Good: Drag/Drop - This is not new stuff for non-Notes development. Products such as Visual Studio, Eclipse, and even VISIO have long supported the ability to drag/drop elements from a toolbox onto visual design elements. It is such an intuitive way to work and way more productive to create an Xpage this way. DDE 8.5.0 is still a little clunky when you try to drag/drop the controls around the Xpage after they have been created. But this is largely a 1.0 release so it is perhaps not surprising. I would hope that IBM add this same capability to forms and pages at a later stage as it is already hard to go back to the old way.
The Bad: Documentation - One of the biggest limitations I am finding at the moment is the difficulty in getting a detailed understanding about how Xpages and server-sided JavaScript works (LotusJScript  ). With Xpages I am finding that I am drawing more on my previous, short, experience as a C# ASP.Net developer than my many years as a Notes developer. Many Notes developers are not as lucky and must be struggling even more than I to understand important new concepts such as application, session, page lifecycle events clinet sided v server sided etc. It would be great if there were a few redbooks, technical books etc that we could consult like a bible while enduring those first few days/week/smonths (years?) as an XPage developer. I remember when I first learnt LotusScript how much I consulted my LotusScript book to figure out how to write my code.
|
XPages - The Good, The Bad and the UGLY - III
|
I was so frustrated with my lack of progress these past two days I decided to take my project home as a homework assignment. I am not sure what it was but suddenly things started to click. Perhaps getting my XPage design onto my 30" monitor allowed me to see the problems more clearly. Eventually I was able to get the interim solution I had been seeking... creating the typical Notes design pattern of a view with a preview pane.
I have read a lot of articles on Xpages over the past few days but didn't see any tutorials on this specific design pattern so I will outline the solution that was ever so painfully constructed.... I am sure I will refine this over time. My first fingerpainting from kindergarten is unlikely to be hung at the Louvre.
Before starting you will need a view to display your data and at least one Xpage that can display the selected row in the view.
- Create a new Xpage
- For Preview Right add a table with one row and two colums. For Preview Below add a table with two rows and one column.
- In the first cell add a view control and format the view to meet your needs
- Use the view properties to assign a value to "var" e.g. rowData (this is found under All Properties)
- In the second cell add a Panel and assign it a name e.g. NotesPreviewPane
- Place an Include Page control inside the panel and select the XPage you wish to use to display the data.
- Views do not have a generic onClick event so you need to create an onclick event for each view column you wish to trigger the preview.
- In the onClick event include code such as follows to save the UNID of the selected document in Session where it can be accessed by the other Xpage.
- doc = rowData.getDocument();
- sessionScope.manualID = doc.getUniversalID();
- In the event definition also set the Server options to Partial Update and select the Panel you defined for the preview (NotesPreviewPane). This will trigger AJAX to be used so that only the preview pane is refreshed each time a new document is selected in the view.
- This is optional but setting the view column property to show values in this column as a link will ensure the cursor changes when the user hovers over the column indicating that this column is linked.
- Set document open mode to read-only (unless you wish to support editing)
- Modify the XPage used to display the data so that the documentID for the DataSource is computed using the formula sessionScope.manualID
The above can be easily extended to inspect the value of Form for the selected document so that the XPage used to display the data is computed based upon the Form rather than being static.
Adding an outline custom control to the left of the view control allows the Xpage to take on the look/feel of the traditional Notes client 3-pane UI that seems to be used by the vast majority of Notes Applications. (I am not saying you should keep using this design pattern!)
My next task for this projects is to simulate the launch first attachment feature. I am hoping that will be a lot less painful.
|
Creating a NotesPreviewPane with XPages
|
More observations on Xpages from my first few days in XPages kindergarten.
The Good: Source View. This is up there as one of my favorite additions to Domino Designer. It is also something I can easily relate to having used a similar feature in MS Visual Studio for ASP.Net development. I am a developer and so I like to look at code. Being an OOP developer I am used to seeing all my LS code in one place (LS library). So being able to see visual elements such as XPages represented as a single block of XML code is really cool. It provides options for me to do things I haven't been able to do with other visual design elements. I can now see what I have done with my Xpage without the need to click on an endless number of controls and review all the tabs with various radio buttoms, check boxes and keywords. I can use the source view to edit visual elements too small to see. I can copy/paste the xml and do search/replace much as I can with LotusScript code. I havent tried this yet, but I can probably now use TeamStudio code snippets as a way of creating a library of common xPage components (over an above custom controls). I am hoping IBM plan to extend this capability to all other Visual design elements, especially forms and views. If I do I might then be able to copy/paste codes between these design elements (see legacy code yesterday).
The Bad: Programming Language Support I was tempted to classify this as just plain UGLY, but that might be a little unfair. I am sure a few people out there such as Nathan T Freeman and Andrew Pollack will disagree with me. That's OK, I respect their opinions, even when they are wrong  ... Without doubt my single biggest disappointnment with xPages so far is the decision to support server sided scripting for XPages with a new variation of JavaScript. Sorry, but I just don't accept that JavaScript is a programming language. Most other development platforms employ JavaScript for client events only. If they could get Java or C# to run in a browser I am sure they wouldn't even be using JavaScript. Most server sided programming outside of the Notes world is now done using OOP languages like Java or one of the .Net languages - C# or VB.Net. Outside the yellowverse it is also pretty much accepted that OOP is the programming style of choice. Within Notes Java is OOP and LotusScript can be (sort of, kind of). JavaScript does not support classes (outside of hacks such as prototype), it doesn't even support strong typing, everything is a variant. There are some cool things with this version of JavaScript such as implementations of @functions, but it is still a procedural scripting language. It seems with this current version of XPages OOP is sadly not an option (agent hacks aside).
I have seen suggestions that JavaScript was chosen as a way of getting Xpages implemented and out there quickly using JFaces. I am not sure if that is true. If it is, I am not sure if that then means in the future support will be added for both Java and LotusScript for Server events and LotusScript for client events. I hope that is the case as it creates a real dilema for me as to whether or not I would want to rewrite my applications from being OOP to procedural. For me that is a giant step backwards from a software engineering perspective. Xpages need engineering as they can be very complicated. I am not sure if IBM have ever publicly commented on its choice of JavaScript for XPages and where this is leading.... It is is still my hope that one day soon IBM will publish a road map for Notes Development programming languages that clarifies the future for both LotusScript and Java. In every Notes shop I have worked for in the past 10 years LotusScript has been the dominant programming language (95%+) . Convincing people to move away from LotusScript may prove to be just as hard as convincing these same people to move away from Notes to Workplace.
|
XPages - The Good, The Bad and the UGLY - II
|
I have blogged a lot recently about Notes 8.5.1. I even sent out a request to Santa Clause to place a copy of 8.5.1 under my Christmas Tree. Shortly after that blog the beta program was announced so I wrote a letter to Santa (aka Ed Brill) and asked for a new bike and a copy of Notes 8.5.1. Its only June, but I still stuck a stocking over my fire place just in case. And then last night when I got home I found my stocking had a registration key allowing me to download and install the latest 8.5.1 beta.
So the good news is I now know a lot more about 8.5.1. The bad news is that in order to get my new toy I had to sign an NDA so I now can't actually say anything. I did blog about consolidated stuff from public forums discussing what would be in 8.5.1. It seems these people all knew what they were talking about!
Tonight I should check to see if the new bike is there too. I was so excited about 8.5.1 I forgot to look.
|
There Really is a Santa Clause
|
|
Now that I am back playing around in Xpages kindergarten I am going to try to chronicle some of my "experiences" in learning (and hopefully mastering) Xpages. In an attempt to be balanced I will try each day to find something good, something bad (and perhaps sometimes) something UGLY.
The Good: View Reuse. Previously it was always necessary to design a view to meet the needs of its ultimate purpose. Views used in the background could be consolidated but views displayed to the user always had to be designed the exactlyas they are to be displayed. This leads to the need to create multiple views containing the same collection of documents. With Xpages I can now use a single view and present it in multiple ways by selecting each time those columns I wish to display. I can even change the column headings assigned to each column and add new columns. This means I can protentially build an application with fewer views than before, a decided performance advantage for databases with large numbers of documents. And less views for a developer to manage has to be a good thing.
The Bad: Legacy Code. When constructing an Xpage it appears almost impossible to use much of the existing (non-Xpage) design componennts contained in this or other applications. About the only thing I seem to be able to copy and paste form other design elements to an XPage is text. I can't seem to copy fields (forms) , tables(pages/forms), columns (views), actions (views,forms,pages), computed text, outlines, layers, or even images (forms/pages) into an Xpage. So in terms up taking an existing application and redeveloping it to use Xpages I basically have to build the application from scratch. Unless later versions of Designer address this I suspect we will have a lot more legacy (non-XPage) applications than we would like.
|
XPages - The Good, The Bad and the UGLY - I
|
|
I can't remember the last time |
2
34
0
|
Title
|
Most Recommendations
|
Most Comments
|
Most Visits