I've been playing with something off and on since Friday that I think has some serious potential. Rather than silo the idea, I've decided to show you what I've come up with so far and ask if any of you want to lend a hand.
First, let me tease you with a couple screenshots.
Nothing terribly exciting so far, I suppose. How about something a tiny bit fancier?
Okay, I guess that's a little more interesting. It's starting to look like a real XPage now. But what if we pan up a bit?
One final tease... let's slide up just a bit more and a little to the left:
That's right, my friends: none of these screenshots were taken in Designer. Or even Eclipse. It's just Chrome. On a Mac.
This is an XPage app for writing XPage apps. I know that's a bit matryoshka, but I think there are a few fundamental implications lurking beneath this proof of concept:
Immediate, full-fidelity preview. This is not the Design tab in Designer, which gives you a static approximation of what your app might look like; this shows you what your app will look like. Right away. No "Preview in Web Browser"... you're already in the browser. That's why I'm tentatively calling it WYSIWYX: what you see is what you experience.
It's lightweight. No gigabyte footprint installation eating up half your RAM and occasionally all of your CPU. Just whatever browser you already have installed. Hell, it even works in IE.
Did I happen to mention I'm using this on a Mac? I suppose the whole browser thing makes it obvious that the operating system doesn't matter, but in my opinion this is the biggest implication. No need to set up a virtual machine and make sure the guest Windows installation is properly licensed (or, if you're the rebellious type, risk the wrath of Redmond by running it without licensing it). No need to install anything at all. If you've got a browser, you can do your job.
There's a huge amount left to be done. At the moment, it's not hooked up to the VFS, so you can't actually save the result as an XPage directly from the browser. I know how to do this, the code just needs to be written. The component registry that makes what already works possible can also be leveraged to create a component palette much like the one in Designer, as well as a property editor, so developers won't have to type all the XML by hand. Right now it only supports namespaced components; it needs support for passthru as well, but more importantly, resources, data sources, and the like. It's also only handling hardcoded attribute values at the moment... obviously we need to support method and value bindings as well. And of course, it needs some sort of application navigator or package explorer, allowing the developer to add applications and select which XPage they want to edit. The infrastructure is already in place to display multiple editors at once... it just needs to be hooked into some actual navigation.
In short, I'm pretty pleased with the potential represented by the five hours I've spent on this so far (feel free to try out the in-progress proof of concept). But I'm also too excited about what this could become to wait as long as I'd have to if I insisted on writing this all myself. So......... any volunteers?
locating XPage components with XspQuery
Sun, Apr 14th 2013 12:00a Tim Tripcony Several years ago, I wrote a utility Java class designed to make it easy to search for components within the current XPage instance based on various criteria. I've found it enormously useful, and, apparently, so has Keith Strickland, because he added it to org.openntf.xsp.extlib, complete with a few refinements. As an example of how you might use this, examine the following line of code:
List requiredFields = new XspQuery()
.loc [read] Keywords: ldd
your how is not your what
Wed, Apr 3rd 2013 11:36a Tim Tripcony I've noticed a pattern emerging when I'm asked for help with XPages. Here's a representative conversation:
"I'm trying to do [X] and it's not working. How can I do that?"
"What are you trying to accomplish?"
"I already told you. I'm trying to do [X]."
"No, that's how you're trying to do it. What are you trying to do?"
For example, replace "[X]" with "reach into a repeat control from outside it" (since this has become the most frequent topic I'm asked about [read] Keywords: xpages application
my new favorite quote
Sat, Mar 23rd 2013 5:20p Tim Tripcony "We go about our daily lives understanding almost nothing of the world. We give little thought to the machinery that generates the sunlight that makes life possible, to the gravity that glues us to an earth that would otherwise send us spinning off into space, or the atoms of which we are made and on whose stability we fundamentally depend. Except for children (who don’t know enough not to ask the important questions), few of us spend much time wondering why nature is the way it is; where the [read] Keywords: wiki
Taking the scary out of Java in XPages: Prologue
Tue, Feb 26th 2013 9:50p Tim Tripcony The discussion following my last post made stark the need for greater availability of information that makes the nature of Java more accessible to Domino developers. Credit for the title of this post goes to Declan, who is considering writing a series of blog posts on this topic. I will be doing the same; hopefully there will be a fair amount of duplication. As David Leedy is fond of stating, it's a good thing when several people share the same information, because that makes it easier for the [read] Keywords: domino
Passthru vs. component - my perspective
Sat, Feb 16th 2013 9:40p Tim Tripcony Paul Withers posted a thorough article explaining the differences between namespaced XPage components (e.g. ) and their corresponding passthru elements (e.g. ), providing numerous examples of what actually happens when these objects are constructed. I've always heard (and often repeated) that passthru elements are more efficiently processed than their namespaced equivalents, so Paul's post inspired me to offer my own perspective.
Simply put, there's practically no difference... but there a [read] Keywords: acl