This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Here is where I am still trying to grasp the best solutions to certain problems that only come about in depth asynchronous callbacks.
I have two screens. One for account one for event. In both there is a way to edit an item. If you edit it through the account page, I have to update a section. If I update it through event page, I don't have that. Also from the event page I am passing a boolean to close a window, where I don't have that parameter or need through the account page.
I want to reuse code I have to use in both screens. But here is the rub. The flow is through 4 different callbacks
the event or account page has a link, with the same class name that I attach the click event to. But only attach it when that screen is rendered by the templating engine.
Here is the flow from the account page
A) click on accounts page to bring up popup
B) calls showItemSignedUp which is setting up some vars and calling showItem
C) calls showItem which uses the vars to define the popup.
D) calls saveItemForEvent which is used to save the with a post.
COULD INJECT HERE
E) updateEventAfterItem with closeMe === true in the event page, in the account page no closeMe needed so shouldn't call updateEventAfterItem, but in account page call a different function.
so in A, I know where I am, which affects what E should be. But I don't want to store it in a global var. How do I pass the information that in E I was originally called from the account screen, or I am in E and I was originally called from the event screen.
Remember I put screens because they are not pages. I only have a single page app. The screens are just rendered templates I put into a div called content. So one screen html might be in there, or some other one.
Could you encapsulate the callback functions into an object. And then create another object that inherits from this object and adds the last callback function. This last object have two versions, one with the last callback function for the account page and one for the event page. Kind of like the Template Method pattern, where the steps are defined in the parent class, and all the same functions are also in the parent class and the child just has to implement the abstract methods that are specific to the subclass.
Actually, it looks like that would be the best solution. Create one object with the template function and common functions. Then create a new object for the account screen with the first as its prototype, then add the last function. Then do the same for the event screen setting this new objects prototype to the same base function/class.