Zero to Awesome: Portal Actions - Using a portal for user actions
There are, oh so many ways, to provide for users to click buttons. You can use FileMaker's native buttons, store icons in containers and make those clickable, and there's always portals too!
In this next installment of the Zero to Awesome series, I showcase the method I'm going to use for user actions - called Portal Actions. This is, more or less, using a simple portal to display the possible actions a user can take.
Because a portal can dynamically render its data, you have more control over which actions are shown based on various conditions.
Working within the self-defined context of the My Invoicer file, I can show different actions based on where the user is and what that user can do.
Watch the video for some really advanced FileMaker development. Even if you don't use the techniques shown, it pays to know its possible!
Comments
Portal Actions for a IWP database
Hello Matt & Co.
I have just watched this screencast and I think it is awesome. I have a couple of questions about it:
1- You use zippscript within your solution but looks like it is not available anymore. Is it correct? if so what can I use instead zippscript? and what have I to change on your solution?
2- I need to provide different actions according to the user's privilege sets (what you do in this episode) on a database published through IWP. Do you think there is a way to achieve that?
Thanks and have a nice weekend
Something simpler...
Ciao Matt,
TYVM for another valuable tip that has opened my eyes and my brain again...
Let me suggest a much more easier way to execute a script from an Action_portal like yours without needing any plugin.
The Format>>Button dialog doesn't permit to pass the script name by indirection and the best and FM-only-based way to dynamically launch scripts form a single button (even if part of a portal) is not to use a plugin, but to acknowledge the limit and use it as a starting point, not a close door.
Solution: Define a master script INDEX(scriptname) for example, and pass to it the desired scriptname ...and parameters (but I discourage it because a gui object could suddenly disappear...)
INDEX will cycles through a classic IF-ELSEIF-ELSE-ENDIF and will execute the right script or will report an error message (ELSE) if the script name was not recognized..
It's a long time I'm used to "branch" all my script starting from a so called "INDEX" master script. Every object of my interface always calls INDEX. I've divided it into parts and subparts. For example I group buttons/menus/tabs... and then I subgroup them by context.
You should find something about here --> http://fmdidag.blogspot.com/
Please note that if the field makes use of any kind of calculation, you need to use the Evaluate() function in the optional script parameter.
I thank You again for the "portal by context"idea!
Best regards,
/Stefano Lesandrini