Widgets [RFC]

286 views
Skip to first unread message

Andres Gutierrez

unread,
Jan 10, 2013, 1:26:27 PM1/10/13
to pha...@googlegroups.com
This RFC is to discuss the possible inclusion of widgets in the core of Phalcon and possible implementation with special emphasis on whether this can be implemented by developers without the intervention of Phalcon.

What are widgets?
Widgets is an abstraction that allows code reuse especially in views.

1. Add widgets to the IoC
As object instances can be easily injected in the views, a widget class can be registered and then used in any view as the following example demonstrate: https://gist.github.com/4504200
The implementation is very simple, but if the number of "widgets" is too high maybe would be hard to maintain.

This strategy is currently used in INVO: http://docs.phalconphp.com/en/latest/reference/tutorial-invo.html#user-components

2. Create the widgets using a Factory
This implementation is very similar to the first one, it increases the code needed to render the widget but makes the code more maintainable when creating/adding new widgets to the application.  https://gist.github.com/4504306

Please add comments about the following topics:
  • Is this necessary to be implemented in the Phalcon's core?
  • What is the best implementation? Vote for one of the options above or present one by yourself
  • Are necessary built-in widgets in the core? What of them?
  • The framework should be "engaged" with a UI library such as jQueryUI, Dojo or Bootstrap?
  • Should be the widgets functionality implemented in PHP or C? Note that a PHP implementation allow more developers to make contributions

Looking forward to your comments,

Николай Измайлов

unread,
Jan 10, 2013, 1:47:05 PM1/10/13
to pha...@googlegroups.com
I think it was very well if it were embedded widgets of Jquery UI. Implementation in C can be , but with the possibility of extensions, вприницпе and can be in PHP. Don't forget to provide the connection of the css and js in the <head></head> and check-js.
Also it would be great to make a run and endRun and between them paste your code


2013/1/10 Andres Gutierrez <andres.g...@phalconphp.com>

--
You received this message because you are subscribed to the Google Groups "Phalcon PHP Framework" group.
To post to this group, send email to pha...@googlegroups.com.
To unsubscribe from this group, send email to phalcon+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Antonio Lopez

unread,
Jan 10, 2013, 7:54:25 PM1/10/13
to pha...@googlegroups.com
-1, what would become part of the core? your examples show that it is something that has to be written by the developer,,

I think that write everything in C is an absurdity, I think that if there is a good API for creating widgets is more than good..

--

Romanko

unread,
Jan 10, 2013, 8:59:06 PM1/10/13
to pha...@googlegroups.com, andres.g...@phalconphp.com
My comments are in red below.
  • Is this necessary to be implemented in the Phalcon's core?
Widgets belong to representation, they are parts of the page. If you were building CMS, you could have widgets as separate classes managed from backend and so. Considering that Phalcon is a framework and not CMS, what functionality a Widget class can provide? It may have a separate sub-template and / or model attached if rendering widget requires some logic. Thus we come to HMVC comncept. On the other hand, having separate controllers just for widgets is exsessive.
  • What is the best implementation? Vote for one of the options above or present one by yourself
  • Are necessary built-in widgets in the core? What of them?
I would prefer to have something similar to Phalcon/User/Component, just to keep the rendering logic organized and maybe to operate with widget template, if separate template is required.
  • The framework should be "engaged" with a UI library such as jQueryUI, Dojo or Bootstrap?
Definitely not. UI library should be an optional choice not the obligation. 

Karol

unread,
Jan 11, 2013, 2:53:12 AM1/11/13
to pha...@googlegroups.com, andres.g...@phalconphp.com
Hi,
Phalcon is highly decoupled framework, so when others doesn't need to simplify things let them create innovative wheels, but the rest of us who just want to do the work, create a widget system/manager that will have rules which defines how people can create reusable extensions. Just copy/paste folder with extension (very simple mvc with own views) and it should work on every page with simple customize. It could help phalcon popularity, we could have our extension market too :). Yii (yii is framework before php 5.3) so disadvantages for me is his namespaces="innovative wheels too" which i don't like to learn/use, while namespaces exists from php 5.3. Yii2 will have normal namespaces.

Please look at how works extensions in Yii - http://www.yiiframework.com/doc/guide/1.1/en/basics.view#widget
Please look at yii extensions http://www.yiiframework.com/extensions/ - please take a look at some of them and you see what is widget and how powerfull it could be. 


Laravel use bundles (aka widget too).

But phalcon need to create another module - assets manager. Asset manager should copy resources from app space, installed widget, to public space.

I i have to vote for your two options i vote for second.

Romanko

unread,
Jan 11, 2013, 5:17:43 PM1/11/13
to pha...@googlegroups.com, andres.g...@phalconphp.com
If widgets go into IoC it should be a specialized "view IoC" not to mix presentation object with core objects. This approach has some disadvantages, e.g., another entry point (widgets bootstrap??) to configure all the widgets used at page beside those instantiated in controller.

The factory approach is easier in terms of lazy loading. I vote +1 for it.

As Andres mentioned, the goal is to allow code reuse in views. I think If widget is something which is shared between pages aka HTML snippet with no or simple presentation logic behind, it can be implemented via partials. By the way, is passing parameters to partials supported or do they use global scope?

If widget has complex logic behind, it should be a class extending some core widget class. Factory which instantiate widgets should be aware of DI and inject it if widget implements Phalcon\DI\InjectionAwareInterface.

For example, we have a SiteMap class and a widget which can render breadcrumbs using current route:

class MyBreadcrubs extends Phalcon\Mvc\View\Widget implements Phalcon\DI\InjectionAwareInterface
{
    protected $di;

    public function setDi() { ... }
    public function getDi() { ... }

    public function render()
    {
        $sitemap = $this->di->get('sitemap');
        $router = $this->di->get(''router);
        $path = $sitemap->locate(
               $router->getModuleName(),
               $router->getControllerName(),
               $router->getActionName(),
        );

        $this->view->setVar('path', $path);

        // ... rendering
    }
}

I think widgets should work their own views. There is a use case, a calendar which changes its layout:

class MyBreadcrubs extends Phalcon\Mvc\View\Widget implements Phalcon\DI\InjectionAwareInterface
{
    const VIEW_WEEK = 'week';
    const VIEW_MONTH = 'month';
    const VIEW_YEAR = 'year';
    const VIEW_AGENDA = 'agenda';

    protected $di;
    protected $viewStyle;
    protected $startDate;

    public function __construct(array $parameters = array())
    {
        parent::__construct($parameters);
        $this->viewStyle = ( isset($parameters['style']) ? $parameters['style'] : self::VIEW_WEEK );
        $this->startDate = ( isset($parameters['date']) ? $parameters['date'] : date('Y-m-d') );
    }

    public function setDi() { ... }
    public function getDi() { ... }

    public function render()
    {
        $this->view->setVar('date', $this->startDate);

        switch($this->viewStyle) {
            case self::VIEW_WEEK:
                 $this->view->setMainView('week.html');
                 break;

            case self::VIEW_WEEK:
                 $this->view->setMainView('week.html');
                 break;

            case self::VIEW_MONTH:
                 $this->view->setMainView('month.html');
                 break;


            case self::VIEW_YEAR:
                 $this->view->setMainView('year.html');
                 break;

            case self::VIEW_AGENDA:
                 $this->view->setMainView('agenda.html');
                 break;

            default:
                 thrown new \InvalidArgumentException('Invalid calendar view style');
        }

        // ... rendering

aavolkoff

unread,
Jan 14, 2013, 12:00:35 AM1/14/13
to pha...@googlegroups.com, andres.g...@phalconphp.com
I think that you don't need create "Widgets" functionality for the rendering view purpose, because Phalcon\MVC\Controller can do it instead with more flexibility.

Just example:
I create new action for the controller that can be a part of the application or standalone view (like "widjet"). "Rendering level" may be obtained from the context of using.
```
class AuthController  extends ControllerBase{
 public loginAction{
    $page = array(...);
    if ($this->request->isPost()){
        //... do actions
        $this->flash->error('Validation failed'); 
        //... do actions 
    }
    //... do actions 
   $this->view->setVar("page", $page);
 }
}
```
Then I create phtml(volt) view for the login action:
```
<?php $this->getContents() ?>
<form name="login-form" method="post" action="/auth/login">
   <input type="text" name="login" id="login" required placeholder="Login"> 
   <input type="password" name="login" id="login"required placeholder="Password">
</form>
```

...somwere in html:
```
<div class="nav">
   <?php $this->render->("auth\login") ?> // In this context "rendering level" of the login action must be set to "Phalcon\Mvc\View::LEVEL_ACTION_VIEW" automatically.
</div>
```
And the result html will be:
```
<div class="nav">
   <div class="error">Validation failed</div>
   <form name="login-form" method="post" action="/auth/login">
      <input type="text" name="login" id="login" required placeholder="Login"> 
      <input type="password" name="login" id="login"required placeholder="Password">
   </form>
</div>
```

In that case we can construct views from blocks (controller's actions). I think it will be really useful feature.


 

Reply all
Reply to author
Forward
0 new messages