Sorry typo...
On 1/22/2010 9:39 AM, Paul wrote:
Agree, don't want to use Action view helpers.
As for the front controller plugin, you are saying create a plugin,
that inside predispatch, interacts with the view, either by adding
vars, or even adding an object that knows how to display itself(almost
like a view helper), then if you need to respond to you an ajax post
back or something your plugin can react accordingly.
Very interesting and I like it. As I think more about this, I was
thinking of doing something similar only with action helpers instead
of front controller plugins, this way you dont need the plugin to run
on every request only when you use the action helper.
// in my controller -
$this->view->myWidget = $this->_helper->myWidget($canPassModelInfo,
$orOtherConfigurations) // would instantiate your widget, allow it
to pull data from the request, and create an object that is returned.
This object can act just like a view helper like object, and in fact
it is! It just *does NOT need* to to be added as helper path (which
actually is better in terms of performance).
in your view you can then do whatever you want.., as long the object
returned by the action helper return an object that has a __toString()
method.
// view
$this->myWidget->limit(5)->allowMultiSelect();
what's great is that you action helper can also respond to any other
request info, or alter the response object.
this keeps your widget layers nice and separate.
You have a view object for rendering, and action helper for request,
routing, and dispatching, and both can interact with your domain model
layer. Also no need to add a million helper paths, if your system is
using many widgets.
On 1/22/2010 2:03 AM, Dennis Becker wrote:
Zend_View_Helper_Action is really slow, the best between
easy-to-understand & use ist the usage of Frontcontroller Plugins.
You should use them like controllers and could fill placeholders in
Zend_Layout / Zend_View.
2010/1/22 Vladas Diržys <[email protected]
<mailto:[email protected]>>
I think there is already a solution which handles kind of "Widgets".
Then you call <?= $this->action('my-widget-action', 'my-widget')
?> from your view, you can have similar effect.
But the downside of this solution is performance.
--
Regards,
Vladas Diržys
On Wed, Jan 20, 2010 at 22:11, Paul <[email protected]
<mailto:[email protected]>> wrote:
I know the term Widget is a loaded concept, but was wondering
what everyone's thoughts on the best way to create reusable
Controls/Components/Widgets.
To me a Widget is something you can drop into any controller
and it would be able to handle rendering itself and working
with Model. At first this sounds very similar to a View
Helper, which is how I have done this so far. The issue
comes when you need to update the Model.
Updating a model from the view is not really good practice or
allowed in MVC.
An example situation, may help paint the picture:
A Widget photo selection widget. This widget would fetch
images from some Gallery Model. The view part of the
widget would show a thumbnail grid of the photos, with
some sort of js lightbox modal. When a user select one
photo, it would via ajax, post back and add to the image
to his favorite photos collection, which means we need to
update a model.
If this widget was just going to be in one system, you would
just create a view helper, and the controller to handle the
ajax. If you want to make this ajax/post reusable you could
create an Action Helper. So to me seems like to be able to
do this, you would need a way to create an encapsulate
package that includes a View Helper and Action Helper.
What we want to be able to do, similar to modules, is to just
drop a widget in place. It doesn't need to go as far as
having to bootstrap itself like a module. It can work like
action helper / view helpers do with brokers. The issue I
have is that since the package is contained, you are going to
add up with a bunch of helper paths which is going to really
hurt performance if you have a bunch of widgets in your system.
Thoughts? Ideas? I am thinking too much about this :)
--
Dennis Becker [email protected] <mailto:[email protected]>
Telefon: +49 (0) 211-63 55 55-97
Telefax: +49 (0) 211-63 55 55-22
sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391
www.sipgate.de <http://www.sipgate.de> - www.sipgate.at
<http://www.sipgate.at> - www.sipgate.co.uk <http://www.sipgate.co.uk>
