Occasionally, I find plugging in a few lines of JS code in the Pre/Post sections can be useful but I’m not sure if I need to discontinue this habit!
We are using WLE 7.5.1.
NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
This topic has been locked.
5 replies Latest Post - 2013-02-07T21:35:37Z by SystemAdmin
Pinned topic Pre and Post Executions Assignments
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-02-07T21:35:37Z at 2013-02-07T21:35:37Z by SystemAdmin
barsa4ever 270004VVMH100 PostsACCEPTED ANSWER
Re: Pre and Post Executions Assignments2013-02-07T06:50:17Z in response to SystemAdminThe only reason I see here is to keep your code clean. When somebody will try to understand your code, all this pre- and post- assignments will confuse a bit. Trust me, I tried it. :)
Actually I don't think it will somehow decrease performance in any noticable level.
Sometimes it's the only way to make things work, otherwise I prefer not to use it.
Re: Pre and Post Executions Assignments2013-02-07T16:42:45Z in response to barsa4everSo if there is no decrease in performance that would be great. I don't see how this would be confusing when IBM actually provides us with a tiny dot on the left or the right corner of the service (for Pre and Post) to add clarity.
Personally, I prefer to use it (not intensively though) for initialization mainly. I suppose it is a matter of opinion but thanks for your response.
jmac_EmeriCon 110000S3HB279 PostsACCEPTED ANSWER
Re: Pre and Post Executions Assignments2013-02-07T16:52:40Z in response to SystemAdminNot sure if you saw our brief discussion on this topic here.
Bottom line I see no reason to avoid these for simple initializations/logging, but imo they should not be abused.
Re: Pre and Post Executions Assignments2013-02-07T21:16:55Z in response to jmac_EmeriConTo follow up on John's post, the people who feel the most strongly about this are the people who have been burned the most. When you have advance features on, the pre and post are full JS edit windows, like a server side script. This can cause some people to simply jam large JS blocks in there and you don't know why. Additionally you can get really confusing behaviour like "Hey when I ran in debug, right before I went to the coach the value of the variable was X but on the coach it is Y" or "I submitted Y for my value, but when the coach went to the next step, the value was X". Sure there is a little blue dot on the coach but that can be easily overlooked by the person trying to figure out what went wrong. Especially when you start adding in the additional complexity that the 8.0 coaches bring along.
The real problem is many people are lazy and just wind up using it because they don't want to reconnect lines.
There is little to no performance impact either way. If someone really measured I suspect there is a slight chance that the stand alone js block might perform ever so slightly more slowly if "save execution context" is turned on, but I would be amazed if that was a significant difference.
Andrew Paier | Director of Special Operations | BP3 Global, Inc. www.bp-3.com