Sep 25, 2015 5:12 PM
453 Posts
topic has been resolvedResolved

Defining a custom property Object (revised)

  • Category: Other
  • Platform: All
  • Release: 9.0.1
  • Role: Developer
  • Tags: Data Object
  • Replies: 6

Found the issue -- had a computedText that had an error in it that stopped everything without returning an error. In any case it now works the compositeData code still fires way too often but not sure what to do about that. The good news is that it is all memory resident code so the performance hit is not great, but....

 

This question is a follow up to my previous question and I will try to refine the issue
http://stackoverflow.com/questions/32789071/defining-an-object-property-in-a-compositedata-on-a-custom-control

Here is a picture of what I am trying to do:

 

The repeat control is bound to an arrayList generated by the Java method Payments.getAllItems(LinkKey) and that works correctly. The button in the repeat is fairly simple it just setts the viewScope.vsShowPayment = true and vsRIndex to the repeat Index value so I know which element in the ArrayList we are working with. It then does a refresh of the panelPaymentContainer which hides the repeat and renders the custom control ccTestPayment. 
ccTestPayment has a custom property called pItem of the type java.lang.Object with this code:

    <xc:ccTestPaymentInput rendered="#{javascript:(viewScope.vsShowPayment)}">
                    <xc:this.pItem><![CDATA[#{javascript:try{
            var debug:Boolean = true;
            if (debug) WFSUtils.sysOut("Open existing row = " + viewScope.vsRIndex)
            rIndex = parseInt(viewScope.vsRIndex.toString());
            if (debug) WFSUtils.sysOut("rIndex = " + rIndex);
            pItem = Payments.getItem(rIndex);
            return pItem;
        
    }catch(e){
        WFSUtils.sysOut("Failure in Custom Prop of add item " + e.toString());
        return null;
    }}]]></xc:this.pItem>
    </xc:ccTestPaymentInput>

the method in the class Payments Payments.getItem(rIndex) then returns the PaymentItem Object from the ArrayList of PaymentItems and displays them in custom control. the fields in the custom control are bound to compositeData.pItem.getPaymentDate etc and to this point everything is cool.

I can edit any of the fields on the custom control and that all works fine. However, when I press the "Save" button none of the code in it gets executed.

    try{
    print("Start Payment save");
    var debug:Boolean = true;
    
    var pos:Integer = parseInt(viewScope.vsRIndex.toString());
    if (debug) print("Working with pos = " +  pos + " Call saveThisItem");
    
    if (Payments.saveThisItem(compositeData.pItem , pos)){
        if (debug) print("save Payments Worked ");
    }else{
        if (debug) print("save Payments FAILED ");
    }
    
    }catch(e){
        print("payment save Error " + e.tostring);
        
    }finally{
        viewScope.vsExpPayDate = null;
        viewScope.vsShowPayment = false;
        viewScope.remove("vsRIndex");
        viewScope.remove("vsGotItem")
    }

None of the print statements get fired. I suspect it has something to do how pItem gets defined. the code behind the custom property gets fired over and over again and I'm wondering if that is getting in the way.

Sep 27, 2015 7:27 PM
588 Posts
hmm

Bill,

This seems rather complicated...  I personally hate seeing the dependency on all those viewScope variables but I'm not suggesting that's related to your problem.

My suggestion is to strip out as much as you possibly can and reproduce the core problem in a database you could upload.  I will then try to look at it or could post it on my blog to see if anyone else can look at it.  

(Ideally, putting any sample in source control would be preferred but I'm not sure you're using that yet.)

 

Dave

Sep 28, 2015 6:39 PM
453 Posts
Dave I got it working the issue was easy.

I have a maxim "bugs that are hard to find are easy to fix, bugs that are easy to find are hard to fix." and this bug was hard to find but really easy to fix. I had a computed Text field on my custom Control that I was using to display a value, This display worked at one time, but then the law of unintended consequences came into play.  I mad a change in a Java Method that was used in the Computed Text which caused the formula in the display to fail. The problem was that there was no error thrown just everything stopped. Clicking the Save button did nothing. After much head scratching I noticed that the computed display was not displaying anything deleted the Computed Text field and everything lit up and started working again. 

There are really only two viewScope variables at play in this whole thing. vsShowPayments (true/false) is set to 'hide' one panel and display another. The other vsRIndex is used to pass the Repeat Control Index value. The repeat Control Index tells me which element of the ArrayList that I need to work with it the when I come to do the CRUD on the individual PaymentItem.

The whole process is reasonably complex in the details but fairly simple over all. I had a process where I created individual Payment Notes Documents related to the main Document using an @Unique key. I then had a repeat control that displayed these related documents. I did the CRUD via a dialog which used the actual Notes Documents and saved them in real time. I needed to get a total of the payments to date so I would need to grab all the related documents and read through them and sum the total Payments. This was cumbersome and slow because in any given iteration of the Main Document I would need to perform this function several times. So I created a JAVA class Payments that contained all the methods. (I'm getting there with this Java stuff). I have a method getAllItems that loads and ArrayList with a PaymentItem Object for each related Notes Document. The getAllItems is only executed once when the Main Document is loaded. After that everything is memory resident so getting the total payed is fast and simple. Then I have a Java Method that I call in the QuerySave that takes the ArrayList and updates or writes new Notes Documents for each of the PaymentItems. 

As suggested elsewhere I have defined a Property Definition of type java.lang.Object  on my custom control that I use for CRUD and load the appropriate item out of the ArrayList of PaymentItems. I considered doing the whole payment CRUD process in Java, but one step at a time.

In actual fact this particular application is fairly trivial (only 3 - 4 fields per PaymentItem but I wanted to do this first kick at the cat on something fairly simple. The application that I'm aiming at each Item will have many fields with a lot of verification and processing.

Thanks for the help and advice really do appreciate it.

Bill

 

Sep 29, 2015 7:27 AM
588 Posts
hmmm

there was no error at all?  Not even on the console?  

 

I still am not feeling using a viewScope variable for the repeat index but I might be missing something.

 

Glad you got it working.

Sep 29, 2015 10:53 AM
453 Posts
No there was not an error anywhere

Yes the computed text field caused a general failure - no error message to the client nor the console. After clicking the save button if I refreshed the page I would get an error but the error bore no apparent relationship to the process causing the problem. Very strange but it works now. 

As far as the viewScope to capture the value of the the repeat index is concerned it works fine. The only issue is that repeat index is an integer value 0, 1, 2 etc and when that is stored in the viewScope it is 0.0, 1.0, 2.0 etc which is a bit of a pain. when I need it to get the correct element have to convert it back to an integer, but that is not a really big issue.

Why do you consider that the viewScope.vsRIndex = rIndex in the repeat button might cause a problem. I guess I could put the CRUD control inside the repeat where I would have direct access to the PaymentItem. I did that when I was using a dialog but had some issues with the CRUD control, but that was early in my learning curve and perhaps I should revisit that part of the issue.

Sep 29, 2015 11:23 AM
588 Posts
hmm

Weird there was no error...  Try adding Xpages Log reader if you don't already...  that gives you access to the console but also some other areas where errors can get logged.

regarding the viewScope as a double...  you can store anything you want in viewScope...  so convert it to an integer or even string first if you prefer....

I don't get  - and again this might just be me, but I don't understand what you're doing by putting a repeat index value into viewScope...  I'm not seeing yet what value that's giving you.  I ASSUME you're doing something like adding a button to "Open a record"...  then that button puts the index number into viewScope...  then you have some kind of dialogbox or something that gets open and then retrieves the index number from viewScope and loads data...  So you're using viewScope as a "CurrentRecord" type of thing...  

I could be very off base there...  I'm much better with seeing code in example apps inside DDE then reading through posts....  If you're doing something similar to what I described then I'd say that there's probably some better methods out there...  if you're doing something different forget everything I just typed.  haha

 

Dave

 

Sep 29, 2015 4:32 PM
453 Posts
The Repeat index gives me the position of the

Payment Object in the ArrayList returned from getAllItems. So if the repeat index is 3 (it is zero based) I know that I am working with the 4th element in the getAllItems. I have a method getItem(Iteger n) that returns the nth element of getAllItems. I then use that in the Properties of the the custom control that I am using for the CRUD. Because my custom control that I'm doing my CRUD in is outside the repeat I do not have access to the data object of the repeat nor the index. 

I'm going to try to move the CRUD control inside the repeat, if that works then I don't need the repeat index because I will have access to the 'current' item Object of the repeat. I know when I tried doing that to begin with I had all kinds of problems, but that was early on in my design learning curve, but I can't see why that would not work and should be faster and smoother -- though the way it is right now works pretty well.