[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-debug-dev] Launch Templates
|
Darin,
Yeah. It does see to me that this gets complicated. You would need to
give users the ability to specify the applicability on a per
attribute level in order to properly support pushing updates to the
children of the template. You could do that via a table, but that
would mean exposing attribute names to the user, and the typical
users doesn't deal with attributes (and shouldn't have to, IMO, in
order to properly make use of this new feature).
Seems to me these complications come to light only in the 'update'
aspect of the feature. While I think it's a nice capability, I think
template are still useful and worthwhile without them. Removing the
'update' aspect also simplifies the existing proposal. You would not
need to preserve a parent/child between a template and its offspring.
John
At 01:36 PM 11/12/2009, 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
