public abstract class AbstractFolderDescriptor extends TopLevelItemDescriptor implements org.jenkins.ui.icon.IconSpec
AbstractFolder
.Descriptor.FormException, Descriptor.PropertyType, Descriptor.Self
clazz
Modifier | Constructor and Description |
---|---|
protected |
AbstractFolderDescriptor()
Default constructor.
|
protected |
AbstractFolderDescriptor(Class<? extends AbstractFolder> clazz)
Explicit constructor.
|
Modifier and Type | Method and Description |
---|---|
<I extends TopLevelItem> |
childNameGenerator()
Folders, especially computed folders, may have requirements for using a different on-disk file name for child
items than the url-segment name.
|
String |
getCategoryId()
Needed if it wants AbstractFolderDescriptor implementations are categorized in Jenkins 2.x.
|
String |
getDisplayName() |
List<FolderHealthMetricDescriptor> |
getHealthMetricDescriptors()
Health metrics that can be configured for this type of
AbstractFolder subtype. |
String |
getIconClassName() |
List<FolderIconDescriptor> |
getIconDescriptors()
Gets the
FolderIconDescriptor s applicable for this folder type. |
String |
getIconFilePathPattern()
Needed if it wants Folder are categorized in Jenkins 2.x.
|
List<AbstractFolderPropertyDescriptor> |
getPropertyDescriptors()
Properties that can be configured for this type of
AbstractFolder subtype. |
boolean |
isIconConfigurable() |
boolean |
isLookAndFeelConfigurable(AbstractFolder<?> folder) |
boolean |
isTabBarConfigurable() |
all, checkApplicableIn, getDescription, getIconFilePath, isApplicable, isApplicableIn, newInstance, newInstance, newInstance, testInstance
addHelpFileRedirect, calcAutoCompleteSettings, calcFillSettings, configure, configure, doHelp, find, find, findByDescribableClassName, findById, getCategory, getCheckMethod, getCheckUrl, getConfigFile, getConfigPage, getCurrentDescriptorByNameUrl, getDescriptorFullUrl, getDescriptorUrl, getGlobalConfigPage, getGlobalPropertyType, getHelpFile, getHelpFile, getHelpFile, getId, getJsonSafeClassName, getKlass, getPlugin, getPossibleViewNames, getPropertyType, getPropertyType, getPropertyTypeOrDie, getT, getViewPage, isInstance, isSubTypeOf, load, newInstance, newInstancesFromHeteroList, newInstancesFromHeteroList, save, self, toArray, toList, toMap
protected AbstractFolderDescriptor(Class<? extends AbstractFolder> clazz)
clazz
- the explicit AbstractFolder
sub-class that this descriptor is for.TopLevelItemDescriptor(Class)
protected AbstractFolderDescriptor()
TopLevelItemDescriptor()
public String getDisplayName()
getDisplayName
in class TopLevelItemDescriptor
public String getCategoryId()
NestedProjectsCategory
heregetCategoryId
in class TopLevelItemDescriptor
public List<AbstractFolderPropertyDescriptor> getPropertyDescriptors()
AbstractFolder
subtype.public List<FolderHealthMetricDescriptor> getHealthMetricDescriptors()
AbstractFolder
subtype.public List<FolderIconDescriptor> getIconDescriptors()
FolderIconDescriptor
s applicable for this folder type.public String getIconFilePathPattern()
getIconFilePathPattern
in class TopLevelItemDescriptor
public String getIconClassName()
getIconClassName
in interface org.jenkins.ui.icon.IconSpec
getIconClassName
in class TopLevelItemDescriptor
public boolean isIconConfigurable()
public boolean isTabBarConfigurable()
public boolean isLookAndFeelConfigurable(AbstractFolder<?> folder)
@CheckForNull public <I extends TopLevelItem> ChildNameGenerator<AbstractFolder<I>,I> childNameGenerator()
ProjectNamingStrategy
and thereby
prevent users from creating child items with names that do not comply with the ProjectNamingStrategy
.
However, ComputedFolder
instances may not have that luxury. The children of a
ComputedFolder
may have names that come from an external system and the matching item must be created,
always. The obvious solution is that the ComputedFolder
should mangle the supplied Item.getName()
but the side-effect is that the URLs of the child items will now be mangled. Additionally the filename
requirements can be rather onerous. Here is the most portable list of filename specification:
A-Za-z0-9_.-
are available.
and ..
AUX
, CON
, NUL
, etc.
See
Microsoft's page on "Naming Files, Paths, and Namespaces"
(What's that you say, "Oh but we only run on Linux", perhaps but users may want to migrate from one OS
to an other by moving their JENKINS_HOME
(or even parts of it) so if you are
mangling names, be sure to ensure that the mangled name is the same on all OSes
ChildNameGenerator
to having a ChildNameGenerator
as the migration will
require inference of the un-mangled name from the filesystem, which may or may not match the un-mangled
name from the source of the computation. Now POSIX does not specify how the filesystem is supposed to handle
encoding of filenames and there can be strange behaviours, e.g.
File.listFiles()
is rumoured to always return
NFC on OS-X
ChildNameGenerator
at least allows an AbstractFolder
to apply an on-disk naming strategy
that differs from the names used for the URLs.
If you implement a ChildNameGenerator
it is strongly recommended to return a singleton for performance
reasons.
I
- A wildcard parameter to assist type matching.ChildNameGenerator
for all instances of the concrete
AbstractFolder
class or null
if no name mangling will be performed.Copyright © 2016–2020. All rights reserved.