This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal



Oct 17, 2014, 12:50 PM
14 Posts

The Number of Strategies that Don't Work

  • Category: APIs
  • Platform: All
  • Release: All
  • Role:
  • Tags: XPages Application
  • Replies: 3

Something I've run into with XPages is the number of red herring solutions I hit while developing. Often I am developing 2, 3 solutions at once just so I have a backup when I hit a brick wall. At first I thought it was my inherent lack of experience with XPages, and maybe thats true. But for example, setting up a project tab to report multiple appointments, I was trying 1-filling in filelds & appending them to other fields on one doc, and 2- writing up SSJS to create new docs for each appointment. Of course both sound plausible. I'm sure both are ultimately workable. But I ended up with the doc oriented solution working very quickly, and wondering why the list oriented solution didn't, or got stuck on some debugging problem. I dunno if it's the sheer quantity of debuggers and layers of browser, server, Javascript flavor, Javascript object environment, contributing to the frustrations over what seemed to be a simpler solution.

In full disclosure, a couple of other list-based features worked just fine on the same XPage.

Now, this solution is released & working. But I am reflecting on the sheer dev cost of doing the same things different ways til it works. That is my main concern.

I've worked on other dev projects outside Domino, and this is not ... uncommon in Java dev. There're a lot of ways of doing things on Java servers, and thats not a compliment. The nice side of Domino has been a useful set of tools to leapfrog other dev platforms, along with quick ways of discovering what works. I have found that feeling in how some of the Extension Library components, work. And I look forward to a point where theres some help with that, again.

Oct 18, 2014, 2:29 AM
586 Posts
hmmm

I'm not sure I'm following you on this one.  :)

You tried some things that didn't work and then came up with something that did?  Again I'm not sure I understand what you're trying to say. I'm not sure what you mean by doc orientated vs list based.

I think there's always different ways to solve anything.  You have a choice of platforms, tools, and techniques.  

Look at a repeat control for instance.  How do you get it data?  You could bind it to a view.  a DbLookup.  A Server Side JavaScript function, a Java Object, a Mananged Bean, and probably others that I'm forgetting.  It's the details that might determine which one you want to use.  But choices of tools is typically a good thing.  I think it's about choosing the right tool for the job for the right reason.

Dave

 

Oct 18, 2014, 5:09 PM
14 Posts
its not that I want working strategies reduced

Its a number of things, though.

First, I've noticed the quantity of "blank looks" from the server has increased.

I'm spending far more time searching for SS issues by printing debug messages.

Second, validation errors silently stop the whole page.

Finally, SS code sometimes just doesnt get executed, due yes to some legitimate issue running the SSJS or tge like, but throwing no errors I can see, either in compike or often in debug runs.

Now, I've been on this platform ... longer than you. Love your work with it, and follow. But I know what I am missing in XPages dev environment.

I really need much better coding-time warnings, especially to trap issues with SSJS and validation coding. Yes, I am intensely aware Javascript syntax is all thats checked right now. It doesnt compare with other language support in Domino.

Oct 20, 2014, 3:19 PM
453 Posts
Some of my experience

I to come to XPages from many years in the Native Notes environment and found the first few iterations in XPages extremely frustrating. I found the lack of documentation to be a major stumbling block. Mastering XPages was a great help but much of the discussion on various blogs and sites was very good but way beyond my knowledge level (the TLCC courses were also very helpful to say nothing of Dave's NotesIn9). Oh how I missed the debugger in LS. 

In the process of developing I found myself painted into a corner on more occasions than I want to count. I have torn my application apart more than once and put it back together again, but within XPages I have found that process not nearly as challenging a task as in native Notes. I learned very early on to put everything into smaller custom controls then combine them to a final XPage. In fact my application contains just two XPages one to view information and another to do CRUD.

I use the deBugToolBar fairly extensively, but also do lots of println statements to the console. I have not been able to really get the SSJS debugger to work very well.

 I have said before that there are many things that are dirt simple in native Notes but really difficult in XPages, and there are many things that I wish I could have done in native Notes that are a piece of cake in XPages. 


This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal