Jump to content

  •  

Photo

OnRecordCommit in Portals?

portal commit record trigger

  • Please log in to reply
8 replies to this topic

#1 j.s  member

j.s
  • Members
  • 16 posts
  • FM Application:11 Advance
  • Platform:Windows XP
  • Skill Level:Intermediate
  • Time Online: 2d 19h 28m 8s

Posted 27 November 2011 - 04:10 AM

Hi

I'd like to have a validation script run, whenever a portal row is commited, or more precisely: whenever a portal row loses focus AND was modified before.

I tried Portal::OnObjectSave, whicht unfortunately doesn't fire for known reasons.
I tried Portal::OnObjectExit, which fires too often, namely, even if the portal row data was NOT modified.
I tried PortalField::OnObjectSave, which fires too early, because validation can only be done on record level, but not on field level.

I have in mind to use Portal::OnObjectExit and there decide, whether a record needs validation based on a flag that was either set priorly using PortalField::OnObjectSave or by evaluating the record's modification timestamp in a way that I haven't figured out yet.

Either way, I'm afraid that my solution will lack of elegance and robustness.

I'm aware that the same question was posted earlier this year, but there was no sufficient answer (in my eyes).
Nevertheless, I reckon this problem is standard and me, being a script newbie, just blind to the appropriate solution.. :-)

Thanks for your trouble!

Jürg from Zurich
  • 0

#2 LaRetta   Lifelong FM Student

LaRetta
  • Members
  • 9,989 posts
  • LocationOregon
  • FM Application:13 Advance
  • Platform:Mac OS X Mavericks
  • Time Online: 243d 12h 59m 20s

Posted 27 November 2011 - 10:43 AM

Hi Jürg,

I cannot grasp what you are attempting here. We need to visualize the process. What is the name of the parent table and the name of the portal table? And what is a User doing when you want this 'action upon commit' to take place, e.g. adding parent then child records, only changing a value in a portal field? And what is the specific validation which needs to fire?

Usually when I get into 'twists' it is because the logic has not yet been walked through sufficiently to clearly see the true need. Not to worry ... you are in the best place for assistance. So please walk through the visualization for us - not what you have tried but rather what you are doing and then why it is insufficient. If you wish to post a file or example to add clarification, it usually helps.
  • 0
Each assumption is an educated guess, a likely condition or event, presumed known and true in the absence of absolute certainty.

#3 comment  consultant

comment
  • Members
  • 24,563 posts
  • Time Online: 344d 15h 14m 36s

Posted 27 November 2011 - 04:57 PM

I reckon this problem is standard


I don't think so.

One of the features of editing records in a portal is that any modified row remains uncommitted - thus allowing ALL edits to be reverted. Conversely, you cannot selectively commit a specific portal row - it's an all (including the parent record) or none proposition. This is also why the script step is called Commit Records (plural).

I suspect that portal editing may not be best suited for your purpose. Still, it's possible to do what you requested, with only a small addition - see attached.

Another option would be to capture all relevant values into a variable upon entering a portal row, and comparing it to the current values upon exit. Note that looking at the record's modification timestamp is useless, as this will change only upon commit.

Attached Files


  • 0

#4 LaRetta   Lifelong FM Student

LaRetta
  • Members
  • 9,989 posts
  • LocationOregon
  • FM Application:13 Advance
  • Platform:Mac OS X Mavericks
  • Time Online: 243d 12h 59m 20s

Posted 27 November 2011 - 06:02 PM

I would never have considered using Get ( OpenRecordState ) in this way!
  • 0
Each assumption is an educated guess, a likely condition or event, presumed known and true in the absence of absolute certainty.

#5 comment  consultant

comment
  • Members
  • 24,563 posts
  • Time Online: 344d 15h 14m 36s

Posted 27 November 2011 - 07:09 PM

Me neither. That's exactly the fun mentioned in the other thread:
http://fmforums.com/...post__p__377824
  • 0

#6 LaRetta   Lifelong FM Student

LaRetta
  • Members
  • 9,989 posts
  • LocationOregon
  • FM Application:13 Advance
  • Platform:Mac OS X Mavericks
  • Time Online: 243d 12h 59m 20s

Posted 27 November 2011 - 07:48 PM

Indeed! :yep:
  • 0
Each assumption is an educated guess, a likely condition or event, presumed known and true in the absence of absolute certainty.

#7 RodSierra  apprentice

RodSierra
  • Members
  • 233 posts
  • FM Application:10 Advance
  • Platform:Cross Platform
  • Time Online: 2d 8h 42m 55s

Posted 27 November 2011 - 08:37 PM

Thanks for the idea, and good example of OpenRecordState.
  • 0

#8 j.s  member

j.s
  • Members
  • 16 posts
  • FM Application:11 Advance
  • Platform:Windows XP
  • Skill Level:Intermediate
  • Time Online: 2d 19h 28m 8s

Posted 28 November 2011 - 03:00 AM

Holy cow, Comment, that's most impressive! :-) A lot of fun, indeed!

I would have never guessed that the flag that I was going to implement myself in humbling manner does already exist. Moreover, it even seems to be rock-solid (at least I couldn't make your solution misbehave in no way) and requires no maintenance, should ever fields be added to the child table.

All the more, I now wonder why portals shouldn't be the best choice for my problem (as you said). In terms of user-friendliness I reckon they are.

Thank you, Comment!
Thank you, LaRetta!

It seems lik you made me save a lot of time and trouble, since this situation occurs regularly in my projects (whenever its about complex user data validation) and, feeling very thankful, I browsed through your profile looking for sth like a 'Donate' button, because the service you provide is on the far side of self-evident. How can I show my gratitude?

Jürg
  • 0

#9 comment  consultant

comment
  • Members
  • 24,563 posts
  • Time Online: 344d 15h 14m 36s

Posted 28 November 2011 - 04:04 AM

All the more, I now wonder why portals shouldn't be the best choice for my problem


I am thinking this problem wouldn't exist in List view, since there you cannot exit a record without committing it.


I browsed through your profile looking for sth like a 'Donate' button


Hmm. Something to think about - thanks for the idea.
  • 0




FMForum Advertisers