Self contained Ajaxian Widgets!

Hi guys,

Is it possible to build a Widget that could handle its ajax requests alone. without the need to write controller actions to handle those requests ? I think the answer is no.

According to the APIs,"A widget is a self-contained component that may generate presentation based on model data. It is a micro-controller that embeds into the controller-managed views. Compared with controller, a widget has neither actions nor filters. "

My point is :

How could the widget be some sort of controllers if it couldn’t deal with user interactions ? in the other hand, how could a widget be self-contained if we need to write some code outside to treat ajax requests.

What do you think ?

  • Phiras

This is a good question. We could support such truly self-contained widgets, but the problem is that it would complicate creating the widget as well as their usage.

A not so self-contained yet simpler approach would be to implement the ajax action code in the widget class and ask the user of the widget to call this method in their appropriate controller actions. As an example, you may take a look at the new CActiveForm (in svn trunk only) which performs server-side validation via AJAX.

Supporting such thing in a subclass of CWidget wouldn’t affect users who want to create regular widgets. and will support the idea and could be very cool.

Thank you for your answer and thank you for the good work!

I’d like to see this… so much… :P

How could a route to such a widget action look?

These actions would have to be static widget methods, as no widget instance will exist.

I see no problem in that… because inside the widget all actions should be well-known

The thing is what you said, it has to be coded in the core, I see no means to implement something external to give this funcionality but I see that as a MUST-HAVE if you want to implement totally indepentend widgets

The changes would not be many. If widget routes look like e.g. "?r=widget:MyWidget/someMethod" only CWebApplication::processRequest would have to be changed to handle those routes differently. And maybe CUrlManager would need some changes to make sure, these routes are created/parsed properly.

But not sure, if this route pattern is really appropriate.

Oh, one important thing will make things difficult: authentication is now coupled tightly to controller actions. You’d have to add similar auth checks for your public widget actions to make them really useful.