So I’m writing a test framework for a large website, and am currently working on modeling the UI driver. I have a UI Session that abstracts a number of emulators and drivers for browsers and mobile devices. this object also holds state information about the browser session, including a history of page objects, the top of which is the current page. My problem is that I want my page objects to lazy load data from the browser (properties set up with getters that check whether we’ve extracted the data, if not, whether this is the current page, and if so, pulls the data from the browser and caches it in the page object), but that means they need access to the abstraction layer provided by the session.
The first idea of course was just sticking the session in the page, but that creates a circular reference, which is bad. I also considered trying to define multiple interfaces for page, but I couldn’t see how that would really work too well. What I really want is to be able to intercept the call in session then have session redirect the call down to page to a hidden getter that also takes session as an argument, but I haven’t been able to figure out how to do that.
Is there a good solution or design pattern that I could use here to get the info and access I need where I need it without having circular references or giving up lazy loading? I don’t want to make the interface more complicated by forcing users to sometimes call methods and sometimes call properties or members to access the same info (the idea is to hide the fancy footwork behind the scenes and make using the framework dead simple).
I actually do have a CurrentPage class that all it does is store the current_page in a class variable which is set by session on navigate events, so I suppose I could make current_page a magic global-esque accessor that would be the only way to actually get data off the page and have it use a special interface and store the session object as well, but that seems clunky to me.
Anyone have any suggestions?
You said:
“The first idea of course was just sticking the session in the page, but that creates a circular reference, which is bad.”
But that’s not true. Circular references won’t get garbage collected instantly the way non-circular ones will, and
__del__methods won’t get called, but as long as you’re aware of both of those limitations and don’t have needs that conflict with them, circular references are fine. See:http://docs.python.org/reference/datamodel.html#object.__del__Having pages store a reference to the session should be fine.
Edit: if session and page are in different files and circular imports become an issue, you can use an approach like this:
As long as you don’t need to construct Sessions inside of page.py you won’t need to import it at all, since there won’t be a need for capital-S Session (the class). If that changes, you can do something like: