[Solar-talk] Okay Quick Framework 'Shift' Question
Paul M Jones
pmjones at ciaweb.net
Tue Sep 25 15:01:18 CDT 2007
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>
More information about the Solar-talk
mailing list