1 2 3 Previous Next 40 Replies Latest reply on Jun 7, 2015 11:06 AM by erolst

    Portal Filtering - too many cases needed

    glorifindal

      Greetings

       

      I'm filtering a portal with 5 drop down fields … and beginning to despair of ever getting to the end of the Case statements needed...

       

      The following is JUST for ONE field ...

      Case(

      // 1 field

      not IsEmpty( field1 ) and IsEmpty( field2 ) and IsEmpty( field3 ) and IsEmpty( field4 ) and IsEmpty( field5 ) ; field1.s = field1 ;

      IsEmpty( field1 ) and not IsEmpty( field2 ) and IsEmpty( field3 ) and IsEmpty( field4 ) and IsEmpty( field5 ) ; field2.s = field2 ;

      IsEmpty( field1 ) and IsEmpty( field2 ) and not IsEmpty( field3 ) and IsEmpty( field4 ) and IsEmpty( field5 ) ; field3.s = field3 ;

      IsEmpty( field1 ) and IsEmpty( field2 ) and IsEmpty( field3 ) and not IsEmpty( field4 ) and IsEmpty( field5 ) ; field4.s = field4 ;

      IsEmpty( field1 ) and IsEmpty( field2 ) and IsEmpty( field3 ) and IsEmpty( field4 ) and not IsEmpty( field5 ) ; field5.s = field5 ;

      // 2 fields

      etc, etc

      )

      All that for just using one field in the filter

      Is there some way of avoiding this Case madness? The amount of possible combinations for 5 fields is silly to enter into a filter I think

      Orr perhaps I'm just being plain stupid here...

       

      Kindest

       

      Glorifindal

        • 1. Re: Portal Filtering - too many cases needed
          thurmes

          Wait, if you're filtering a portal then it's just a case of whether the record is visible, right? And you'll always want a record visible when any of the fields 1...5 are populated?

           

          Isn't the easiest way

          not IsEmpty ( field1 ) + not IsEmpty ( field2 ) + ... ?

           

          I'm probably just missing something, because I don't see what you are using field1.s, etc, to do once you've set them in this Case statement.

          • 2. Re: Portal Filtering - too many cases needed
            erolst

            glorifindal wrote:

            Is there some way of avoiding this Case madness? The amount of possible combinations for 5 fields is silly to enter into a filter I think

             

            I suggest you explain what these five fields represent and what filter conditions you want to implement.

             

            At a guess, you want to express …

             

            not IsEmpty ( LayoutTO::field1 ) and LayoutTO::field1 = PortalTO::field1

            OR

            not IsEmpty ( LayoutTO::field2 ) and LayoutTO::field2 = PortalTO::field2

            OR

            not IsEmpty ( LayoutTO::field3 ) and LayoutTO::field3 = PortalTO::field3

            OR

            not IsEmpty ( LayoutTO::field4 ) and LayoutTO::field4 = PortalTO::field4

            OR

            not IsEmpty ( LayoutTO::field5 ) and LayoutTO::field5 = PortalTO::field5


            • 3. Re: Portal Filtering - too many cases needed
              Mike Feeney

              The Patterncount function is quite powerful and often overlooked. Here is the basic portal filtering technique I typically use, which can also be used for real-time filtering if you attach a script trigger that refreshes the portal results after each keystroke.

               

              Patterncount ( portalField1 ; filterField1 )

              or Patterncount ( portalField2 ; filterField2 )

              or Patterncount ( portalField3 ; filterField3 )

              or etc

              • 4. Re: Portal Filtering - too many cases needed
                siplus

                instead of filtering, the whole portal could be based upon a relationship between a global field and your data.

                 

                The 5 filters have a trigger that recalcs the global, setting it To List(field1;Field2;field3;field4;field5).

                • 5. Re: Portal Filtering - too many cases needed
                  glorifindal

                  Sorry - perhaps I should have stated:

                   

                  I use a let statement at the start of the calculation -

                  Let([

                  field1.g = TO::field_One_Global ;

                  field2.g = TO::field_Two_Global ;

                  field1 = TO~RelatedTO::field1;

                  field2 = TO~RelatedTO::field2

                  etc

                  I did not use the proper field names in here as I did not see a need to.

                   

                  However, the long list of subsequent Case statements are still needed.

                  I just find that writing out all the combinations very tedious.

                   

                  Example:

                  IsEmpty( field1.g ) and not IsEmpty( field2.g ) and not IsEmpty( field3.g ) and IsEmpty( field4.g ) and IsEmpty( field5.g ) ; field2 = field2.g and field3 = field3.g ;

                  This for just 2 fields / 1 combination…tedious

                  • 6. Re: Portal Filtering - too many cases needed
                    erolst

                    FuneralDataManager wrote:

                     

                    The Patterncount function is quite powerful and often overlooked

                    By whom?

                    • 7. Re: Portal Filtering - too many cases needed
                      glorifindal

                      Adding a relationship would be another way to do it … I have actually used portal filtering only a few times, and thought it might be useful - but when there are so many filter fields to choose from, hmm need to reconsider.

                      • 8. Re: Portal Filtering - too many cases needed
                        glorifindal

                        By me for one :-)

                        • 9. Re: Portal Filtering - too many cases needed
                          glorifindal

                          I'll have a look at this and see if it could provide a shorter amount of Cases needed

                          • 10. Re: Portal Filtering - too many cases needed
                            coherentkris

                            PatternCount is a little more resource intensive than Count ( ) as PatternCount has to parse the entire contents of the field.

                             

                            Count ( table::field1 ; table::field2 ; table::field3 ) returns 3 when table::field1 AND table::field2 AND table::field3 all contain a valid value

                            • 11. Re: Portal Filtering - too many cases needed
                              siplus

                              Your whole case thing could boil down to this:

                               

                               

                              Set Variable [$EmptySituation; Value: IsEmpty(PF5::field1) & IsEmpty(PF5::field2)& IsEmpty(PF5::field3)& IsEmpty(PF5::field4)& IsEmpty(PF5::field5)]

                              Set Variable [$Empties; Value:PatternCount($EmptySituation;"0")]

                              If [$Empties = 0]

                                Exit Script []

                              Else

                                #work to do

                                Set Variable [$i; Value:0]

                                Loop

                                  Exit Loop If [Let ($i = $i + 1; $i > 5)]

                                    Set Field By Name ["PF5::field" & $i & ".s"; ""]

                                    If [not GetAsBoolean(Middle($EmptySituation;$i;1))]

                                       Set Field By Name ["PF5::field" & $i & ".s"; GetField("PF5::field" & $i)]

                                    End If

                                End Loop

                              End If

                              Commit Records/Requests []

                               

                              but then... beyond showing what remains after boiling spaghetti for 3 hours, it's useless.

                               

                              Go with the unfiltered, global-based portal, imho.

                              • 12. Re: Portal Filtering - too many cases needed
                                erolst

                                glorifindal wrote:

                                However, the long list of subsequent Case statements are still needed.

                                I just find that writing out all the combinations very tedious.

                                This for just 2 fields / 1 combination…tedious

                                 

                                I'm beginning to find your usage of the word “tedious” becoming a bit … well …

                                 

                                Anyway, as you have seen from the replies posts, you don't have to write all these combinations – because you'd either  use a relationship, or employ “The Power of Boolean Logic®”, aka “code smarter” … and you still haven't explicitly stated what conditions you want to implement (“I want to see a record from the other table /a record in that other table shall be considered related IF some condition …”)

                                • 13. Re: Portal Filtering - too many cases needed
                                  erolst

                                  glorifindal wrote:

                                  a shorter amount of Cases

                                  Chances are that you won't need a single Case() – see the code example in my earlier post.

                                  • 14. Re: Portal Filtering - too many cases needed
                                    jgalt

                                    siplus wrote:

                                     

                                    instead of filtering, the whole portal could be based upon a relationship between a global field and your data.

                                     

                                    The 5 filters have a trigger that recalcs the global, setting it To List(field1;Field2;field3;field4;field5).

                                    I would highly recommend trying siplus' suggestion.

                                    1 2 3 Previous Next