To BS or not to BS ?
By Chandan_DasGupta-Oracle on Jan 16, 2013
Should Browser Scripts be part of the Open UI universe, going forward?
Honestly, the jury is still out on that one. At least as far as the Open UI design team sees it. A thorough analysis of an adequate number of examples is still pending.
But this has been a very common question that we are facing. So I would like to share my thoughts and would appreciate the same from you.
Its always about assigning the right concerns in the right places. What are the concerns that Browser Scripts could address pre Open UI?
- Replicating domain logic (most commonly validations) . Note the "Replicating" part. Just so that things can be a little more user friendly - among other things, maybe avoiding round trips. Never any business logic that is actually NOT implemented on the server and therefore only on the browser. That's just BAD.
- Implementing custom UI where there is room for doing so and a valid use case. By "room" I mean - you can creation a popup window with a bit of interactivity and data entry capability, or maybe a window to just display information. But these are silo UIs away from the main Applets on the screen, where there isn't "room" for UI customization, even by browser scripts (at least in HI).
- Doing custom browser-side pre or post processing for default functionality invoked due to user actions, at the Application, Applet, Business Component or Business Service Level. These are the well known pre and post hooks on InvokeMethod or SetFieldValue, at one or more of the the mentioned levels. Needless to say, this extra embellishment should make sense on the client and should not be something that should ideally sit on the server.
- Interaction with external applications. Again, the first question would be why we are doing this on the client. If we are talking to a desktop application or we are doing a simple browser side mashup (like showing addresses on a map) it may make sense. Remember, we are talking pre-Open UI.
- Injecting styling.
Now, coming to Open UI, and addressing the above concerns in the same order
- Server Domain Logic (typically validations) replicated on the Client is probably the only thing that makes sense in Browser Scripts in the Open UI scenario. And that too only in Business Components. Looking forward to what others feel about this. My thoughts are that this is not "Presentation Model". If anything, it can be considered "Client Mirrored Domain Model".
- All UI concerns in Open UI should be met by the PM-PR stack. Browser Scripts provide a few gaps, where available, to squeeze in UI creation. The PM lets you do whatever you want with the UI, including any level of modification. So which should be used is a no-brainer. And flirting with a hybrid option can provide unpredictable results, apart from the fact that it is an ugly thing to do.
- Unless it is Replicated server domain logic, it must be User Interaction related logic. If it is anything else it does not fit on the client. If it is User Interaction related logic, it should go into the PM-PR stack for the same reasons as mentioned in 2. You have facilities to add all the pre and post hooks that you can add in Browser Scripts, in Open UI Presentation Model extensions as well.
- Do I even need to talk about that?
So in a nutshell, only domain logic (typically server validations replicated on the client) are possible candidates to retain in Browser Scripts. As I said in the beginning, we believe this requires more analysis.
Would love to hear your opinion on this.
See you later! And apologies for the title of the post - no offence meant. I just couldn't help myself.