Wesley,
1. Does the answer below mean no global persistant objects?
(Application scope) I guess that it does.
No. Files, a database or memory (memcached) can be used to facilitate
application variables.
However, I've been told this is taboo in PHP. Coming from Java I'm sure
youve heard as I
have, that the lack for native support of application variables is a
weakness in PHP, however it
appears that it has actually been designed without support for application
variables *on purpose*.
If you look at *shared nothing* on
wikipedia<http://en.wikipedia.org/wiki/Shared_nothing_architecture>,
youll find a a decent overview.
I also found some articles on the Zend website that essentially say an
$_APPLICATION array
was purposely not implemented.
If i understand correctly there is a trade off between a centrally managed
state and a shared nothing
approach. Shared nothing systems will have redundant data, but less load
trying to grant exclusive access to a shared central state. Shared nothing
systems
introduce additional complexity in order to keep exclusive copies of central
state in sync.
2. Is this an un-PHP way of doing things?
If youre talking about application variables then, apparently.
3. Is what I'm trying to do even worthwhile or should I just create
each form and its validation rules by hand? (My gut feeling is that
its still worth doing as it centralizes form processing and reduces
redundancy on a code level)
dont let PHPs lack of managing persistent objects dissaude you
from good programming practices. code duplication is often a poor
technique,
although there are times when it can be rationalized. in your paritcular
situation,
implementing form validation, you may want to study up on the strategy
pattern,
if you dont already know about it. there is a decent example on
phppatterns.com <http://www.phppatterns.com/docs/design/strategy_pattern>
which demonstrates strategy using form validation as an example
(although the example is in php4 :<)
4. Which would be more expensive recreating the object each time? Or
fetching it from the session each time? (I know that this probably
doesn't have a definative answer)
i think there are quite a few variables in this question. primarily it
depends on what the
obect does. for an object that needs to query the database to initialize
its state it is almost
certainly less expensive to cache the instance in memory. but if it is
simply built w/ the values
of user input in a web form it may not offer noticeable savings. object
persistence is a
trade off between time and space, persisting the objects will take more
space. of course if
those objects represent data from a database or some other source where the
data they represent
can change, there is additional complexity involved making sure their
internal values are changed
when the data they represent changes.
all of this really comes down to design decisions. if youre new to PHP i
would recommend focusing
on learing the language, applying what you know from java to your object
design and move to a
caching model once youre a little more comfortable [thats basically the path
ive taken w/ the language]
-nathan
4. Which would be more expensive recreating the object each time? Or
fetching it from the session each time? (I know that this probably
doesn't have a definative answer)
Anyway my feeling is it probably shouldn't go in the session as its
not a client object.
Comments are welcome.
Regards,
Wesley
On 7/15/07, Nathan Nobbe <quickshiftin@xxxxxxxxx> wrote:
> Wesley,
>
> I too have come from a Java [ and c++ ] background to PHP. fear not;
you
> can create persistent objects PHP.
> although there is no JVM to handle this automatically object can be
> persisted by storing their references. the
> most natural place to store them is in the session. and if i understand
the
> advice i was given a few weeks ago
> this is the PHP way to do it since PHP was written as an implementation
of
> the shared nothing paradigm (did i say that correctly?).
> Also, note that there are many ways the session can be stored. PHP
stores
> the session on disk naively, but
> this behavior can be overridden. Sessions often times are stored in a
> database instead. And my thinking, though
> im sure someone would love to correct me, is that sessions can be stored
in
> memory via a technology like
> memcached.
>
> -nathan
>
>
> On 7/15/07, Wesley Acheson <wesley.acheson@xxxxxxxxx> wrote:
> >
> > Hi,
> >
> > At work we use Java so one thing is annoying me. Is there really no
> > way to create a persistent object in PHP? As far as my understanding
> > goes each object will be recreated on each and every request.
> >
> > The reason I was asking is I wanted to create a form object that would
> > be used as follows.
> >
> > which would require recreating the from stuff three times at least
> > Once for a JS file. Once for a HTML output. And once for Server side
> > validation)
> >
> > Please note that the following is just an example off the top of my
> > head the code to do this hasn't been written yet and the exact
> > implemantation may be different. It would be much better to only
> > create the object once.
> >
> > <?php
> > ...
> > Other stuff goes here.
> > ...
> > //Create a new form
> > formReg = new Form ("registration");
> >
> > regStyle = new
> RenderStyle(HTML_AND_JAVASCRIPT_TABLELESS);
> > formReg->setRenderStyle();
> >
> > /**
> > * Set the username field and its Validation
> > */
> > fieldUsername = new Field("username");
> > fieldUsername->setLabel("User Name");
> > fieldUsername->setType(FIELD_TEXT);
> > fieldUsername->setCompulsary(true);
> > fieldUsername->setUnique(true);
> > fieldUsername->setMinLength(6);
> > fieldUsername->setMaxLength(20);
> >
> fieldUsername->setMaxLengthError(fieldUsername->getMinLengthError());
> > fieldUsername->setValidCharachters(CHARACHTERS_A-Z_1-9);
> >
> > formReg->addField(fieldUsername)
> > .....
> > //OTHER FIELD STUFF HERE
> > .....
> >
> > //Adds the link to a generated JS file at the top;
> > if (frmReg->needsJSCode == true) {
> > output->add(formReg->getJSValidationURL)
> > }
> > ....
> > //CONTINUE WITH THE REST OF THE HTML PAGE
> > ....
> >
> > //Insert the form into the HTML
> > output->add(fromReg->getForm(regForm));
> > ?>
> >
> > In the custom JS file we need;
> > <?php
> > frmReg->getValidationAsJavascript()
> > ?>
> >
> > Then after this in the page that receives the form submission we again
> > need to get the validation rules which means recreating the the form
> > object at least three times. This time to validate serverside.
> >
> > <?php
> > session_start() {
> > ....
> > if (!frmReg->validates) {
> > $_SESSION[VALIDATION_ERROR] = frmReg->getValidationError();
> > $_SESSION[ERROR_FIELD] = frmReg->getValidationField();
> > ...
> > //logging goes here
> > ...
> > HttpResponse::redirect ( REGISTRATION_URL) ;
> > ....
> > } else {
> > ...
> > // Attempt to save to the DB
> > // Redirect on error
> >
> > // log a successfull registration
> > ...
> > require_once (REGISTRAION_SUCCESS_PAGE);
> > }
> >
> > ?>
