[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-debug-dev] Launch Configuration Templates
|
>
> Here are my comments regarding launch configuration templates:
>
> 1. Templates and Launch Mode
>
> Do we want to support tying a template to a specific launch mode?
> Would there be a case where a template is only applicable to a
> single mode. I can have a template created for debugging, with special
vm
> arguments, but the arguments are not applicable in run / profile
> mode. I may have special profile settings, that cannot be applied
> to debug or run mode. If the template is not tied to a launch mode,
> would the UI be cluttered to show all tabs that are applicable to a
> launch configuration type? Or are you expecting that when the user
> is working in a template, they would have told us what launch mode
> they are dealing with? What happens if I want to create a template
> for mixed mode: debug & profile?
My feeling is that we do *not* want to tie a template to a specific mode.
Currently, configurations are not tied to specific modes - the same
configuration appears for re-use across all of its supported modes. If the
user makes a mode specific configuration, that is up to them, and the same
rule should apply to templates. (Let's keep it simple).
>
> 2. UI for managing the launch configuration template
>
> How does the user manage and manipulate the settings in a launch
> configuration template? If the user uses the "New Template" action from
the
> toolbar, would the template be shown along with other configurations
> in the LCD. If so, how can the user tell whether a configuration is
> a template or not? Would it be confusing? Should we provide a
> filter to allow the user to filter out the template, or filter out
> simple configurations?
The proposal is that nesting in the tree will show which configurations
are templates (because they have children). In addition, the proposal
suggests that launch configuration types can contribute an image for its
templates. I think we'll have to provide a platform overlay for templates
for configurations do not contribute their own image.
We could consider having filters for templates/configurations if you think
it would be useful.
>
> 3. Create a template from existing configuration
>
> RE: Select the configuration in the LCD and click the "Template"
toolbar
> button.
> Do we create a new launch configuration that will be treated as a
> template, or are we converting existing launch configuration as the
> template? If we are converting the launch configuration, does this
> mean the user can no longer launch the config, and must create a new
config
> from the template? Would it better if we create a new launch config
> and use that as a template?
The proposal is to make the existing configuration a template - *not* to
copy it. There are different work flows that could be used here:
* Convert a config to a template, then make config from the template
(which is easy)
* Duplicate a config, then make the duplicate into a template, then drag
the original config below the template
The first approach seems more natural to me. I'm not sure if it will be
common to create a template and config at the same time.
In general, I would not expect templates to be launched. However, we could
enable the run/debug buttons based on its validation state. We will have a
new method to validate templates in the UI, but we could use the old
method to determine if there are any errors on it (and if not, allow
launching).
>
> RE: "A configuration will automatically become a template if an
> existing configuration is dropped on it as a child configuration. As
> this operation modifies the drop target into a template, the user
> should be prompted to confirm the operation. "
>
> I don't think this is a natural workflow. If an existing launch
> configuration is dropped under another launch config, does this mean
> the child launch config will copy all attributes from the parent
> template in this case. So, this operation changes the drop target
> and also the existing launch configuration. It is not obvious to me
> that I can convert a config to a template this way. But I can
> understand why this is a convenient method. In addition, again if
> the parent configuration is converted to a template, can it be launched
still.
Being able to drop a config on a config seems to be confusing people. So I
suggest we not support this - only support dropping on a template, which
could prompt to apply attributes from the parent template (with a do not
ask again option).
>
> 4. Update all configurations made from a template
>
> I like the idea that we can push changes in the template to the
> children, but should we allow the user to pick and choose, rather
> than forcing an update on all children?
We could provide a selection dialog for this. Not sure if it should be a
different action, or if it should be provided with a "do not ask again"
option. In general children of a template are there for a reason.
>
> In addition, would it be useful for the user to work in a
> configuration that was originally created from a template, and push
> the configuration changes back up to the template? Once the
> template has the setting, the changes can be pushed to other launch
> configurations. Can we also allow the user to choose what
> attributes to sync-up?
I think it's more natural to push attributes down from a template, rather
than up from a configuration. We cannot allow the user to choose
attributes to push since we have no way to correlate the UI widgets with
attributes or descriptions of attributes (i.e. user readable descriptions
of them).
>
> 5. Nest configurations by template
>
> Can a template be nested inside another template? If this is
> useful, what does it mean?
One could nest templates. The core infrastructure supports it, so we could
allow it in the UI. Basically, it allows for a tree of templates, so for
example, you could specify a common classpath at the root, then different
VM args at the next level, and so on. I'm not sure how useful it would be
in practice.
Darin
