Examples of View

• android.view.View
• at.jku.sii.sqlitereader.model.View
• bm.core.mvc.View
  View (see MVC Pattern). @author Narciso Cerezo @version $Revision:4 $
• bpntojava.view.View.View
  View. @author mschuessler
• ca.simplegames.micro.View
  @author Florin T.PATRASCU @since $Revision$ (created: 2012-12-24 12:09 PM)
• chunmap.view.View
• collide.gwtc.ui.GwtCompilerShell.View
• com.ateam.webstore.ui.views.View
• com.basemovil.vc.view.View
  Base view class. @author Narciso Cerezo @version $Revision$
• com.caucho.config.gen.View
  Represents a public interface to a bean, e.g. a local stateful view
• com.centraview.view.View
• com.couchbase.client.protocol.views.View
  Represents a View definition inside the Couchbase cluster. This class knows whether the view contains "map" and/or "reduce" functions. It also is able to generate the URI representation of itself to be used against the cluster. Also, instances of a View can be used in combination with DesignDocuments to actually create them.
• com.daehonges.soilsieve.View
• com.dotcms.repackage.org.jgroups.View
• com.espertech.esper.view.View
  The View interface provides a way for a stream, data provider, or another view, to notify an object of additions and deletions to its data set. Views are themselves Viewable by other Views, and can implement their own set of cached data internally. The contract is that a View is wholly derived from the object (its parent) to which it is attached. That is, it must be able to reconstitute its cached state from a playback of source data passed to it through the update() method. A view's job is to derive some data from the data in the Viewable object to which it is attached. This can happen by a 'push' mechanism whereby new data in the underlying collection is pushed to the view through the update method. A view that operates in this mode incrementally updates its derived data and then provides this data to any queries or requesters through its Data interface and potentially through other customized methods it exposes. When these methods are called, the view in push mode does not contact its parent: it just supplies the requester with the data it already derived. The push mode is efficient when data in a view is slow-changing with respect to how much its data is requested. For example, a view calculating the mean of an intermittent signal over time may be queried very frequently. It incrementally updates its statistic and then provides that quantity to callers whenever they want it, which may be much more frequently than the incoming signal occurs. The 'pull' mechanism is driven by requests to the view's Data interface or other customized data access methods. A view operating in 'pull' mode may know whether it is "clean" or "dirty" by listening to its update method, or it may not get any calls to its update method, and have to consult its parent to re-derive data when it is called. This mode is efficient when requests to a view for its data are infrequent compared to the update frequency of its parent's data. For example, a temperature sensor may be changing on a near-continuous basis, and a view which derives some quantity from that sensor may be queried irregularly. It is most efficient for that view to operate in pull mode, and only update itself when it is asked by some consumer for its derived quantity. It then asks the temperature sensor for the current temperature, does its derivation, and returns to the requester. To feed views that are registered with it, a view should only call the update method on its child views when its own data has changed. If it receives an update which results in no change to its data, it should not update any children views.
• com.eteks.sweethome3d.viewcontroller.View
  An MVC view created and controlled by a controller. @author Emmanuel Puybaret
• com.firefly.mvc.web.View
• com.firefly.template.View
• com.foundationdb.ais.model.View
• com.github.rnewson.couchdb.lucene.couchdb.View
• com.google.collide.client.ui.tooltip.Coachmark.View
• com.google.devtools.depan.eclipse.visualization.View
  Widget-like object that encapsulates the OGL rendering on behalf of the ViewEditor. Hides the {@link GLPanel} and other OGL artifacts from the{@link ViewEditor}. @author ycoppel@google.com (Yohann Coppel)
• com.habitsoft.kiyaa.views.View
  A user interface component that can load and save its state on demand.
• com.skymobi.monitor.model.View
  @author Hill.Hu
• com.starbase.starteam.View
• com.szuppe.jakub.view.View
  @author Jakub Szuppe
• com.tivo.hme.sdk.View
• com.vaadin.navigator.View
  Interface for all views controlled by the navigator. Each view added to the navigator must implement this interface. Typically, a view is a {@link Component}. @author Vaadin Ltd @since 7.0
• com.xith3d.scenegraph.View
• com.yammer.dropwizard.views.View
• com.zaranux.os.client.ui.View
• diva.gui.View
  View is an interface that captures the notion of a view on a document in a graphical application. Typically, there are one or more views on a particular document, or even on different parts of the document (such as discrete pages), although this is not necessarily so. Each application will typically create one or more implementations of this interface for the types of documents it can work with. @author Michael Shilman @version $Id: View.java,v 1.11 2005/07/08 19:55:12 cxh Exp $ @Pt.AcceptedRating Red
• edu.hawaii.ics.csdl.jupiter.file.preference.View
  3.org/2001/XMLSchema}anyType"> <sequence> <element ref="{}Phase" maxOccurs="3" minOccurs="3"/> </sequence> <attribute ref="{}default"/> </restriction> </complexContent> </complexType>
• event_manager.views.View
  @author uzzaldevkota
• gov.nasa.arc.mct.gui.View
  Implements a skeleton of a view. Component developers should derive from this class to implement their own view manifestation classes.
• gov.nasa.worldwind.View
• hudson.model.View
  Encapsulates the rendering of the list of {@link TopLevelItem}s that {@link Jenkins} owns.

  This is an extension point in Hudson, allowing different kind of rendering to be added as plugins.

  Note for implementors

  • {@link View} subtypes need the newViewDetail.jelly page,which is included in the "new view" page. This page should have some description of what the view is about.

  @author Kohsuke Kawaguchi @see ViewDescriptor @see ViewGroup
• io.dropwizard.views.View
  A Dropwizard view class.
• it.uniroma1.dptu.stan.gui.View
  @author Giampaolo
• javax.media.j3d.View
  The View object contains all parameters needed in rendering a three dimensional scene from one viewpoint. A view contains a list of Canvas3D objects that the view is rendered into. It exists outside of the scene graph, but attaches to a ViewPlatform leaf node object in the scene graph. It also contains a reference to a PhysicalBody and a PhysicalEnvironment object.

  The View object is the main Java 3D object for controlling the Java 3D viewing model. All of the components that specify the view transform used to render to the 3D canvases are either contained in the View object or in objects that are referenced by the View object.

  Java 3D allows applications to specify multiple simultaneously active View objects, each controlling its own set of canvases.

  The Java 3D View object has several instance variables and methods, but most are calibration variables or user-helping functions. The viewing policies defined by the View object are described below.

  Policies

  The View object defines the following policies:

  • View policy - informs Java 3D whether it should generate the view using the head-tracked system of transformations or the head-mounted system of transformations. These policies are attached to the Java 3D View object. There are two view policies:
  • SCREEN_VIEW - specifies that Java 3D should compute a new viewpoint using the sequence of transforms appropriate to screen-based head-tracked display environments (fish-tank VR/portals/VR-desks). This is the default setting.
  • HMD_VIEW - specifies that Java 3D should compute a new viewpoint using the sequence of transforms appropriate to head mounted display environments. This policy is not available in compatibility mode (see the setCompatibilityModeEnable method description).

  • Projection policy - specifies whether Java 3D should generate a parallel projection or a perspective projection. This policy is attached to the Java 3D View object. There are two projection policies:
  • PARALLEL_PROJECTION - specifies that a parallel projection transform is computed.
  • PERSPECTIVE_PROJECTION - specifies that a perspective projection transform is computed. This is the default policy.

  • Screen scale policy - specifies where the screen scale comes from. There are two screen scale policies:
  • SCALE_SCREEN_SIZE - specifies that the scale is derived from the physical screen according to the following formula (this is the default mode):
  screenScale = physicalScreenWidth / 2.0

  • SCALE_EXPLICIT - pecifies that the scale is taken directly from the user-provided screenScale attribute (see the setScreenScale method description).

  • Window resize policy - specifies how Java 3D modifies the view when users resize windows. When users resize or move windows, Java 3D can choose to think of the window as attached either to the physical world or to the virtual world. The window resize policy allows an application to specify how the view model will handle resizing requests. There are two window resize policies:
  • VIRTUAL_WORLD - implies that the original image remains the same size on the screen but the user sees more or less of the virtual world depending on whether the window grew or shrank in size.
  • PHYSICAL_WORLD - implies that the original image continues to fill the window in the same way using more or less pixels depending on whether the window grew or shrank in size.

  • Window movement policy - specifies what part of the virtual world Java 3D draws as a function of window placement on the screen. There are two window movement policies:
  • VIRTUAL_WORLD - implies that the image seen in the window changes as the position of the window shifts on the screen. (This mode acts as if the window were a window into the virtual world.)
  • PHYSICAL_WORLD - implies that the image seen in the window remains the same no matter where the user positions the window on the screen.

  • Window eyepoint policy - comes into effect in a non-head-tracked environment. The policy tells Java 3D how to construct a new view frustum based on changes in the field of view and in the Canvas3D's location on the screen. The policy only comes into effect when the application changes a parameter that can change the placement of the eyepoint relative to the view frustum. There are three window eyepoint policies:
  • RELATIVE_TO_SCREEN - tells Java 3D to interpret the eye's position relative to the entire screen. No matter where an end user moves a window (a Canvas3D), Java 3D continues to interpret the eye's position relative to the screen. This implies that the view frustum changes shape whenever an end user moves the location of a window on the screen. In this mode, the field of view is read-only.
  • RELATIVE_TO_WINDOW - specifies that Java 3D should interpret the eye's position information relative to the window (Canvas3D). No matter where an end user moves a window (a Canvas3D), Java 3D continues to interpret the eye's position relative to that window. This implies that the frustum remains the same no matter where the end user moves the window on the screen. In this mode, the field of view is read-only.
  • RELATIVE_TO_FIELD_OF_VIEW - tells Java 3D that it should modify the eyepoint position so it is located at the appropriate place relative to the window to match the specified field of view. This implies that the view frustum will change whenever the application changes the field of view. In this mode, the eye position is read-only. This is the default setting.
  • RELATIVE_TO_COEXISTENCE - tells Java 3D to interpret the eye's position in coexistence coordinates. In this mode, the eye position is taken from the view (rather than the Canvas3D) and transformed from coexistence coordinates to image plate coordinates for each Canvas3D. The resulting eye position is relative to the screen. As in RELATIVE_TO_SCREEN mode, this implies that the view frustum changes shape whenever an end user moves the location of a window on the screen. In this mode, the field of view is read-only.

  • Front and back clip policies - specifies how Java 3D interprets clipping distances to both the near and far clip planes. The policies can contain one of four values specifying whether a distance measurement should be interpreted in the physical or the virtual world and whether that distance measurement should be interpreted relative to the physical eyepoint or the physical screen. The front and back clip policies are specified separately. The front clip policy determines where Java 3D places the front clipping plane. The back clip policy determines where Java 3D places the back clipping plane. The values for both front and back clipping planes are:
  • VIRTUAL_EYE - specifies that the associated distance is from the eye and in units of virtual distance.
  • PHYSICAL_EYE - specifies that the associated distance is from the eye and in units of physical distance (in meters). This is the default policy for both front and back clipping.
  • VIRTUAL_SCREEN - specifies that the associated distance is from the screen and in units of virtual distance.
  • PHYSICAL_SCREEN - specifies that the associated distance is from the screen and in units of physical distance (in meters).

  • Visibility policy - specifies how visible and invisible objects are drawn. There are three visibility policies:
  • VISIBILITY_DRAW_VISIBLE - only visible objects are drawn (this is the default).
  • VISIBILITY_DRAW_INVISIBLE - only invisible objects are drawn.
  • VISIBILITY_DRAW_ALL - both visible and invisible objects are drawn.

  • Transparency sorting policy - specifies whether and how transparent objects are sorted. Sorting multiple transparent objects is necessary to avoid artifacts caused by overlapping transparent objects. There are two transparency sorting policies:
  • TRANSPARENCY_SORT_NONE - no depth sorting of transparent objects is performed (this is the default). Transparent objects are drawn after opaque objects, but are not sorted from back to front.
  • TRANSPARENCY_SORT_GEOMETRY - transparent objects are depth-sorted on a per-geometry basis. Each geometry object of each transparent Shape3D node is drawn from back to front. Note that this policy will not split geometry into smaller pieces, so intersecting or intertwined objects may not be sorted correctly. The method used for determining which geometry is closer is implementation dependent.

  Projection and Clip Parameters

  The projection and clip parameters determine the view model's field of view and the front and back clipping distances.

  • Field of view - specifies the view model's horizontal field of view in radians, when in the default non-head-tracked mode. This value is ignored when the view model is operating in head-tracked mode, or when the Canvas3D's window eyepoint policy is set to a value other than the default setting of RELATIVE_TO_FIELD_OF_VIEW.
  • Front clip distance - specifies the distance away from the clip origin, specified by the front clip policy variable, in the direction of gaze where objects stop disappearing. Objects closer than the clip origin (eye or screen) plus the front clip distance are not drawn. Measurements are done in the space (physical or virtual) that is specified by the associated front clip policy parameter.
  • Back clip distance - specifies the distance away from the clip origin (specified by the back clip policy variable) in the direction of gaze where objects begin disappearing. Objects farther away from the clip origin (eye or screen) plus the back clip distance are not drawn. Measurements are done in the space (physical or virtual) that is specified by the associated back clip policy parameter. The View object's back clip distance is ignored if the scene graph contains an active Clip leaf node.

  There are several considerations to take into account when choosing values for the front and back clip distances.

  • The front clip distance must be greater than 0.0 in physical eye coordinates.
  • The front clipping plane must be in front of the back clipping plane, that is, the front clip distance must be less than the back clip distance in physical eye coordinates.
  • The front and back clip distances, in physical eye coordinates, must be less than the largest positive single-precision floating point value, Float.MAX_VALUE. In practice, since these physical eye coordinate distances are in meters, the values should be much less than that.
  • The ratio of the back distance divided by the front distance, in physical eye coordinates, affects Z-buffer precision. This ratio should be less than about 3000 to accommodate 16-bit Z-buffers. Values of 100 to less than 1000 will produce better results.

  Violating any of the above rules will result in undefined behavior. In many cases, no picture will be drawn.

  Frame Start Time, Duration, and Number

  There are five methods used to get information about system execution and performance:

  getCurrentFrameStartTime returns the time at which the most recent rendering frame started.

  getLastFrameDuration returns the duration, in milliseconds, of the most recently completed rendering frame.

  getFrameNumber returns the frame number for this view.

  getMaxFrameStartTimes retrieves the implementation-dependent maximum number of frames whose start times will be recorded by the system.

  getFrameStartTimes copies the last k frame start time values into the user-specified array.

  View Traversal and Behavior Scheduling

  The following methods control the traversal, the rendering, and the execution of the behavior scheduler for this view:

  startBehaviorScheduler starts the behavior scheduler running after it has been stopped.

  stopBehaviorScheduler stops the behavior scheduler after all currently-scheduled behaviors are executed.

  isBehaviorSchedulerRunning retrieves a flag that indicates whether the behavior scheduler is currently running.

  startView starts traversing this view and starts the renderers associated with all canvases attached to this view.

  stopView stops traversing this view after the current state of the scene graph is reflected on all canvases attached to this view.

  isViewRunning returns a flag indicating whether the traverser is currently running on this view.

  Note: The above six methods are heavy-weight methods intended for verification and image capture (recording). They are not intended to be used for flow control.

  Scene Antialiasing

  The following methods set and retrieve the scene antialiasing flag. Scene antialiasing is either enabled or disabled for this view. If enabled, the entire scene will be antialiased on each canvas in which scene antialiasing is available. Scene antialiasing is disabled by default.

  setSceneAntialiasingEnable sets the scene antialiasing flag.

  getSceneAntialiasingEnable returns the scene antialiasing flag.

  Note that line and point antialiasing are independent of scene antialiasing. If antialiasing is enabled for lines and points, the lines and points will be antialiased prior to scene antialiasing. If scene antialiasing is disabled, antialiased lines and points will still be antialiased.

  Note: Scene antialiasing is ignored in pure immediate mode, but is supported in mixed-immediate mode.

  Depth Buffer

  The following two methods enable and disable automatic freezing of the depth buffer for objects rendered during the transparent rendering pass (that is, objects rendered using alpha blending) for this view. If enabled, depth buffer writes are disabled during the transparent rendering pass regardless of the value of the depth-buffer-write-enable flag in the RenderingAttributes object for a particular node. This flag is enabled by default.

  setDepthBufferFreezeTransparent enables depth buffer freezing.

  getDepthBufferFreezeTransparent retrieves the depth buffer flag.

  Transparent objects include BLENDED transparent primitives and antialiased lines and points. Transparent objects do not include opaque objects or primitives rendered with SCREEN_DOOR transparency.

  Sensors

  The following methods retrieve the sensor's location in the virtual world:

  getSensorToVworld takes the sensor's last reading and generates a sensor-to-vworld coordinate system transform. This Transform3D object takes points in that sensor's local coordinate system and transforms them into virtual world coordinates.

  getSensorHotSpotInVworld retrieves the specified sensor's last hotspot location in virtual world coordinates.

  Compatibility Mode

  A camera-based view model allows application programmers to think about the images displayed on the computer screen as if a virtual camera took those images. Such a view model allows application programmers to position and orient a virtual camera within a virtual scene, to manipulate some parameters of the virtual camera's lens (specify its field of view), and to specify the locations of the near and far clipping planes.

  Java 3D allows applications to enable compatibility mode for room-mounted, non-head-tracked display environments, or to disable compatibility mode using the following methods. Camera-based viewing functions are only available in compatibility mode.

  setCompatibilityModeEnable turns compatibility mode on or off. Compatibility mode is disabled by default.

  getCompatabilityModeEnable returns the compatibility mode enable flag.

  Use of these view-compatibility functions will disable some of Java 3D's view model features and limit the portability of Java 3D programs. These methods are primarily intended to help jump-start porting of existing applications.

  Setting the Viewing Transform

  The View object provides the following compatibility-mode methods that operate on the viewing transform.

  setVpcToEc a compatibility mode method that specifies the ViewPlatform coordinates (VPC) to eye coordinates viewing transform.

  getVpcToEc returns the VPC.

  Setting the Projection Transform

  The View object provides the following compatibility-mode methods that operate on the projection transform:

  The setLeftProjection and setRightProjection methods specify a viewing frustum for the left and right eye that transforms points in eye coordinates to clipping coordinates.

  The getLeftProjection and getRightProjection methods return the viewing frustum for the left and right eye.

  Additional Information

  For more information, see the Introduction to the Java 3D API and View Model documents. @see Canvas3D @see PhysicalBody @see PhysicalEnvironment @see ViewPlatform @see TransparencyAttributes

• javax.swing.text.View

  A very important part of the text package is the View class. As the name suggests it represents a view of the text model, or a piece of the text model. It is this class that is responsible for the look of the text component. The view is not intended to be some completely new thing that one must learn, but rather is much like a lightweight component.

  By default, a view is very light. It contains a reference to the parent view from which it can fetch many things without holding state, and it contains a reference to a portion of the model (Element). A view does not have to exactly represent an element in the model, that is simply a typical and therefore convenient mapping. A view can alternatively maintain a couple of Position objects to maintain its location in the model (i.e. represent a fragment of an element). This is typically the result of formatting where views have been broken down into pieces. The convenience of a substantial relationship to the element makes it easier to build factories to produce the views, and makes it easier to keep track of the view pieces as the model is changed and the view must be changed to reflect the model. Simple views therefore represent an Element directly and complex views do not.

  A view has the following responsibilities:

  Participate in layout.

  The view has a setSize method which is like doLayout and setSize in Component combined. The view has a preferenceChanged method which is like invalidate in Component except that one can invalidate just one axis and the child requesting the change is identified.

  A View expresses the size that it would like to be in terms of three values, a minimum, a preferred, and a maximum span. Layout in a view is can be done independently upon each axis. For a properly functioning View implementation, the minimum span will be <= the preferred span which in turn will be <= the maximum span.

  

  The minimum set of methods for layout are:

  • {@link #getMinimumSpan(int) getMinimumSpan}
  • {@link #getPreferredSpan(int) getPreferredSpan}
  • {@link #getMaximumSpan(int) getMaximumSpan}
  • {@link #getAlignment(int) getAlignment}
  • {@link #preferenceChanged(javax.swing.text.View,boolean,boolean) preferenceChanged}
  • {@link #setSize(float,float) setSize}

  The setSize method should be prepared to be called a number of times (i.e. It may be called even if the size didn't change). The setSize method is generally called to make sure the View layout is complete prior to trying to perform an operation on it that requires an up-to-date layout. A view's size should always be set to a value within the minimum and maximum span specified by that view. Additionally, the view must always call the preferenceChanged method on the parent if it has changed the values for the layout it would like, and expects the parent to honor. The parent View is not required to recognize a change until the preferenceChanged has been sent. This allows parent View implementations to cache the child requirements if desired. The calling sequence looks something like the following:

  

  The exact calling sequence is up to the layout functionality of the parent view (if the view has any children). The view may collect the preferences of the children prior to determining what it will give each child, or it might iteratively update the children one at a time.

  Render a portion of the model.

  This is done in the paint method, which is pretty much like a component paint method. Views are expected to potentially populate a fairly large tree. A View has the following semantics for rendering:

  • The view gets its allocation from the parent at paint time, so it must be prepared to redo layout if the allocated area is different from what it is prepared to deal with.
  • The coordinate system is the same as the hosting Component (i.e. the Component returned by the {@link #getContainer getContainer} method).This means a child view lives in the same coordinate system as the parent view unless the parent has explicitly changed the coordinate system. To schedule itself to be repainted a view can call repaint on the hosting Component.
  • The default is to not clip the children. It is more efficient to allow a view to clip only if it really feels it needs clipping.
  • The Graphics object given is not initialized in any way. A view should set any settings needed.
  • A View is inherently transparent. While a view may render into its entire allocation, typically a view does not. Rendering is performed by traversing down the tree of View implementations. Each View is responsible for rendering its children. This behavior is depended upon for thread safety. While view implementations do not necessarily have to be implemented with thread safety in mind, other view implementations that do make use of concurrency can depend upon a tree traversal to guarantee thread safety.
  • The order of views relative to the model is up to the implementation. Although child views will typically be arranged in the same order that they occur in the model, they may be visually arranged in an entirely different order. View implementations may have Z-Order associated with them if the children are overlapping.

  The methods for rendering are:

  • {@link #paint(java.awt.Graphics,java.awt.Shape) paint}

  Translate between the model and view coordinate systems.

  Because the view objects are produced from a factory and therefore cannot necessarily be counted upon to be in a particular pattern, one must be able to perform translation to properly locate spatial representation of the model. The methods for doing this are:

  • {@link #modelToView(int,javax.swing.text.Position.Bias,int,javax.swing.text.Position.Bias,java.awt.Shape) modelToView}
  • {@link #viewToModel(float,float,java.awt.Shape,javax.swing.text.Position.Bias[]) viewToModel}
  • {@link #getDocument() getDocument}
  • {@link #getElement() getElement}
  • {@link #getStartOffset() getStartOffset}
  • {@link #getEndOffset() getEndOffset}

  The layout must be valid prior to attempting to make the translation. The translation is not valid, and must not be attempted while changes are being broadcasted from the model via a DocumentEvent.

  Respond to changes from the model.

  If the overall view is represented by many pieces (which is the best situation if one want to be able to change the view and write the least amount of new code), it would be impractical to have a huge number of DocumentListeners. If each view listened to the model, only a few would actually be interested in the changes broadcasted at any given time. Since the model has no knowledge of views, it has no way to filter the broadcast of change information. The view hierarchy itself is instead responsible for propagating the change information. At any level in the view hierarchy, that view knows enough about its children to best distribute the change information further. Changes are therefore broadcasted starting from the root of the view hierarchy. The methods for doing this are:

  • {@link #insertUpdate insertUpdate}
  • {@link #removeUpdate removeUpdate}
  • {@link #changedUpdate changedUpdate}

  @author Timothy Prinzing
• jfix.zk.View
  Wraps a generic value and a component. A View is to be used in a TableModel, when you want to display a complex component (or different label), although the table should use the given value for indexing, sorting and so on.
• lbms.azcatdest.gui.View
• liquibase.structure.core.View
• lmnd.model.command.View
• lotus.domino.View
• mallemuck.model.command.View
• multididdy_view.View
  @author chris
• net.datacrow.console.views.View
  The Swing presentation. A view uses a view component to render items. Any component implementing the IViewComponent interface can be used as a view component.
• net.gridshield.nexsm.entityclasses.View
  View definition class, created when reading the map view definition XML files. @author Sergio Guzmán Lorz
• net.infonode.docking.View
• net.sf.fysix.presentation.view.View
• net.sf.minuteProject.configuration.bean.model.data.View
• net.sf.minuteProject.configuration.bean.view.View
  @author Florian Adler
• net.sf.mpxj.View
  This interface represents a view of a set of project data that has been instantiated within an MS Project file. View data is instantiated when a user first looks at a view in MS Project. Each "screen" in MS Project, for example the Gantt Chart, the Resource Sheet and so on are views. If a user has not looked at a view (for example the Resource Usage view), information about that view will not be present in the MPP file.
• net.sourceforge.pebble.web.view.View
  Represents a view component and prepares the model for display. @author Simon Brown
• net.sourceforge.syncyoursecrets.gui.rcp.View
  The Class View links the content provider with the UI and associates a double-click with the PWEditor.
• org.apache.ambari.view.View
  Interface for main view class.
• org.apache.ddlutils.model.View
• org.apache.deltaspike.jsf.api.config.view.View
• org.apache.drill.exec.dotdrill.View
• org.apache.geronimo.monitoring.console.data.View
  @version $Rev: 720024 $ $Date: 2008-11-24 02:32:00 +0800 (Mon, 24 Nov 2008) $
• org.apache.hadoop.yarn.webapp.View
  Base class for all views
• org.apache.isis.viewer.dnd.View
• org.apache.isis.viewer.dnd.view.View
• org.apache.myfaces.extensions.cdi.core.api.config.view.View
• org.apache.oodt.cas.workflow.gui.perspective.view.View
  View abstract base class. @author bfoster @author mattmann
• org.apache.sentry.core.View
• org.apache.sentry.core.model.db.View
• org.apache.shindig.gadgets.spec.View
  Represents a Content section, but normalized into an individual view value after views are split on commas.
• org.apache.sling.discovery.impl.common.View
  DAO for a view stored in the repository.
• org.apache.struts2.sitegraph.entities.View
  TODO Describe View
• org.beryl.gui.View
• org.bs.mdi.View
• org.codinjutsu.tools.jenkins.model.View
• org.cruxframework.crux.core.rebind.screen.View
  Represents a Crux View at the application's server side. Used for GWT Generators. @author Thiago Bustamante
• org.cytoscape.view.model.View
• org.datastorm.gui.swt.View
• org.dmd.mvw.tools.mvwgenerator.extended.View
  The View class extends the basic View definition to provide a variety of consistency checking and the creation of various information required to format the View interface.

  The generated code from this falls into 3 main areas: the ViewIF and its associated ViewPresenterIF and the ViewBaseImpl.

  The ViewIF will contain the various viewMethods and will require the viewImports.

  The ViewPresenterIF will contain the various presenterMethods and presenterImports as well as any local event dependencies.

  The ViewBaseImpl will have dependencies on the events that it fires and the usesRunContextItem indications.

• org.eclipse.gmf.runtime.notation.View
• org.eclipse.jetty.io.View
• org.eclipse.papyrus.sysml.modelelements.View
  A representation of the model object ' View'.

  The following features are supported:

  • {@link org.eclipse.papyrus.sysml.modelelements.View#getViewPoint View Point}
  • {@link org.eclipse.papyrus.sysml.modelelements.View#getBase_Package Base Package}

  @see org.eclipse.papyrus.sysml.modelelements.ModelelementsPackage#getView() @model @generated
• org.ektorp.support.DesignDocument.View
• org.fao.geonet.services.metadata.View
  Retrieves a particular metadata. Access is restricted
• org.flexdock.view.View
  The {@code View} class is slightly incompatible with {@code JComponent}. Similar to JFC/Swing top-level containers, a {@code View} contains only acontent pane {@code Container} and a {@code Titlebar}. The content pane should contain all the components displayed by the {@code View}. As a convenience {@code add} and its variants, {@code remove(Component)} and{@code setLayout} have been overridden to forward to the{@code contentPane} as necessary. This means you can write:

   view.add(child); 

  And the child will be added to the contentPane. The content pane will always be non-null. Attempting to set it to null will cause the View to throw an exception. The default content pane will not have a layout manager set. @see javax.swing.JFrame @see javax.swing.JRootPane @author Christopher Butler @author Karl Schaefer
• org.gjt.sp.jedit.View
  A View is jEdit's top-level frame window.

  In a BeanShell script, you can obtain the current view instance from the view variable.

  The largest component it contains is an {@link EditPane} that in turncontains a {@link org.gjt.sp.jedit.textarea.JEditTextArea} that displays a{@link Buffer}. A view can have more than one edit pane in a split window configuration. A view also contains a menu bar, an optional toolbar and other window decorations, as well as docked windows.

  The View class performs two important operations dealing with plugins: creating plugin menu items, and managing dockable windows.

  • When a view is being created, its initialization routine iterates through the collection of loaded plugins and constructs the Plugins menu using the properties as specified in the {@link EditPlugin} class.
  • The view also creates and initializes a {@link org.gjt.sp.jedit.gui.DockableWindowManager}object. This object is responsible for creating, closing and managing dockable windows.

  This class does not have a public constructor. Views can be opened and closed using methods in the jEdit class. @see org.gjt.sp.jedit.jEdit#newView(View) @see org.gjt.sp.jedit.jEdit#newView(View,Buffer) @see org.gjt.sp.jedit.jEdit#newView(View,Buffer,boolean) @see org.gjt.sp.jedit.jEdit#closeView(View) @author Slava Pestov @author John Gellene (API documentation) @version $Id: View.java,v 1.111 2004/05/06 22:35:11 spestov Exp $
• org.graphstream.ui.swingViewer.View
• org.hsqldb.View
  Represents an SQL VIEW based on a query expression @author leptipre@users @author Fred Toussi (fredt@users dot sourceforge.net) @version 2.0.0 @since 1.7.0
• org.hsqldb_voltpatches.View
  Represents an SQL VIEW based on a query expression @author leptipre@users @author Fred Toussi (fredt@users dot sourceforge.net) @version 1.9.0 @since 1.7.0
• org.ifmo.clgp.view.View
  @author Brantner
• org.jboss.aerogear.controller.view.View
  A view in AeroGear consists of a path to a resource and optionally a model.

  The path could be to a jsp page, or any other type of template language file. @see ViewResolver
• org.jboss.dna.graph.query.validate.Schemata.View
• org.jboss.ejb3.jndi.binder.impl.View
  @author Carlo de Wolf
• org.jclouds.View
  {@link View} allows access to the provider-specific, or library-driven apibehind an abstraction. One backend context can support multiple views.

  For example, the {@code CloudStackContext} can be backend by both{@code ComputeServiceContext} and {@code LoadBalancerServiceContext}, as the api covers these features. @author Adrian Cole

• org.jgroups.View
  A view is a local representation of the current membership of a group. Only one view is installed in a channel at a time. Views contain the address of its creator, an ID and a list of member addresses. These adresses are ordered, and the first address is always the coordinator of the view. This way, each member of the group knows who the new coordinator will be if the current one crashes or leaves the group. The views are sent between members using the VIEW_CHANGE event @author Bela Ban @version $Id: View.java,v 1.20 2008/02/20 15:51:57 belaban Exp $
• org.jitterbit.application.ui.view.View
  A View represents what is currently being displayed in the main panel in the UI.

  Each View implementation must have a constructor that takes an ApplicationWindow as its single argument. @author Torgil Zethson

• org.kitesdk.data.View
  A {@code View} is a subset of a {@link Dataset}. A {@code View} defines a space of potential storage keys or a partitionspace. Views can be created from ranges, partial keys, or the union of other views. @param < E> The type of entities stored in the {@code Dataset} underlying this{@code View}. @since 0.9.0
• org.modeshape.jcr.query.validate.Schemata.View
• org.mojavemvc.views.View

  Represents the renderable view in the model-view-controller pattern. Users can create their own renderable views by implementing this class, and returning a concrete instance in an action method.

  @author Luis Antunes
• org.molgenis.model.elements.View
  This class describes an updatable view, which shows two or more entities. This can only be a liniair path in the entity graph otherwise updates are undefined. @author RA Scheltema @author MA Swertz @version 1.0.0
• org.mortbay.io.View
  A View on another buffer. Allows operations that do not change the _content or indexes of the backing buffer. @author gregw
• org.netmelody.cieye.spies.jenkins.jsondomain.View
• org.nutz.dao.entity.annotation.View
• org.nutz.mvc.View
  视图接口 @author zozoh(zozohtnt@gmail.com)
• org.openntf.domino.View
  The Interface View.
• org.palo.viewapi.View
• org.parosproxy.paros.view.View
  To change the template for this generated type comment go to Window - Preferences - Java - Code Generation - Code and Comments
• org.pentaho.cdf.views.View
  @author pdpi
• org.shiftone.jrat.core.spi.ui.View
  @author $Author: jeffdrost $ @version $Revision: 1.8 $
• org.sonar.api.web.View
  @since 1.11
• org.sonatype.nexus.componentviews.View
  A binding between a view name (which is part of the URL), and a list of {@link RequestMatcher request matchers}, each of which can delegate to a chain of {@link Handler}s. @since 3.0
• org.springframework.data.couchbase.core.view.View
• org.springframework.richclient.application.View
  A view is a panel-like component displayed within an area on the page associated with an application window. There can be multiple views per page; a single view can only be displayed once on a single page. View instances encapsulate the creation of and access to the visual presentation of the underlying control. A view's descriptor -- which is effectively a singleton -- can be asked to instantiate new instances of a single view for display within an application with multiple windows. In other words, a single view instance is never shared between windows. @author Keith Donald
• org.springframework.web.servlet.View
  mazon.com/exec/obidos/tg/detail/-/0764543857/">Expert One-On-One J2EE Design and Development by Rod Johnson (Wrox, 2002).

  View implementations may differ widely. An obvious implementation would be JSP-based. Other implementations might be XSLT-based, or use an HTML generation library. This interface is designed to avoid restricting the range of possible implementations.

  Views should be beans. They are likely to be instantiated as beans by a ViewResolver. As this interface is stateless, view implementations should be thread-safe. @author Rod Johnson @author Arjen Poutsma @see org.springframework.web.servlet.view.AbstractView @see org.springframework.web.servlet.view.InternalResourceView

• org.springframework.webflow.execution.View
  Allows the client to participate in flow execution. Encapsulates behavior to send the client an appropriate response and handle the resulting event once the client responds. @author Keith Donald @see ViewFactory
• org.structr.common.View
  Defines a named set of {@link Property} keys for a given type. This class isneeded for the REST server to define inheritable "views" for an entity. See the example archetype for more information. @author Christian Morgner
• org.thechiselgroup.choosel.core.client.visualization.View
• org.timepedia.chronoscope.client.canvas.View
  View encapsulates platform specific behaviors, such as graphics rendering, timing, and CSS property retrieval. Views support asynchronous creation, therefore, the proper use of a view is to postpone operations until ViewReadyCallback is invoked.
• org.uiautomation.ios.inspector.views.View
• org.waveprotocol.wave.client.wavepanel.view.View
  Base interface for all views of wave panel components.
• org.wicketstuff.openlayers3.api.View
  Provides an object that models a view of a map.
• org.wiztools.restclient.View
  This is the callback interface for RequestExecuter. An implementation of this interface needs to be passed to RequestExecuter (actually, a number of View implementation could be passed to RequestExecuter--it is an vararg parameter). The callback methods will be called during various stages in request processing. @author schandran
• pl.edu.pw.elka.mmarkiew.view.View
  Game view @author Kajo
• pl.eternalsh.simplecalc.view.View
  View: manages application's windows (here: only one window), so the controller doesn't need to know windows hierarchy nor their structure. @author Amadeusz Kosik
• pt.opensoft.dbaccess.View
• sw_digitalworks.View
• view.View
• y.view.View

Examples of org.wicketstuff.openlayers3.api.View

Examples of org.wiztools.restclient.View

Examples of pl.edu.pw.elka.mmarkiew.view.View

Examples of pl.eternalsh.simplecalc.view.View

Examples of pt.opensoft.dbaccess.View

Examples of sw_digitalworks.View

Examples of view.View

Examples of y.view.View