[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-debug-dev] Launch Templates
|
One common request we get from our users is that they would like to be
able to edit the launch configurations in a plain editor. This gives me
an idea for a low-tech (and a somewhat crude) solution to this problem:
what if we gave the user an option to see and edit the LC templates in
its raw form (as property name/value pairs). Then the user could
selectively look at the attributes and zero-out the ones that should not
be in the template.
Cheers
Pawel
Darin Wright wrote:
While working on the user interface for launch templates, I stumbled
across the problem described below. I've updated the WIKI (
http://wiki.eclipse.org/Debug/Plan/3.6/Launch_Templates#Design_Decisions)
with this description. Any input would be appreciated. Basically, we need
to decide if it is worthwhile moving ahead with the template
implementation with this limitation.
Launch configurations are relatively simple attribute/value data
structures. However, a launch configuration can use the absence of an
attribute to indicate important data. For example, when the JRE attribute
is not present for Java Application launch configurations, it indicates
that the project (or workspace) default JRE should be used (depending on
whether the configuration is associated with a project). This imposes a
limitation on template implementation: simply copying attributes from a
template to a configuration does not work for template application - as
this does not cause unspecified attributes to be removed.
For example, when a configuration specifies a specific JRE and a template
specifies a default JRE (null), copying attributes will result in the
specific JRE setting to remain in the configuration. For this reason it is
important to persist "null" and "removed" values in configuration
templates. This adds to the complexity of templates - as templates will
often be incomplete. For example, a template would not often contain a
main type name to launch - that whould usually be specified by individual
configurations. So, if the template contained a null or empty main type
name, we would not want this to cause the main type name in configurations
to be wiped out.
For these reasons, it is important that templates contain only the
relevant (sub)set of attributes that they define, and that null/removed
values are also persisted in the template. This also imposes restrictions
in the user interface implementation. If all launch tabs are present for a
template, all attributes will be present in that template - and
effectively override all settings its children configurations. To solve
this problem, a subset of tabs could be allowed for templates - and the
user should decide which tabs are going to be present in their template.
It also means that the effectiveness of templates depends on the existing
set of attributes grouped on each tab, as each tab will be applied in its
entirety to its children configurations. (The platform has no way of
associating attributes with launch tab controls, so this is the finest
granularity it can offer with existing APIs).
Darin
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
