@Jake: I've dabbled in Flex a bit, kicked the tires. I'm pretty sure you've got more experience with it than I do though.
"If the profile field value is added to the XML sent to Flex then you can hide the column. No hoops."
That's my point - getting the @GetProfileField to the XML for Flex *is* a series of hoops. You'd have to (1) Switch from Flex Builder to Designer, (2) go to your page/agent/whatever that's creating the XML (3) open an XML tag, (4) add the profile lookup, possibly remember to escape it properly, and (5) close the tag. Then you can finally (6) switch back to Flex Builder and reference it there.
If, in Flex Builder, you could click on the column, click on the visibility attribute and type an @GetProfileField, you'd have the equivalent of XPages' implementation. Easy and elegant. But you're forced to build these additional data transport layers as you go. XPages handles all this for you.
It can get far more complex from there. Aside from the scaling concerns, or the pseudo-JOIN scenario, consider a security scenario where you don't even want to *send* the XML data for that column if it's hidden. Now you're dealing with more manual code-crafting in the XML generation. It would *have* to be an agent at that point, since you can't put an @GetProfileField (reliably) in a view column formula. That alone might mean a rewrite of your XML generation. And you would need a (tiny) bit more logic on the Flex side of things to handle the fact that the XML attribute might not even be present at run-time.
With XPages you would need zero changes.
I'm not arguing that Flex isn't a good delivery platform, it definitely can be. But there are definitely some advantages to XPages due to the level of integration they have with NSF.
@Jake: I've dabbled in Flex a bit, kicked the tires. I'm pretty sure you've got more experience with it than I do though.
"If the profile field value is added to the XML sent to Flex then you can hide the column. No hoops."
That's my point - getting the @GetProfileField to the XML for Flex *is* a series of hoops. You'd have to (1) Switch from Flex Builder to Designer, (2) go to your page/agent/whatever that's creating the XML (3) open an XML tag, (4) add the profile lookup, possibly remember to escape it properly, and (5) close the tag. Then you can finally (6) switch back to Flex Builder and reference it there.
If, in Flex Builder, you could click on the column, click on the visibility attribute and type an @GetProfileField, you'd have the equivalent of XPages' implementation. Easy and elegant. But you're forced to build these additional data transport layers as you go. XPages handles all this for you.
It can get far more complex from there. Aside from the scaling concerns, or the pseudo-JOIN scenario, consider a security scenario where you don't even want to *send* the XML data for that column if it's hidden. Now you're dealing with more manual code-crafting in the XML generation. It would *have* to be an agent at that point, since you can't put an @GetProfileField (reliably) in a view column formula. That alone might mean a rewrite of your XML generation. And you would need a (tiny) bit more logic on the Flex side of things to handle the fact that the XML attribute might not even be present at run-time.
With XPages you would need zero changes.
I'm not arguing that Flex isn't a good delivery platform, it definitely can be. But there are definitely some advantages to XPages due to the level of integration they have with NSF.