| Home >> All >> com >> jcorporate >> expresso >> services |
Package Samples:
• com.jcorporate.expresso.services.controller.dbmaint: This package contains Controller objects to perform basic administration functions within Expresso, including security maintenance, testing, and default error handling.
• com.jcorporate.expresso.services.controller.configuration: This package contains Controller objects to perform basic administration functions within Expresso, including security maintenance, testing, and default error handling.
• com.jcorporate.expresso.services.controller.tests
• com.jcorporate.expresso.services.crontab.tests
• com.jcorporate.expresso.services.dbobj.tests
• com.jcorporate.expresso.services.html
• com.jcorporate.expresso.services.test
• com.jcorporate.expresso.services.controller
• com.jcorporate.expresso.services.controller.ui
• com.jcorporate.expresso.services.taglib
• com.jcorporate.expresso.services.job
• com.jcorporate.expresso.services.servlet
• com.jcorporate.expresso.services.asyncprocess
• com.jcorporate.expresso.services.crontab
• com.jcorporate.expresso.services.dbobj
• com.jcorporate.expresso.services.validation
Classes:
• SecurityDBObject: SecurityDBObject.java this object provides a means to control the DB context via Setup values. subclasses will ignore any context except that found in Setup. You probably will never create a subclass of SecurityDBObject yourself--it is a framework tool embedded in the Expresso security system. The idea is to provide a flexible way to redirect authentication classes to another database context. For example, consider a situation where there are two Expresso applications, and you wanted the second application to rely on the first in order to authenticate users and otherwise supply user information. ...
• DefaultAsyncProcessor: This is a default implementation of the AsyncProcessor. It has specific claim timeout, specific threads and queue size, and a particular order of dealing with things. A different kind of implementation might, for example, dispatch the requests to another machine for processing and return the result. This asynchronous processor relies on the set up tables for the following parameters. parameters are missing from the set up table then the default values will be used instead. These parameters are: AsyncClaimTimeout : when the job is completed there is always the chance that it will never be claimed ...
• SimpleRegistration: SimpleRegistration Controller. This is the implementation example of Registration. Depends on: Login Controller Email Validator Registration Validator Reg Domain DBObjects Reg Domain DBObject Map The following states are the usual entry points into the registration controller showDBMenu - For users that want to change/edit their registraiton info promptAddRecord - Where we prompt the user to fill out the registration information promptSelfRegister - Where we prompt for login information et.al. from users who wish to self-register promptApproval - For approval administrators only. Shows the registration ...
• MediaDBObject: A MediaDBObject is a DBObject intended to be used for storage of media objects directly in the database. It facilitates generic storage by automatically creating filename and MimeType fields that map to the MimeTypes table for easy downloading. This allows for the ability to store more than one media type in the same table while still allowing the Application to appropriately deal with each MimeType. This data object conveniently stores and retrieves Binary Large OBjects (BLOBS) or Character Large OBjects (CLOBS). Performance note: Each blob field access requires one more round trip to the database ...
• TestSystemInitializer: This class loads the standard Expresso configuration upon startup. You use this class by passing the following arguments to the Virtual Machine system properties junit.argv.webAppDir Where is the webapp directory located. required junit.argv.configDir The full path name of the configuration directory. required junit.argv.testContext The name of the data context to perform the destructive database tests to. optional if no testContext is specified then the context name is set to " test " as the default context expresso.logDir  : Directory to write expresso related ...
• MimeTypes: This table provides for mapping between files and mime types. Here we try to put every mime type that we are aware of and provide the following services: Output Stream Content Type settings. Useful for content management, or file servers. Once the system knows what the mime type of the application is, it can be set for serving to downstream browsers. File to icon mapping. See this in action for the download controller. Useful for that fancy directory browsing where the appropriate icons appear for each data type javax.activation integration- MimeTypes extends the Activation javax.activation.MimetypesFileTypeMap ...
• DBMaint: Controller that enables basic maintenance (add/update/delete) of any DBObject DBMaint acts more as a controller for allowing operations on DBObjects. The real work for adding, deleting, searching and updating is carried out by a series of classes that are dynamically instantiated and live in the com.jcorporate.expresso.core.servlet.commands package. These classes can be extended to add additional functionality. When tracking down code functionality, the core states are in package: com.jcorporate.expresso.services.dbmaint The only state handlers embedded in the class are minimalistic classes ...
• WizardFormStack: Utility class for wizard type interfaces. Call processNewState() for each 'prompt' state. Ignore for each process state. Typical Usage WizardFormStack.getInstance(request).processNewState(this, request,response); Transition backBtn = WizardFormStack.getInstance(request).getPreviousTransition(); if (backBtn != null) { response.add(backBtn); } The issues with using this class include: (1) The WizardFormStack does not work across multiple controllers. (2) You must not use a parameter named 'back' in your form since this is required to detect if you've gone backwards in the workflow.
• FormActionTag: Use FormActionTag for the "action=" part of the <form> tag. The tag takes a transition and automatically maps it to the appropriate URL that should be used for the form. This tag's parameters mirror that of JSTL's <c:out/> tag with the only exception being that the 'escapeXML' attribute is not available. The tag parameters should evaluate to a string. The way to do this with a Transition is to evaluate to the transition and call getMapping() So an example would be:
• ELTagSupport: ELTag support provides a wrapper around the actual JSTL-el parsers. Once the JSP APIs advance, we will basically be able to call the JSP system directly rather than rely on the Apache JSTL parser. The goal here will be to switch relatively painlessly. Typical usage: String myVal = (String)ELTagSupport.getInstance().evaluate("test", "${controllerResponse.namedInputs[\"Test\"].defaultValue}", java.lang.String.class, this, pageContext);
• ValidationEntry: This class abstracts the storing of the data that goes along with any particular validation operation. This class also provides functions for a validation request to be created in the first place. In this first incarnation, this class stores all the data using DBObjects. If warranted at a later time, the ideal way to change the functionality by making this class abstract and then implementing DBValidationEntry and XMLValidationEntry or whatever. Most of the methods in this class are "protected", so that minor changes can be handled by simply extending this class and overridining the necessary methods ...
• ButtonParams: Use ButtonParamsTag right after putting a button on a form that maps to a particular Transition. The ButtomParams tag will add a hidden form field that will contain all the appropriate parameters associated with the Transition. The only supported attribute is 'value', there is no default given, since it is critical that it maps to an existing transition. value parameter should map to a Transition. Example:
• ValidationController: This is an Expresso controller that responds to the validator clicking on an URL provided to him from the notification from the validation job. It has the responsibility of extracting the parameters from the request, resurrecting the Validation entry using the validation-db-context and the validation id. It then compares the code provided in the request with that stored in the validation entry. If the code matches, then the application-supplied validation handler is called to allow the validated-process to go through.
• ValidationJob: This class implements an Expresso Job, which is a background task, to decouple the user selecting some action that requires validation, from the mechanics of storing the user/application-selected parameters and starting the processing. The primary reason for using a Job here is to allow load-balancing if required, and also to make the UI appear much faster (since otherwise the user would have to wait until the entire function finished). The submission of the job is done using the ValidationEntry class.
• JobQueue: Copyright 1999, 2000, 2001 Jcorporate Ltd. Jobqueue is a table that contains all the jobs, or asynchronous tasks, to be executed. This table works with JobQueueParam table as a detail table so that multiple parameters per job may be specified. The JobHandler checks the JobQueue table every so often to see if there's a job there waiting to be used. If it is, then the JobHandler server takes ownership of that JobQueue entry, constructs a job object based upon it and executes the appropriate job
• TransitionName: The TransitionName tag is what you insert at the value for the name of a submit button on a form where you wish for the transition to appear. This is necessary since a special button naming convention is used in Expresso. For the 'value' attribute supply a JSTL-EL expression that evaluates to a Transition object, and the tag will output the button name from that Be sure to add the appropriate button hidden parameters after your submit button by using the 'buttonparams' tag.
• RegistrationDomain: A registration domain defines a registration context. A DB context can have multiple registration contexts. Each context defines a controller that takes care of registration for that context. Each context also defines whether the extended registration beyond that provided by the User object is required for the domain or not. The map of registration objects per registration domain is provided by the RegistrationObjectMap class. Creation date: (5/15/2001 12:26:11 PM)
• DBObjSecurityTests: Perform unit tests to determine if the db object security is working correctly. These unit tests create a temporary user entry, assign it certain permissions, verifying that the permissions are granted appropriately, then remove the permissions and check that they are removed. Note that this test requires that the default UserDBObj implentation of User is used - e.g. don't have LDAP enabled when this test is run.
• Registration: Registration Controller. Provides services for self-registering people... ie sign-up pages on websites. This is the abstract class from which all Registration class should extend from. This class contains most of the non prompt/process methods Depends on: Login Controller Email Validator Registration Validator
• UserPreferenceDef: This object defines the available user preference definitions. The populateDefaultValues methods of various db objects can populate this table to "register" the fact that they are providing preference values that the user can set. The actual preferences are set in UserPreference and the valid values (if any are defined) are specified in UserPreferenceVal
• ClearOldValidation: This job clears all expired validation queue entries. It is typically run once a week or so to clean out unwanted validation items to keep the size of the table down and remove any potential referential integrity issues. A Job is an asynchronous task that is performed, run and the results of the job are eventually mailed to the queuing user.
• EditUserPreference: Allow a user to edit his/her user preferences, optionally restricting to a single set of preferences. Objects that have user preferences defined can call this controller, passing their classname, to allow editing of preferences specific to that object. Calling without specifying a classname allows editing of all of the user's own preferences.
• LoginController: Main Login Controller - used for login/logout and basic interaction with the registration system. This class recognizes the 'registration' classHandler name in the expresso-config.xml It uses the classname in that field to construct and forward to the appropriate registration class. Creation date: (5/12/2001 6:36:41 PM)
• SchemaManager: This class reference counts references to various Schema objects. When a reference count drops to zero, the schema is deleted. [If it's not marked read only] If it is marked readonly, then the schema is created, but not deleted. [Makes for much faster checking when running unit tests on, say, a single controller]
• Add: Displays a form for a new DBObject record. This state does not actually perform the adding of the dbobject to the database, instead it creates a blank form that is pre-populated with the default values of the given DBObject. The actual class that does the updating is AddUpdate
| Home | Contact Us | Privacy Policy | Terms of Service |