I just watched the Soliant Consulting video giving some information on the new Refresh Portal script step. I have to wonder...what is the difference between this script step and the Refresh Object script step? Didn't Refresh Object do exactly the same thing if you specified the portal object name? Is there some performance benefit to using Refresh Portal?

In my experience, oilcan, Refresh Object doesn't always refresh portal contents, because those are generally cached.  Before 14, the only way* to do it was the sledge-hammer approach of Refresh Window [Flush cached join results], which flushes all join results and is thus a pretty heavy approach, performance-wise.  Refresh Portal gives us a jewelry hammer to use instead of the sledge hammer, refreshing only the cached results relevant to the specific portal.  This is a huge improvement!

(*It wasn't actually the only method.  The other approach was Daniel Wood's cool method employing a Cartesian join, but now it looks like we can finally "ditch the ditch," with apologies to Daniel.  ;-)

Mark

Exactly; the "Refresh Portal" i tuned to do everything it needs to refresh the portal.  More targeted than the "refresh object"

Thanks all for clearing that up!

Edited May 12, 201510 yr by oilcan

In retrospect, They should have just enhanced the 'refresh object' script step to properly work with portals.  I wonder why it needs to be a separate step.  

In any event, I am totally going to start using this one right away!

 

Jerry

I agree with Jerry.. why introduce an entirely new script step instead of fixing the old one.

It also raises another question: with 'Refresh Portal' does FM act on the current portal (which puts the obligation on the developer to move the focus there) or do you specify an object name (which requires the developer to name the portal)? Or.. is there some new way to specify the target portal (e.g. a popup, etc)?

It also raises another question

​

or just RTFD: http://www.filemaker.com/help/14/fmp/en/html/scripts_ref1.35.166.html#1164620

Edited May 12, 201510 yr by eos

And the docs state:

• If the layout object specified for Object Name is not a portal, Refresh Portal performs the Refresh Object script step.

So again, why does this need to be a new script step? Why not update the existing 'Refresh Object'? If the passed object name is a portal, it refreshes the entire portal (ignoring the optional repetition param), otherwise it behaves at it did in the past.

And the docs state:

• If the layout object specified for Object Name is not a portal, Refresh Portal performs the Refresh Object script step.

So again, why does this need to be a new script step? Why not update the existing 'Refresh Object'? If the passed object name is a portal, it refreshes the entire portal (ignoring the optional repetition param), otherwise it behaves at it did in the past.

​So, basically, you should just always use Refresh Portal whether it's a portal or not for the most flexible code. That's just...counter-intuitive and weird. All portals are objects, not all objects are portals. These coding options are bass ackwards. Gotta agree with the above sentiments, why in the world would they have gone this route rather than just updating the Refresh Object step? I mean, I guess it gives more visibility to the ability to properly refresh a portal in this release, but a nice bullet point regarding updated Refresh Object functionality with portals would have worked as well!

Interesting to note that in WebDirect, 'Refresh Portal' actually performs the 'Refresh Window' script step... (according to the help pages)

In trying to fix a non-refreshing portal in my FMA 13, I also stumbled on Daniel Woods original article "Ditch those Flush Caches, Use Cartesian Join Instead!" at

https://www.teamdf.com/blogs/ditch-those-flush-caches-use-cartesian-join-instead

In his follow-up article, he mentions that one of the issues with this method is that the cartesian relationship does not allow for records to be created on the portal. Also it's a hack to be creating a field just for refreshing purposes.

But while we're hacking, why not hack some more and introduce another field in the child table. Both Refresh_1 fields auto-enter 1 in their respective tables. What do you think about this:

Parent_ID = Child_ID

and

Refresh_1 = Refresh=1

So refreshing now works as well as adding new records in the portal.

I know it's a hack for an older version, but since it's the one I'm using right now, it would be interesting to know if perhaps I didn't foresee some completely different problem down the road.

Stefan