org.netbeans.modules.vcscore.util (NetBeans VCS API) - NetBeans API Javadoc 4.1.0

Overview

Package

Class

Use

Tree

Deprecated

Index

Help

PREV PACKAGE NEXT PACKAGE

FRAMES NO FRAMES

Package org.netbeans.modules.vcscore.util

This package provides declarative UI parsing and rendering engine.

See:
Description

Interface Summary

NestableInputComponent Defines contract that all embedded JCOMPONENTS must implement.

TopComponentCloseListener This listener is used to listen to the closing of a TopComponent.

VariableInputDialog.FilePromptDocumentListener

Class Summary

ChooseDirDialog Select directory dialog.

ChooseFileDialog Select file dialog.

Debug Deprecated. Use ErrorManager instead.

FileEditorSupport

FileEditorSupport.FileEnvironment

NotifyDescriptorInputPassword

OrderedSet

Table Table class implements the Map interface.

TableMap In a chain of data manipulators some behaviour is common.

TableSorter A sorter for TableModels.

VariableInputComponent The representation of component for variable input.

VariableInputDescriptor The descriptor of variable input components.

VariableInputDescriptorCompat This class assures compatibility of variable input expressions used in 3.1 release with the variable input descriptor used in 3.2 release.

VariableInputDialog Dialog that enables users to set variable values before running the command.

VariableInputNest Provides services for embedded JCOMPONENT in VariableInputDialog.

VariableInputValidator This class validates the variable input components and provides the result of that validation.

VariableValueAdjustment This class is used to adjust variable values so that they can be expanded to the execution string.

VcsUtilities Miscelaneous stuff.

WeakList A simple list wich holds only weak references to the original objects.

Exception Summary

VariableInputFormatException The exception describing a bad format of variable input descriptor.

Package org.netbeans.modules.vcscore.util Description

This package provides declarative UI parsing and rendering engine.

VID User Interface

The package can parse text format and present it to user. TODO more data here.

Defaults Support

When used with profiles there are variables holding command context that can be partially customized by user. The command customization called from CommandProcessor shows the VID UI. The VID UI is described by VIDecriptors that map to subset of actual command variables. Some VIDescriptor values are computed so these values cannot be stored as literals.

Also there are variables that hold literal values but are not actually visualized. It happens for trivial vs expert mode. What values should be stored to defaults and restored later on in different mode? Two examples:

Update Command

 ASK_FOR_EXPERT(PRUNE_EMPTY, ...
 ASK_FOR_EXPERT(CREATE_DIRS, ...
 ASK_FOR_EXPERT(RESET_STICKY, ...
 ASK_FOR_EXPERT(GET_CLEAN_COPY, ...
 ASK_FOR_EXPERT(FORCE_HEAD_MATCH, ...
 ASK_FOR_EXPERT(SEND_TO_STDOUT, ...
 PROMPT_FOR_EXPERT(TAG, ...
 PROMPT_FOR_EXPERT(DATE, ...
 SELECT_RADIO_EXPERT(MERGE_SELECTION, ...
 SELECT_COMBO_EXPERT(RCS_KFLAG, ...
 IF_VAR_EMPTY"recursionBanned"_IF_VAR_NON_EMPTY"FILES_IS_FOLDER"_ASK_FOR_EXPERT(RECURSIVE, ...

In trivial mode there is no component visible and no variable should be defined. In expert mode there are all (possibly minus RECURSIVE) components visible and previous value should be loaded.

In both modes default values reloading should be defined by actual components visibility (catching IF_VAR_EMPTY"recursionBanned"_IF_VAR_NON_EMPTY"FILES_IS_FOLDER"_ASK_FOR_EXPERT) plus in trivial mode PRUNE_EMPTY and CREATE_DIRS. Here interesting situation happens From user point of view value of PRUNE_EMPTY and CREATE_DIRS should be shared between modes in spite of act that it's never visible in simple mode. Hopefully it could be permit-able to ignored it here.

Add Command

 SELECT_RADIO(FOLDER_CONTENTS, ...
 PROMPT_FOR(DESCRIPTION, ...
 IF_VAR_EMPTY"recursionBanned"_ASK_FOR(RUN_RECURSIVELY, ...
 ASK_FOR(DO_COMMIT, ...
 SELECT_RADIO_TRIVIAL(KFLAG_TRIVIAL, ...
 SELECT_COMBO_EXPERT(KFLAG_EXPERT, ...

In trivial mode there is simplified KFLAG component. In expert mode these is full blown KFLAG component. RUN_RECURSIVELY can be possibly hidden depending on execution context.

Ideally defaults reloading should translate between KFLAG trivial and expert modes. Actually it's permit-able to store values for both modes. Note here we do not want to loose trivial mode default in expert mode and vice versa. The storage is not defined by pure components visibility.

Commit Command

 PROMPT_FOR_FILE(TEMPLATE_FILE, ... {FILE_OUTPUT_OF_COMMIT_TEMPLATE_GETTER(0)} ...
 ASK_FOR_EXPERT(FORCE, ...
 PROMPT_FOR_EXPERT(BRANCH, ...
 ASK_FOR_EXPERT(RUN_MODULE_PROGRAM, ...
 IF_VAR_EMPTY"recursionBanned"_IF_VAR_NON_EMPTY"FILES_IS_FOLDER"_ASK_FOR_EXPERT(RECURSIVE, ...

In trivial mode there is only description text visible. The field value it loaded dynamically by evaluating a template getter. There is nothing to store as default - no button should be visible. In expert mode there are visible additional components. RECURSIVE visibility depends on command execution context.

RECURSIVE shoud be shared between modes regardless it's visibility. It's the same situation as with Update's PRUNE_EMPTY and CREATE_DIRS.

Defaults Scope Point of View

Currently defaults are stored on per profile basics. Cleanly not all variables are suitable for per profile reusing. As an example Update's TAG can be taken. It's workdir specifics and it does not make sence to store it. Moreover in CVS case it's defined by directory context so it should be unspecified until user realy wants to switch to another branch.

Roughly spoken for CVS the whole defaults propably degrade to equivalent of what is typically stored in $HOME/.cvsrc.

Defaults Support Summary

Values must be loaded on visibility basics. No invisible value can be reloaded. It guarantees not ideal but permit-able behavior. Values must be stored in a such a way that old defaults are merged with existing defaults to avoid loosing defaults for variables defined in other mode. Ideally there should be variable convertors between modes but merging is permit-able behavior.

Scope point of view probably reduces stored variables even further, storing and reloading globally just variables listed in a predefined list. This solution is used.

VARIABLE_DEFAULTS statement allows to define defaults handling. It defines a list of pairs: variable name and its storage mode. There are two storage modes USER that reloads variable value regardless of mode (propagating from advanced to simple) and EXPERT_USER that reloads expert variable in expert mode only.

E.g. CVS DIFF defines VARIABLE_DEFAULTS(IGNORE_WHITE USER, IGNORE_SPACE USER, IGNORE_CASE USER, ADDITIONAL_OPTIONS EXPERT_USER)