Thanks again for your reply and all the details. I think I need to personally
set myself up with a fresh download of the latest ZF, and experiment with
bootstrap as a class, controllers and views, as well as models and "modules"
which are new to me. I am reading up on data mapping and need to experiment with
that too on free time. If you can please let me know, in regard to my last
question from my previous email (pasted below, my comments are below yours):
> If *you* were coding a products list page, would you :
> - simply create many controller auxiliary/helper functions to do the job
> - or set up a products list model to hold the functions
> - or set up a unique class (similar to a model, except we won't *call* it
> a
> model) and store it anywhere in a common directory, even
> models/commonclasses/
> or something like that?
>
>As you suspected, the list itself isn't usually considered a model.
>The product itself is a model. The list is considered a collection.
>Think in terms of an array/iterator of one or more products.
Understood; so the following is my scenario:
- I have a number of products in my database, for convenience we will call each
Product a Model (even though I have not coded it as a model, following my
previous emails, and all my code is in the controller).
- The Product List pages display a collection of products. There is a LOT more
going on though, several requirements in play, a simple example being "Product
filters". E.g.
Filter by Colour:
- black
- brown
- white
- blue
Filter by Length:
- Long
- Medium
- Short.
Each of the above filters comes from a couple of table JOINs in the database.
>From everything I've read online, I think I can safely call a "filter" = a
"Model", because it comes from the database and is its own entity. There is a
many-to-many relationship between filters and products. If I just want to start
upgrading the site I'm working on to use the concept of "models", should I go
ahead and prepare a model for a general filter? Then my products-list controller
will generate instances of each filter model.
If I were to further improvise our coding, to keep our "product" related
functions and classes separate from other directories, would you recommend that
I create a "module" or custom namespace to hold my "product" functions? For
example, I could have a
/application/modules/ directory (not created at the moment) and then have a
subdirectory called "products" , which will hold my "models/Product.php" for the
Product model, and "models/Filter.php" for the product Filter. Does this make
sense? Am I on the right track?
At the moment I don't want to give our website a complete turnaround in coding
due to limited time, but I just want to get the "filter" part of the pages coded
"well". I am therefore looking to
- either create a model for this, as explained above.
- create a model for this AND put it in a "modules/products/" directory for the
future, to keep all product-related coding for models there.
- or if I'm not on the right track, then I'd simply store a common functions
file for products-lists anywhere else where I prefer.
The above is quite a standard requirement in terms of developing a products
website, so I am looking to find out a fairly simple yet common way for people
who are somewhat new to the framework's concepts of models and modules.
(Wil, p.s. - thanks for the reference on Zend Paginator; I've not used it but I
don't need paging in this particular website.)
Thanks,
Rishi
________________________________
From: Wil Moore III <wil.moore@wilmoore.com>
To: fw-mvc@lists.zend.com
Sent: Sun, November 28, 2010 12:45:10 AM
Subject: [fw-mvc] Re: How to instantiate a model class to use its functions,
standard solution?
Hi Rishi,
I'll do my best to answer your questions...see below:
Rishi Daryanani wrote:
> Do you see any issues with this approach or is it easy to switch to a
> class...
While there is nothing wrong with the older approach (I've supported code
that was setup this way), there are a few benefits to the newer bootstrap
facilities and Zend_Application.
This is not exhaustive and I'm trying to be brief so off the top of my head:
1. You can simply configure "resources" in your application.ini (or .xml if
that is what you use) and they are bootstrapped and available for use
throughout the application.
2. You can re-factor your Bootstrap resource "_init*" methods into their
own classes. There are several advantages here, but I won't go deep into
that here.
3. Through conventions, it is easy to understand what resources are
available and what options are avilable on those resources.
Rishi Daryanani wrote:
>
> http://framework.zend.com/manual/en/learning.quickstart.create-model.html...I
> usually load data into a database from my own custom PHP script or via an
> admin interface (e.g. phpPgAdmin for Postgresql) if need be. Is there a
> certain advantage of doing the database updating/data upload in a similar
> way described in the above link? I suppose the advantage is that it keeps
> everything together, within the application/framework.
>
As I use Doctrine2 (ORM, DBAL) and Liquibase (Schema Migrations), I've never
needed to go through the info in the above link. All I can tell you is that
an OO Data Mapping (you may want to read more about this pattern) strategy
and and schema migrations will alleviate a lot of problems and allow you to
focus on other things.
Rishi Daryanani wrote:
>
> ...why do we have two models: Application_Model_GuestbookMapper and
> Application_Model_Guestbook?
>
One of them is a model/entity class and the other is the mapper. You will
want to read up on the Data Mapper pattern (and potentially study Doctrine2,
Hibernate, and Entity Framework) to understand this separation further. The
basic idea (and I mean basic) is that your model/entity class knowns nothing
of how it will be persisted or even if it will be persisted at all. You
should be able to unit-test your plain PHP object (model) without worrying
about persistence.
Rishi Daryanani wrote:
>
> Following the above tutorial I did try to create a
> "Application_Model_Guestbook" model, however what I did not do is execute
> the
> command line code like % zf create model Guestbook.
>
I've only used the "zf" command once. That was to start a skeleton project.
I keep that skeleton project around for starting new ZF projects. What I'm
saying is that I can't tell you much about the "zf" command as I hardly use
it. I can tell you that there is nothing in the framework that you can't do
on your own (without the "zf" command).
Rishi Daryanani wrote:
>
> ...my script kept returing the error that the php file was not found in
> /Application/Model/ - I'm not sure why it was looking in that directory;
>
Sounds like you need to setup the resource autoloader. Again, not sure as I
don't use that either. I keep all models under a library directory. I've
never really found putting resources near the controllers to be an
advantage. Using sane package/namespace conventions sort of negates any
advantage module/controller resource has (in my mind). Of course, YMMV on
this one. BTW, now that we are on PHP 5.3.x, packages/namespaces are even
cleaner.
NOTE: Zend's autoloader works well and is PSR-0 compliant -
http://groups.google.com/group/php-standards/web/psr-0-final-proposal. I've
had no need to add anything else to the equation.
Rishi Daryanani wrote:
>
> must I execute those command line codes again or can I dive straight into
> creating code like the following?
> // application/forms/Guestbook.php
> class Application_Form_Guestbook extends Zend_Form
>
You can build forms just as you build any other class. Loading them is
completely up to you as well. You can use the resource loader (again,
something I personally don't use) or you can put your forms under your
library directory and load them that way.
Rishi Daryanani wrote:
>
> If *you* were coding a products list page, would you :
> - simply create many controller auxiliary/helper functions to do the job
> - or set up a products list model to hold the functions
> - or set up a unique class (similar to a model, except we won't *call* it
> a
> model) and store it anywhere in a common directory, even
> models/commonclasses/
> or something like that?
>
As you suspected, the list itself isn't usually considered a model. The
product itself is a model.
The list is considered a collection. Think in terms of an array/iterator of
one or more products.
Zend Paginator would help you in this regard as well.
Sorry this was so quick but I hope it turns out to be at least somewhat
helpful.
--
Wil Moore III
-----
--
Wil Moore III
Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html
--
View this message in context:
http://zend-framework-community.634137.n4.nabble.com/How-to-instantiate-a-model-class-to-use-its-functions-standard-solution-tp3054833p3061840.html
Sent from the Zend MVC mailing list archive at Nabble.com.
没有评论:
发表评论