Wednesday, 24 October 2007
Getting up to speed with Quickr ( getting Quicker with Quickr ? )
PS Does one say Connector or Connectr ?
All I can say is "Wow, it's soo cool".
A good example of how component-based architectures work e.g. using Portal Document Manager and Web Content Management through WebSphere Portal, but in a seamless OOB fashion.
Just starting to play with the themes and skins ( standard WebSphere Portal 6 stuff, although it'd be great to see the Portal 6.1 Theme Customizer in there in the future - 8.1 ?? ).
I've just cracked the art of changing the the text on the front page from the default "IBM Lotus Quickr - The fastest way to share everyday content across connected teams" to something different.
In essence, this "splash screen" is created by a portlet called Quickr My Places Header that's deployed on page Content Root -> Home -> Home.
This portlet uses a JSP called MyPlacesHeaderPortletView.jsp which is located in: -
This JSP gets its text from a properties file called: -
which, for the English locale, translates to: -
I changed the value for the NVP quickrArrived from IBM Lotus Quickr to Welcome to my Quickr.
I also changed the text for fastestWay from The fastest way to share everyday content across connected teams to This is THE collaborative team document sharing place-to-be.
Having previous enabled JSP reloading for this particular web application: -
a) Edit ibm-web-ext.xmi in \Quickr\wp_profile\config\cells\dmht6\applications\Quickr_My_ces_Header_quyyjdy.ear\deployments\Quickr_My_ces_Header_quyyjdy\MyPlacesHeader.war\WEB-INF
b) Change reloadingEnabled="false" to reloadingEnabled="true"
c) Restart Quickr
I only need to "touch" the aforementioned MyPlacesHeaderPortletView.jsp to force the page reload. I can then see the changes dynamically by reloading the web browser.
However, you don't need to use reloading if you don't mind restarting Quickr each time you make a change.
A job for another day ................
Monday, 22 October 2007
Lotus Quickr (Java Deployment) to Domino and Sametime
Apart from a few false starts, it's pretty much similar to the process of hooking WebSphere Portal v6 up ( which is no real surprise, given the underlying architecture ).
Looking good .....
Here's my notes of the Quickr -> Domino security configuration, in case it helps. **CAVEAT** Remember, *ALWAYS* use the Information Centre and official documents - my stuff worked for me, your mileage may vary
Wednesday, 17 October 2007
Lotus Quickr - it sooooooooooooo rocks
partners exploring Lotus Quickr; both the Domino and Java flavours ( aka
The more I see of it, the more I like it - I need to do more, and get
into the depths, especially the J2EE deployment, which is based on
WebSphere Portal and Web Content Management.
All in all, a very good investment ......
Thursday, 11 October 2007
WebSphere Portlet Factory - Things I Did Not Know
Imported models seem pretty cool - think of it this way: -
Developer A works on the back-end integration, using direct database/application access or, more likely, a services layer ( whether using web services or not ). This results in a model.
Developer B works on the front-end user interface, applying Web 2.0-like artifacts such as Ajax, Dojo etc. as well as CSS, JSF, JSP etc. This results in a model.
Developer C ( or the architect, which would be me me me ) ties the two models together; for example, he/she creates a third model which is, effectively, the application/portlet framework, and simply imports the other two models into it.
At this stage, all of the builder calls in both imported models are available for Developer C to use, without needing to be bothered about the actual implementation e.g. JDBC vs DAO, JSF vs JSP, Ajax vs Dojo etc.
This provides the ultimate abstraction - if the mechanism of data access changes in the future ( from JDBC to WSDL ), Developer A changes their model, and Deveoper C re-imports it.
The other big revelation was profiling - I kinda knew how powerful this way, especially as I've seen it demonstrated so many times. However, I'd never actually used it.
In essence, Developers A and B both identify builder inputs that can be profiled ( can relate to different use cases ), and associates those inputs with a specific profile set/profile.
The application assembler ( Developer C ) creates/manages the profile, entering the appropriate values for each profiled builder call.
This allows one "application" to be generated for each use case, based on the inputs to the profile. A profile could then be selected by the end-user, or mapped to a LDAP group.
Want to change the way the sales team use/see the CRM application ? Simply change the profile, rather than going back to Developers A and B.
It's possible to introduce muchos complexity at this stage, but there is an art to keeping it simple.
All in all, a good investment of my time thus far .......
Watch this space
Tuesday, 9 October 2007
WebSphere Portlet Factory - More Hands On
It's been especially useful to gain an understanding of the underlying principles and architecture behind WPF.
In addition, having just run through a lab to expose a RDBMS as a service, with SQL queries returning XML datasets, it's good to see the structure and format of a well laid-out model, rather than my hack n' slash approach.
On a related note, I found this external developerWorks wiki for WPF last week: -
Friday, 5 October 2007
Looks like it was last updated in 1965. Kinda surprised to find something so .... well, basic, especially given that it's the gateway to the west of Eire.
Still, mustn't grumble - the wireless is free ( as in air ) and I managed to find a spare wall socket with free (!) power ( don't tell the H&S folks ).
Have been here for nearly three hours, with less than an hour to go before I depart ( for London, I hasten to add ).
It'll be good to back home, after three nights away from my loved ones :)
And, next week, I get to spent FOUR nights away in sunny Manchester, whilst I learn WebSphere Portlet Factory ........ ooh, business travel is just so exotic
Insight into ActiveInsight
So imagine how pleased I was to see a new open beta, v6.1, announced: -
One of the highlights is "...new builders for Cognos, Hyperion and Business Objects..." which, I assume, means that the beta includes a new version of WebSphere Portlet Factory.
I also noted that the beta code will only run on WebSphere Portal 6.1 ( see http://www.davehay.f2s.com/2007/09/ooooh-shiny-stuff.html ) which is even better.
I sense another download-fest approaching..........
Wednesday, 3 October 2007
Nice litle utility .... and it uses a command line too :)
It provides some lovely transition effects and, more importantly, allows the presenter to highlight areas of the "slide" using a user-defined rectangle or a circle ( far better than the "laser" pointer ), provides zooming capabilities and, even better, provides a pan-out mode where all the "slides" in the deck can be previewed.
This makes navigation far easier than the traditional way, and all of the effects can be driven from keyboard commands or, I guess, specific mouse buttons.
Check it out: -
and enjoy presenting once more.
PS Don't have presentations in PDF format ? Shame on you - Lotus Symphony allows you to export from ODF or PPT to PDF ( as does Open Office )
Subscribe to Posts [Atom]