Re: [ptp-dev] Question about the ETFw PerformanceAnalysisTab

[Greg Watson <g.watson@xxxxxxxxxxxx>]

Chris,

I don’t really understand this part of the JAXB implementation. Do you know why it is necessary to save the initialized state?

It seems to me that the lifecycle should be as follows:

1. User creates a new launch configuration or edits an existing configuration
2. initializeFrom is called on the Resources tab (and all other tabs)
3. this loads a controller from the XML (which reads the JAXB configuration)
4. a JAXBControllerLaunchConfigurationTab is created
5. initializeFrom is called on the JAXBControllerLaunchConfigurationTab object
6. JAXB attributes are initialized from values saved in the ILaunchConfiguration

Once the launch configuration dialog is open, switching between tabs should not call initializeFrom again.

7. When the configuration is closed or the apply button pressed, the performApply method is called on each tab. 
8. The Resources tab calls performApply on the JAXBControllerLaunchConfigurationTab
9. The JAXB attributes are saved to the ILaunchConfiguration

The default implementation calls initializeFrom whenever a tab is entered in addition to when the configuration is created or edited. This is because the AbstractLaunchConfigurationTab#activated method calls initializeFrom. I recently added a flag (to master) that prevents initializedFrom from being called more than once on the Resources tab. Everything still seems to work ok, so it might be worth seeing if this helps your issue (or breaks things).

I think some of this JAXB code is a hold over from when resource managers where first class objects. I think Al wanted attributes to be restored if a resource manager was reselected in the Resources tab, but now that we don’t have resource managers any more, I don’t think this code makes much sense. I would be happy to see it removed if it simplifies things.

Greg

On Jan 17, 2014, at 1:46 PM, Christopher Navarro <cmnavarr@xxxxxxxxxxxx> wrote:

> Greg,
> 
> I think the last issue I am working on before I can clean things up and get them submitted to Gerrit is with the way ExtensibleJAXBControllerTab keeps track of whether it is initialized. Currently, ExtensibleJAXBControllerTab.initializeFrom stores its initialization state inside an attribute with a key that is a combination of controlId and initialized. This is really specific to the launch controller and is preventing the Performance tab from initializing it's dynamic tabs. It looks saving the init state prevents switching between tabs from re-activating the "Apply" button when nothing has changed.
> 
> To make this more general, I am thinking about adding variable and set method to ExtensibleJAXBControllerTab so you can specify a key to store init state and if it isn't set, it would get the key as we it is now (from controlId.initialized). Does that sound ok?
> 
> Thanks,
> Chris
> 
> On 01/15/2014 02:05 PM, Greg Watson wrote:
>> Chris,
>> 
>> On Jan 15, 2014, at 11:06 AM, Christopher Navarro <cmnavarr@xxxxxxxxxxxx> wrote:
>> 
>>> Greg,
>>> 
>>> If this isn't a high priority for what you're working on, this will probably be addressed very soon with my current ETFw work. Part of my refactoring with the PerformanceAnalysisTab/ETFWParentLaunchConfigurationTab removes my re-implementation of performApply inside ETFw's parent tab and is more in line with how the ResourcesTab saves attributes to the launch configuration. This removal of duplicated code should make ETFw UI more stable.
>> I’m ok holding off a week or so for you to get the changes in.
>> 
>>> The current issue I'm running into and haven't yet tracked down is with etfw attributes not being found inside the LCVariableMap and the map creates new attributes. The launch config then has the wrong attribute info since the created attribute is very basic, unlike the attribute that was defined in the tool's xml. My problem might be related to yours. Perhaps I shouldn't be using the RMVariableMap from the controller, but create my own that is initialized on the control data from the etfw tool and base my LCVariableMap on my RM map. I will give it a try and see if it addresses both issues. I would like to get this into gerrit by Friday or early next week so you and Wyatt can review what I've done and test it. I'm also waiting to get access to XSEDE so I can test it remotely to make sure it doesn't just work locally.
>> The Resource tab and PerformanceAnalysis attributes are independent right? I can’t think of any reason why they would need to share attributes, in which case you probably do want to create a new map rather than reuse the controller one.
>> 
>> I’m happy to test as soon as you get it in Gerrit.
>> 
>> Regards,
>> Greg
>> _______________________________________________
>> ptp-dev mailing list
>> ptp-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ptp-dev
>> 
> 
> _______________________________________________
> ptp-dev mailing list
> ptp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ptp-dev