Download Validator

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Versant Object Database wikipedia , lookup

Clusterpoint wikipedia , lookup

Database model wikipedia , lookup

Transcript
Core
• These classes are at the lowest level of the pLog
object model. Included here is the Object class,
which is the base class from which all other
classes in pLog inherit.
• The Core package also includes classes for
dealing with simulated exceptions in PHP4
(they are disabled in PHP5 and the framework
will use native exceptions), and a bit of reflection
too using PHP4's reflection features.
DAO
• DAO stands for "Data Access Object" and
represents a data model according to the MVC
architecture.
• DAO classes isolate developers of all the
intricacies of the database structure.
• Otherwise, developers would need to write an
SQL query every time we need to load an article
from the database.
• In general, DAO classes provide access to
reading, updating and removing data from the
database.
DAO
• In pLog, we usually have two classes per entity:
• a smaller one that contains no database access
logic and that only contains the information
necessary (usually, it represents a row from the
database)
• the second will be a bigger class that includes
SQL code and database logic and that provides
all the methods outlined above (read, update
and remove from the database)
What’s MVC?
• 早從 1970 年代末期,MVC (Model-ViewController) 架構漸漸成為常用的 Design
Pattern,特別是在物件導向的 GUI 方面。
MVC 的設計哲學是:將資料 (Model)、外
觀 (View)、以及操作 (Controller) 三者分開,
如此一來,可以輕易地換掉任何一者,而
不會更動到另外兩者。
Logger
• The logger package takes care of
providing logging facilities for the pLog API.
• It is a very simple API but on the other
hand, it follows some of the principles
establishes by log4j and log4php, with a
very similar system of layouts, formatters
and appenders.
Gallery
•
1.
2.
3.
4.
The pLog Gallery module encapsulates all the
logic necessary for:
Dealing with files and their places in disk
Dealing with albums, which are virtual groups
of disks
Automatic generation of thumbnails and
medium-sized thumbnails, according to our
configuration
Automatic extraction of metadata from a set of
supported formats. This is achieved via the
getID3 library.
Getid3
• Extracts information from supported files,
such as metadata from images.
Gallery_resizer
• Please use the proxy class GalleryResizer that
should be used to generate thumbnails, instead
of using directly classes such as
GalleryGdResizer or
GalleryImageMagickResizer.
• This class will check from the configuration the
values of the parameters thumbnail_method
and thumbnail_format and load the appropiate
thumbnail generator class.
Locale
• The Locale module is used for localization purposes. Its
main class is the Locale class that is capable of loading
very simple php files containing a big array of string
identifiers and their translations. The main method of the
class is the Locale::tr() that given a string identifier, will
return the translated version.
• Locale files can also specify default encodings and very
basic date and time formats (this will be improved in next
version) At the moment it is also possible to use right-toleft languages even though there is none available yet.
• The Locales class is the preferred way to load
translations from disk since it has caching mechanisms
so that we don't have to load the data everytime from
disk.
Config
• The Config package is the central place
where all configuration settings are stored
in pLog.
File
• The File module provides some classes to
deal with files.
• The File class is the most useful once,
since provides OOP wrappers around
some PHP functions that work with files.
File_Unpacker
• This module implements support for easily
unpacking files compressed
with .zip, .tar.gz, .tar.bz2 and .rar provided
that all the binary tools are available.
• The main Unpacker class is a proxy class
that will take care of finding the right
subclass according to the package type.
Database
• Database-related objects
Forms
• The Form class helps in data validation
Security
• The Security module provides a basic
implementation of a generic Pipeline to
which we can register "filters", which will
carry out specific actions.
• Any of the filters can interrupt the
processing, depending on the logic of the
filter.
XML
• This module includes several external
libraries and modules that deal with XML
content including parsing, RSS and so on.
Controller
• The controller is the central piece of the
MVC pattern, and the object that takes
care of transferrign the process flow to the
right action class based on a certain value
in the incoming request.
Mail
• Module that allows to easily send email
messages from within pLog.
Bayesian
• The Bayesian module provides the logic
that implements a spam filter based on
Bayesian filtering techniques.
• The filter is trained via the user's own
posts (they are considered "safe" content)
and the negative food is provided via the
posts marked as spam by users via the
admin interface.
Misc
• Miscellaneous classes that did not fit
anywhere
Net
• The Net package includes all the classes
that are related to network functionality in
one way or another.
Net_HTTP
• Package that contains several classes and
code related to HTTP, such as code for
making HTTP requests or code for dealing
with certain HTTP headers
Pager
• generic implementation of a pager. It
doesn't take of generating SQL queries for
paging or anythign like that, it only takes
care of generating the number of pages
based on the number of registers, keeping
track of the current page, etc.
Data
• The Data module includes all sorts of
functions that deal with data manipulation
such as Validator classes, text formatters
or pagers
Validator
• Validator classes allow to reuse validation logic
wherever needed, and in a uniform way since
class users can safely assume that all validators
implement the Validator::validate() method.
• Validator classes in pLog can be built as a set
of Rules, as a set of chained Validator classes
or they can also bring their own non-reusable
logic (non-reusable in the sense that validation
logic does not necessarily need to be part of a
Rule class)
View
• A view is the class in pLog that takes care
of rendering the content and sending to
the user.
• In pLog each Action class must generate
a view that can be sent to the client, which
is obtained via the method
Action::getView()
Template
• The Template module provides classes
for dealing with templates
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.