More Idle Complaining About Designer
Jan 22, 2012, 6:35 PM
As more and more of my Domino development has been with XPages, my databases have filled up with XPages, Custom Controls, and Java design elements. However, the more I use these, the more of a pain Designer becomes. It gets into its head on a regular basis the notion that it needs to recompile every single such design element - when I open the app in Designer (whether or not it was "greyed out" in the sidebar from before), whenever it "forgets" that I have it set to Automatically Recompile and I have to turn that back on (which is frequent), whenever classes just stop loading properly and I have to Clean the project, and sometimes just for fun.
In a basic app, this isn't so bad... it's pretty annoying, but at least it doesn't take too long. In my forums app, though, which contains dozens of pages, controls, and Java classes, it can take about 10 minutes when I'm not in the office. Ten minutes! Just to open the app! That's even ignoring the side effect that the app is unavailable on the web while this is happening, throwing various server errors until all the classes are back.
I've tried numerous things: switching the Java classes to and from the 8.5.3-standard Code/Java folder to a "classic" WEB-INF/src folder (the 8.5.3 folder seems to make it worse), turning off the "Automatically recompile dependent XPages" option relating to custom controls in the prefs, and creating fresh Windows VMs with entirely-clean installations of Designer. Theoretically, I could turn off automatic compilation in the "Project" menu, but then I'd have to do it manually, and I can only imagine I'd consistently run into times where it "needs" a full recompile anyway.
Other than my job, there are only a couple thing tying me to XPages for my for-fun projects: the fact that I now have a pretty huge foundation of knowledge in Domino development, the fact that XPages actually make a lot of fancy things very convenient, especially with the illustrious Extension Library, and Reader fields. The last one of these is surprisingly difficult to reproduce elsewhere. They're so elegant and bulletproof, much better than filtering results, writing giant nested SQL queries, or throwing up my hands and sticking with a basic "access level" type of restriction. And all of those would still mean I'd have to worry about ensuring that I don't accidentally select the wrong records anywhere I write a query, whereas Reader fields mean that the documents effectively don't exist, so I CAN'T screw it up.
So that leaves my main options as:
- Suck it up and keep using XPages
- Suck it up and give up Reader fields in exchange for a programming environment suitable for human use
- Stop being lazy and write access classes in Ruby or PHP that use the DAS API, hoping that performance is good enough
- Close my eyes and wish real hard that a bug fix patch will come out and magically fix all of the problems in Designer
Number 4 would be ideal, but I think number 1 is what I'll most likely do. Still, being able to use Ruby instead of Java would be such a breath of fresh air, and turning Domino into a "mere" database server via DAS both is appealing and would be mostly new ground. Given that the database-open operation I started halfway through this blog post is in its 16th minute and still going, maybe I really should get off my duff and try that out.
Edit: 32 minutes! Nice!
Sean Cull - Jan 23, 2012, 1:26 AM
This recompiling thing is becoming a serious pain. Working ( or even just looking ) at code on live servers is out ( overdue anyway some might say ) and working in a team is much more difficult.
Hopefully the source control options will help with the team bit.
David Marko - Jan 23, 2012, 2:23 AM
The same experience here. See my blogpost on ths topis and some discussion bellow.
I just found that localy the recompilation process is much faster ... so I have installed Domino server on my notebook. Its a bit faster.
Dan O'Connor - Jan 23, 2012, 12:12 PM
In general it is not advised to work on live production databases. I acknowledge that Designer works less than ideally when building databases with Java code within them, but even if it worked very efficiently there would be a point in time where the class files need to be rewritten, and the xpages would not work during that time. The recommended setup is to work off of a local server (and replicate tested changes to the production server), and use source control for team development. We are aware of these issues and are currently working on them. However, even with everything fixed, we will not be recommending to edit production databases. Please feel free to follow up with me on this issue. We are interested in having as many use cases as possible to make sure we work out the kinks in this.
LongliveLotus - Jan 23, 2012, 5:19 PM
"In general it is not advised to work on live production databases"
We all know this. For me, it's a massive strength of classic Notes nsf applications. Many of us do it and I think the OP's point about wanting to make tiny changes is pertinent. This needs fixing IBM... quick
Toby Samples - Jan 24, 2012, 10:18 AM
I have to agree, Don't work in prod anything, It can only cause problems, just make sure your formal process for updating live can be done in a quick way for emergency issues. But I would say that I have learned to use the Java Perspective using almost always only the Java Editor and the plain vanilla xml editor and it has decreased crashes...
Simple Domino - Feb 9, 2012, 11:50 AM
You could use webdav and store CSS and JS as file resources. I find it useful to be able to d&d a whole folder of items, typically skins, into the database design. There are obviously pros and cons to this.