[Solar-talk] Okay Quick Framework 'Shift' Question
Kilbride, James P.
James.Kilbride at gd-ais.com
Wed Sep 26 08:15:30 CDT 2007
NEVER PAUL! YOU'LL NEVER TAKE MY CODE ALIVE!!!
Oh sorry.. flashback to 3:10 to yuma..
You actually did a good job laying out how things relate to each other
between the two. Much as I hoped you would.
So let me talk to what I've got right now. What I have is a hierarchal
structure taking a Program, which has documents, which have procedures.
Programs also have locations and equipment and developers associated
with it. Procedures have a subset of the programs developers, equipment
and locations associated with them.
So in Zend's framework I cranked out over the last couple of days a base
controller which deals with things at the Program level(listing
programs,standard CRUD on the program table). That choosing a program
links you down into the document level which goes to the document
controller(CRUD'd again). Procedures are listed below the document
level(CRUD with the added detail that the base procedure page shows a
summary of each procedure for decision purposes and has a detail
description page). The procedure's display/add/edit pages also modifies
the linkages bewteen procedures and locations/developers. Equipment
actually gets linked to the procedure/location combination in some
cases(still working that issue).
The forms have been slightly annoying since zend doesn't do a good job
of documenting their helpers or making them obvious. But I've found them
and gotten that going just fine at this point.
Basically I have a structure that looks like this:
KilbrideApp/
application/
controllers/
DocumentController.php
IndexController.php
ProcedureController.php
models/
Developer.php
Document.php
Location.php
Procedure.php
ProcedureDeveloper.php
Program.php
VerificationMatrix.php //This is the
Location/Procedure combination which contains additional data.
views/
document/
_form.phtml
add.phtml
delete.phtml
edit.phtml
index.phtml
index/
_form.phtml
add.phtml
delete.phtml
edit.phtml
index.phtml
procedure/
_form.phtml
add.phtml
delete.phtml
edit.phtml
index.phtml
details.phtml
footer.phtml
header.phtml
config.ini //Database configuration file
library/ //Zend Framework area.
public/ //Public scripts/css/images
index.php //This is the zend setup file.
I'm inheriting from Zend's framework classes. This is a very typical
'CRUD' application with some custom logic involving subscreens and such.
Nothing surprising really. So we start off at the
Localhost/KilbrideApp/index/<action> when dealing with program go to
Localhost/KilbrideApp/document/<action> when dealing with documents and
finally hit Localhost/KilbrideApp/procedure/<action> at the procedure
level. Am I reading your structure right in seeing that I'd have an App/
directory and then below that I'd have my Document/Index/Procedure.php
pages and a directory named after each one, my helper/layout/local/view
directories within that directory and my
views(add/delete/edit/index/deatils) within the view directory?
Where do my models go? Especially since I use the program table within
document and procedure, document is used in procedure, etc. Can I just
replace Zend_DB_Table with Solar_Something_Table? I use Zend_Session to
store program/document as I move down my tree, rather than adding
pids/dids to my url's everywhere and making the Url's continually
longer. It does mean the system will boot you back to the top if you
time out your session and you can't go straight to a specific portion of
the hierarchy.. but that's a design choice I wanted to make. i hate
url's with 18 different id's in them and I didn't want everything being
a form posting to the next higher level.
So does my question make sense? And on the oracle scene.. I will be
interested in getting used to it as we have a major year long
development project that I want a good solid framework for. Some of my
developers aren't php veterans or even MVC veterans. And I'm not going
to be available to do design/coding work for most of it(curse you
management role!).
James Kilbride
-----Original Message-----
From: solar-talk-bounces at lists.solarphp.com
[mailto:solar-talk-bounces at lists.solarphp.com] On Behalf Of Paul M Jones
Sent: Tuesday, September 25, 2007 4:01 PM
To: solar-talk at lists.solarphp.com
Subject: Re: [Solar-talk] Okay Quick Framework 'Shift' Question
Hey Kilbride,
> What does it take to shift from Zend Framework to Solar?
> Technically I'm sure you can have both around and all but what are the
> primary differences in your code if all you are using is the view and
> controller structure? Structurally speaking, what's different from
> Solar to Zend?
That is an *excellent* question. I wish I had a short answer for you.
:-(
The good news is that Zend and Solar spring from similar backgrounds
(PEAR standards, and I wrote some of the Zend components, so the
changeover should "feel" familiar).
The bad news is that the controller structures are quite different.
The Zend front/router/page/action controller system is more complex.
In it's simpler usage, it is similar to Solar, but Zend has this weird
(sorry Matthew) plugin system for views and layouts. With Solar, we use
extension and hook-methods (like _preRun() and
_postAction()) instead of controller plugins.
In Solar, the basic page-controller dir structure looks like this ...
Vendor/
App/
Foo.php # page-controller
Foo/
Helper/ # view helpers
Layout/ # layouts to wrap views
Locale/ # l10n files
View/ # views
browse.php # Bar::actionBrowse() view
Bar.php # page-controller
Bar/
Helper/ # view helpers
Layout/ # layouts to wrap views
Locale/ # l10n files
View/ # views
browse.php # Bar::actionBrowse() view
... vice the structure from Zend:
application/
controllers/
FooController.php # page-controller
BarController.php # page-controller
views/
scripts/ # all view scripts
foo/ # Foo views
index.phtml # Foo::actionIndex() view
bar/ # Bar views
index.phtml # Bar::actionIndex() view
helpers/ # view helpers
As you can see, Zend takes more heavily from Rails than Solar does.
Solar tries to compartmentalize the apps more than Zend does.
Because we use extension for our apps, if App_Bar extends App_Foo, then
App_Bar automatically has access to all the helpers, layouts, locales,
and views from App_Foo, and falls back to them when they don't exist in
App_Bar. That means it's relatively easy to set up common views and
layouts in a base application, and extend other applications from it.
Solar page-controllers can recognize the "format" of the request.
Say you have actionBrowse(); normally, the URI "controller/page/ browse"
would render the "View/browse.php" script there. With Solar, if the URI
has a format extension, like "controller/page/browse.rss", the
page-controller is smart enough to look for "View/browse.rss.php"
instead, while using exactly the same actionBrowse() method. That is,
you can have multiple view formats for the same action, without having
to change any of the action code.
The Solar view helpers are (I think) more mature than the ones in Zend.
Solar helpers are more "federated" than Zend ones (even though they come
from the same origin project, Savant3). The last time I checked, with
Zend, if you write a custom helper, it has to be called
Zend_View_Helper_Something. In Solar, you can have your own helpers in
the App directory named for that app, e.g.
"Vendor_App_Foo_Helper_Something" and Solar will find it automatically
when your view script calls $this->something().
I'm sure there's a lot more to it, but that's all I can think of off
hand.
Maybe if you send some snippets of code as examples, we can try to work
through them?
Hope this helps, please let me know if it does not.
--
Paul M. Jones <http://paul-m-jones.com>
Solar: Simple Object Library and Application Repository for PHP5.
<http://solarphp.com>
Join the Solar community wiki! <http://solarphp.org>
Savant: The simple, elegant, and powerful solution for templates in PHP.
<http://phpsavant.com>
_______________________________________________
Solar-talk mailing list
Solar-talk at lists.solarphp.com
http://mailman-mail3.webfaction.com/listinfo/solar-talk
More information about the Solar-talk
mailing list