[ Index ]
 

Code source de LifeType 1.2.4

Accédez au Source d'autres logiciels libres

Classes | Fonctions | Variables | Constantes | Tables

title

Body

[fermer]

/class/action/ -> action.class.php (sommaire)

\defgroup Action Action in pLog are the classes that implement the application logic. Action classes are always instantiated and executed by the Controller after a parameter in an incoming request matched an action class as specified in the action class map.

Poids: 300 lignes (11 kb)
Inclus ou requis:0 fois
Référencé: 2 fois
Nécessite: 0 fichiers

Définit 1 class

Action:: (13 méthodes):
  Action()
  setPreviousAction()
  getPreviousAction()
  perform()
  validate()
  validationErrorProcessing()
  setValidationErrorView()
  registerFieldValidator()
  registerField()
  getView()
  setCommonData()
  setSuccess()
  canPerform()


Classe: Action  - X-Ref

\ingroup Action

The base most basic action class is Action, which provides some common code and the Action::perform()
method which should be implemented by child classes wishing to provide some business logic. At the end
of the method, an Action class is expected to generate a valid View object (or a child class of View)
that will be used by the Controller to render some contents to be sent to the client.

Action classes are expected to at least provide their own logic in the Action::perform() method. In previous
versions of pLog it was also necessary to provide data validation logic in the Action::validate()
method, but that is not necessary anymore (albeit possible if needed) since the introduction of the
new data validation framework (See the FormValidator class and the Validator and Validator_Rules modules)
The Action::validate() method now provides some code of its own that triggers the data validation process
if there is any data to be validated.

There is a lot more information about the data validation framework here: http://wiki.plogworld.net/index.php/PLog_1.0/Forms_and_data_validation

The View object that Action classes must create can be set via the private attribute
Action::_view or te method Action::setView(), though the first one is the most widely used
throughout the core code.

Please keep in mind that it is advisable to call the Action::setCommonData() method at the very end
of the Action::perform() method in our custom classes because it needs to perform some extra
operations right before the view is sent back to the controller.
Action( $actionInfo, $httpRequest )   X-Ref
Constructor.

param: actionInfo An ActionInfo object contaning information about the action
param: httpRequest the HTTP request.

setPreviousAction( $previousAction )   X-Ref

param: previousAction a valid Action object
return: Always true

getPreviousAction()   X-Ref
returns the reference to the previous action in the process flow

return: A valid Action object, or null if there is no previous action

perform()   X-Ref
Receives the HTTP request from the client as parameter, so that we can
extract the parameters and perform our business logic.

The result of this will be a view, which will normally be the output of the
processing we just did or for example an error view showing an error message.
Once we have completed processing, the controller will call the getView() method
to get the resulting view and send it back to the customer.

return: Returns nothing

validate()   X-Ref
This method can be used for data validation and is <b>always</b> executed
before perform(). If it returns 'true', execution will continue as normal. If it
returns 'false', the process will be stopped and the current contents of the
view will be returned. If the view is empty, an exception will be thrown.

As of pLog 1.0, it is not necessary to implement data validation code here and it is recommended
to use the data validation framework (see methods Action::registerFieldValidator() and related) There is
more information about the data validation framework in the wiki: http://wiki.plogworld.net/index.php/PLog_1.0/Forms_and_data_validation.

With the default code provided in the Action::validate() method, the callback method Action::validationErrorProcessing()
will be called and after that, the view set via the Action::setValidationErrorView() will be used to
generate the contents of the error message.

return: Returns true if data is correct or false otherwise. See above for more details.

validationErrorProcessing()   X-Ref
This method will be called when a validation error happens. Child classes are
free to extend or reimplement this one and can be used as some sort of a trigger
in order to do some cleanup if needed.

Ê@return nothing

setValidationErrorView( $view )   X-Ref
sets the view that will be shown in case there is an error during
the validation process... It makes things a bit easier for us when
it comes to validate data. This view will only be used if validate() generates a validation
error or if we force the action to generate an error via Action::setSuccess()

param: view A valid View object
return: Always true

registerFieldValidator( $fieldName, $validator, $onlyIfAvailable = false )   X-Ref
registers a new validator, for validating data coming from fields

param: fieldName The name of the field from the form that we're going to validate
param: validator A valid class inheriting from the Validator base class and that implements
param: onlyIfAvailable validate this field only if its value is not emtpy        
return: Always true

registerField( $fieldName )   X-Ref
registers a new field whose value should be available to the view/template in case
it needs to be reshown.Those fields that haven't been registered, will *not* be shown
when rerunning the view.

param: fieldName The name of the field from the form that we're going to register

getView()   X-Ref
This function does not need to be reimplemented by the childs of this class.
It just returns the resulting view of the operation.

return: A valid View object

setCommonData( $copyFormValues = false )   X-Ref
we can do things here that are common to all the views. This method must be called just before
the Action::perform() method has finished its processing since most of the child Action
classes use it to do some kind of post-processing.

param: copyFormValues Whether the values from fields that were registered via
return: Always true

setSuccess( $success )   X-Ref
This method can be used to trigger validation errors even if they did not really happen, or
to disable errors if they happened.

param: success Whether to force or unforce an error

canPerform()   X-Ref
This method will be executed to check whether this action can be executed or not. This means
that this method will be executed before the perform() method. If this method returns 'false',
the controller will then load the action defined via the Controller::setCannotPerformAction()

return: True if the controller is allowed to call the Action::perform() action or not.



Généré le : Mon Nov 26 21:04:15 2007 par Balluche grâce à PHPXref 0.7
  Clicky Web Analytics