If you have questions or if you want to share your opinion about Aware IM post your message on this forum
#51800 by Jaymer
Fri Oct 11, 2019 6:56 pm
UPDATE Jan 13: Just added a new real-world reason why I needed this today.

Either there is a need for this, or I'm doing something the "non-Aware" way.

Lets say you have a table of Products and only 1 can be "Featured".
Either by manual selection, or algorithm, the desired product gets referenced in a tmp field in the LoggedInRegularUser record (because we don't really have temp memory variables, so we have to store this in LIRU)
You have a Process "Set Featured Product"
You want to call this Process and set the one to Featured. Its pointed to by LIRU.tmp_featured_Product
You need to find any previously/current Featured one(s) out there (should only be 1, might be none) and UnFeature it, then mark the desired one.

1. FIND Product WHERE Featured='Yes' /* Found 1 object */
2. Product.Featured = 'No' /* Looks good so far. Previous one gets UnFeatured */
3. FIND Product WHERE Product = LIRU.tmp_featured_Product /* Found 1 object */
4. Product.Featured = 'Yes' /* Sets BOTH Products, because both are in Context */

Existing Solution: Add another Process "Set Featured Product_clear"
Above Process becomes:
1a. Set Featured Product_clear
3. FIND Product WHERE Product = LIRU.tmp_featured_Product /* Found 1 object */
4. Product.Featured = 'Yes' /* Sets only 1 Product, because the other one was not found in this process. Its long forgotten */


Proposed Solution - NEW Function
1. FIND Product WHERE Featured='Yes'
2. Product.Featured = 'No' /* Looks good so far. Previous one gets UnFeatured */
2b. CLEAR CONTEXT Product
3. FIND Product WHERE Product = LIRU.tmp_featured_Product /* Found 1 object */
4. Product.Featured = 'Yes' /* Sets only 1 Product, because we cleared the 1st record from Context */

This isn't a showstopper - because you can always get around the issue by creating a sub process - but thats just ONE MORE Process, and we know how tedious it gets searching through long Process lists.
Would be nice to add 1 Rule to keep from Making a New Process

What do y'all think?
Last edited by Jaymer on Mon Jan 13, 2020 5:02 am, edited 4 times in total.
#51809 by eagles9999
Sat Oct 12, 2019 7:02 am
I would do it like this...unless I am missing something...

Featured Test BS
(37.53 KiB) Downloaded 60 times
#51810 by hpl123
Sat Oct 12, 2019 8:55 am
Jaymer wrote:Either there is a need for this, or I'm doing something the "non-Aware" way.

Lets say you have a table of Products and only 1 can be "Featured".
Either by manual selection, or algorithm, the desired product gets referenced in a tmp field in the LoggedInRegularUser record (because we don't really have temp memory variables, so we have to store this in LIRU)
You have a Process "Set Featured Product"
You want to call this Process and set the one to Featured. Its pointed to by LIRU.tmp_featured_Product
You need to find any previously/current Featured one(s) out there (should only be 1, might be none) and UnFeature it, then mark the desired one.

1. FIND Product WHERE Featured='Yes' /* Found 1 object */
2. Product.Featured = 'No' /* Looks good so far. Previous one gets UnFeatured */
3. FIND Product WHERE Product = LIRU.tmp_featured_Product /* Found 1 object */
4. Product.Featured = 'Yes' /* Sets BOTH Products, because both are in Context */

Existing Solution: Add another Process "Set Featured Product_clear"
Above Process becomes:
1a. Set Featured Product_clear
3. FIND Product WHERE Product = LIRU.tmp_featured_Product /* Found 1 object */
4. Product.Featured = 'Yes' /* Sets only 1 Product, because the other one was not found in this process. Its long forgotten */


Proposed Solution - NEW Function
1. FIND Product WHERE Featured='Yes'
2. Product.Featured = 'No' /* Looks good so far. Previous one gets UnFeatured */
2b. CLEAR CONTEXT Product
3. FIND Product WHERE Product = LIRU.tmp_featured_Product /* Found 1 object */
4. Product.Featured = 'Yes' /* Sets only 1 Product, because we cleared the 1st record from Context */

This isn't a showstopper - because you can always get around the issue by creating a sub process - but thats just ONE MORE Process, and we know how tedious it gets searching through long Process lists.
Would be nice to add 1 Rule to keep from Making a New Process

What do y'all think?


Yes yes yes. I often have scenarios where this would be useful.
#51814 by hpl123
Sun Oct 13, 2019 6:46 am
BLOMASKY wrote:Isnt this what THIS and THAT were created for?

Find....
Product.... = No
Find....
ThisProduct.featured = 'Yes'

Bruce


Yes, This That and Other works in many cases but you are limited to 3 "batches" of data (sometimes more complex operations with data etc. is needed) and sometimes the This, That and Other is buggy. Another thing is, sometimes even with subprocesses and measures to work with data completely independant from original data, Aware confuses the context and applies operations and data change from the old data operations to the new data operations (which it shouldn't i.e it's buggy as well). NB: This functionality works 98% of the time i.e it´s not a big thing but it still happens.

Having a function to simply CLEARCONTEXT would enable us to work around all this (sometimes a real clean slate is what you need) and also as Jaymer pointed out, minimize total number of processes.

When talking about new context function/ideas. I would love to have memory slots for context (think calculator M button) where we could allocate a context batch to a slot e.g M1Context, M2Context etc. and then (after clearing context) work with some other things before returning/calling/using data from the memory slots. A cool and maybe better variation of this would be to give us state management like functions where we could use "variable" names like PRODUCTCONTEXT = X (current context or operation to populate context with stuff).
Last edited by hpl123 on Sun Oct 13, 2019 5:05 pm, edited 2 times in total.
#51816 by Jaymer
Sun Oct 13, 2019 8:26 pm
If you're looking at this as just a way to prove that THIS or THAT "may" work, then you're missing the point.

Try this alternate scenario.

FIND n records FROM CUST WHERE xyzzy /* Finds 3 records this time
CALL Process /* Send the found Context off for processing
FIND n records FROM CUST WHERE plugh /* Find another set of 5 records, for example
CALL Process /* SENDS ALL 8 records off for processing, INSTEAD of the 5 you want

USING CLEAR CONTEXT CUST inbetween the steps would make this work as desired (and as Obvious to most people reading the rule)
Last edited by Jaymer on Mon Jan 13, 2020 5:00 am, edited 1 time in total.
#51817 by PointsWell
Sun Oct 13, 2019 9:47 pm
Jaymer wrote:If you're looking at this as just a way to prove that THIS or THAT "may" work, then you're missing the point.

Try this alternate scenario.

FIND n records FROM CUST WHERE xyzzy /* Finds 3 records this time
CALL Process /* Send the found Context off for processing
FIND n records FROM CUST WHERE plugh /* Find another set of 5 records, for example
CAL Process /* SENDS ALL 8 records off for processing, INSTEAD of the 5 you want

USING CLEAR CONTEXT CUST inbetween the steps would make this work as desired (and as Obvious to most people reading the rule)


Generally if I have this type of challenge then I am trying to do too much with a single process. If you are doing searches to then process the find results afterwards I find it best from a code containment point of view to drop these to a lower process.

If you need the results back in the main process then I create a non persisted BO, pass that to the sub process run the sub process and then attach the result to the NPBO to pass back to the main process.

Personally I have hundreds of processes. All of them pretty small and all of them with a standard naming convention of:

BOname_action_stepInProcess_SpecificAction

Eg
Contact_Create_1000_AttachEmployer

To me that is easier to follow, easier to debug and easier to find than monolithic processes.
#52720 by Jaymer
Mon Jan 13, 2020 4:37 am
And yet ANOTHER real world example - and reason why I need this.

You can't have a THAT without THIS !!!
Please examine this code (the Last Rule uses That):
Screen Shot 2020-01-12 at 11.33.37 PM.png
Screen Shot 2020-01-12 at 11.33.37 PM.png (51.48 KiB) Viewed 701 times


Gets a Cust & builds the AddrBlock
Finds the Department, where there may be 1 or 2 Contacts assigned
Builds ContactBlock for 1st contact, if found.
Builds ContactBlock for 2nd contact, if found. (MUST use That, because there are 2 Contacts in Context)
BUT, if the 1st of 2 Dept. Contacts is UNDEFINED, then there won't be 2 in Context.
The THIS wont be there, so the THAT won't work. THAT IS THIS WHEN THIS IS UNDEFINED, ELSE THIS IS THIS AND THAT IS THAT

SO, ONCE AGAIN,
If I had a simple CLEAR CONTEXT Contacts
to use when I need it, it would turn this into a non-starter. No need for This or That here, at all.


WHY do i need the subroutine? This subroutine is used to build a temporary address & contact section which goes at the top of several different reports.
The Contacts are not even reachable from the Invoice header - they are 2 files away via a Multi reference. And in address blocks you want to remove blank lines. So rather than code that several places, I build these simple formatted blocks for displaying the data.
Screen Shot 2020-01-12 at 11.51.25 PM.png
Screen Shot 2020-01-12 at 11.51.25 PM.png (39.94 KiB) Viewed 700 times
#52721 by Jaymer
Mon Jan 13, 2020 5:09 am
Also, you might ask... Why don't you have Rules that prevent someone from Entering a 2nd Contact, if there's not a 1st. -OR-
If they remove the 1st Contact, then don't allow a save until they move that 2nd Contact to the Primary position.

Great idea - except there's no way for a user to clear the reference field, per this thread.

Who is online

Users browsing this forum: Google [Bot] and 16 guests