@Jake - You can count it if you want -- I do, since you have to do it or things will break. My point is it's more difficult than XPages makes it.
With Flex (or any non-integrated, i.e. non-XPages solution) you simply will have extra steps to go through to get your data to your UI.
For you and I it's old hat, we've both been doing the classic web dev hacks for years. To us it's "simple" to edit a page, add <computed value> and typing an @GetProfileField, then marking it as pass-through HTML. Adding a hide-when to the paragraph is easy enough, too. Then our UI code (Flex in our discussion) can be updated too.
But with XPages it's much simpler, and much more intuitive.
Just to throw another example out there: Say you want to show on the web a field that shows whether or not a database is full-text indexed, and a button that allows the user to full-text index it.
On XPages you'd create a computed text with one line of JS: Database.isFTIndexed(). Then you'd create a button with one line of JS: Database.UpdateFTIndex(True). On the "visible" (or "disabled") property of the button you'd add !Database.isFTIndexed() so that the button is not clickable if the DB is already FT indexed.
How would you do that in Flex (or any other technology)? You'd need an agent that returns the Database.isFTIndex() attribute. You'd need another agent that actually performed the FT index.
That's a LOT of extra clicks and typing compared with what XPages requires. Personally, I'd probably be cursing and swearing as I typed in the name of the second agent and selected all the appropriate attributes. *And* it will run slower, as agents load and then unload themselves when they're called. And now my app has 2 more design elements to worry about.
It's just *clunky*, ya know?
Consider auto-complete type-ahead, also. On XPages you click "Auto-Complete" on your field and you type JS again, which can include an @DbColumn()! One line of code! With anything else you're crafting yet again something to perform the lookup, spit out the XML, and then adding it to your UI framework.
I'm not trying to bash Flex. It's got some good things going for it. That double-sorting-within-the-group-by example that I gave awhile back is a great example where XPages gets its lunch handed to it. I'm just trying to show you that with XPages there is a level of backend integration that you will not get with any other technology.
@Jake - You can count it if you want -- I do, since you have to do it or things will break. My point is it's more difficult than XPages makes it.
With Flex (or any non-integrated, i.e. non-XPages solution) you simply will have extra steps to go through to get your data to your UI.
For you and I it's old hat, we've both been doing the classic web dev hacks for years. To us it's "simple" to edit a page, add <computed value> and typing an @GetProfileField, then marking it as pass-through HTML. Adding a hide-when to the paragraph is easy enough, too. Then our UI code (Flex in our discussion) can be updated too.
But with XPages it's much simpler, and much more intuitive.
Just to throw another example out there: Say you want to show on the web a field that shows whether or not a database is full-text indexed, and a button that allows the user to full-text index it.
On XPages you'd create a computed text with one line of JS: Database.isFTIndexed(). Then you'd create a button with one line of JS: Database.UpdateFTIndex(True). On the "visible" (or "disabled") property of the button you'd add !Database.isFTIndexed() so that the button is not clickable if the DB is already FT indexed.
How would you do that in Flex (or any other technology)? You'd need an agent that returns the Database.isFTIndex() attribute. You'd need another agent that actually performed the FT index.
That's a LOT of extra clicks and typing compared with what XPages requires. Personally, I'd probably be cursing and swearing as I typed in the name of the second agent and selected all the appropriate attributes. *And* it will run slower, as agents load and then unload themselves when they're called. And now my app has 2 more design elements to worry about.
It's just *clunky*, ya know?
Consider auto-complete type-ahead, also. On XPages you click "Auto-Complete" on your field and you type JS again, which can include an @DbColumn()! One line of code! With anything else you're crafting yet again something to perform the lookup, spit out the XML, and then adding it to your UI framework.
I'm not trying to bash Flex. It's got some good things going for it. That double-sorting-within-the-group-by example that I gave awhile back is a great example where XPages gets its lunch handed to it. I'm just trying to show you that with XPages there is a level of backend integration that you will not get with any other technology.