Tightly Integrated Private Helper Class

I'm working on a page with two sets of collapsable panels. using nHibernate) I get category objects with a list of items in them, and for each category generate a left panel and right panel. In both panels, there is a ListBox. Items are pre-populated to the left list box and the user can select and move items into the right list box (under the corresponding category.) As I've built and worked on it, I ended up with a lot of generic methods like buildPanel(side,categoryID) and then ended up with a lot of repeated if statements inside them to differentiate between the two sides

if type=PanelType.Left then
set these 5 id strings to access components
else
...

The code got messy, so I moved a lot of the logic and static builder strings for the component ids into a private helper class in order to make other parts of the main class easier to read and follow. The problem I see is that the private class is extremely dependant on specific structures in the parent class. There's a very minimal amount of encapsulation going on and I'm possibly making the logic harder to follow even if the individual components in the code are easier to read.

My question is: When you're using a private class like this, is it acceptable to have it tightly integrated with the parent class (since it's private and implemented in the same file), am I better to refactor again and find a way of either simplifying my original code to be as short as possible without the helper class (stick all category/panel functions in one spot and hide them in their own region when I'm not using them), or should I move towards putting more of the logic in the helper class and simply mapping my events directly to the subclass. After typing all this out, I'm leaning towards the last option, but I'm still torn/confused about the whole thing...