Completed
Pull Request — master (#128)
by
unknown
02:06
created

WidgetController::editablesegment()   C

Complexity

Conditions 7
Paths 6

Size

Total Lines 24
Code Lines 15

Duplication

Lines 0
Ratio 0 %

Importance

Changes 7
Bugs 5 Features 0
Metric Value
c 7
b 5
f 0
dl 0
loc 24
rs 6.7272
cc 7
eloc 15
nc 6
nop 0
1
<?php
2
3
/**
4
 * Optional controller for every widget which has its own logic, e.g. in forms. 
5
 *
6
 * It always handles a single widget, usually passed in as a database 
7
 * identifier through the controller URL. Needs to be constructed as a nested 
8
 * controller within a {@link ContentController}.
9
 * 
10
 * ## Forms
11
 * You can add forms like in any other SilverStripe controller. If you need 
12
 * access to the widget from within a form, you can use 
13
 * `$this->controller->getWidget()` inside the form logic.
14
 *
15
 * Note: Widget controllers currently only work on {@link Page} objects,
16
 * because the logic is implemented in {@link ContentController->handleWidget()}.
17
 * Copy this logic and the URL rules to enable it for other controllers.
18
 * 
19
 * @package widgets
20
 */
21
class WidgetController extends Controller
0 ignored issues
show
Coding Style Compatibility introduced by
PSR1 recommends that each class must be in a namespace of at least one level to avoid collisions.

You can fix this by adding a namespace to your class:

namespace YourVendor;

class YourClass { }

When choosing a vendor namespace, try to pick something that is not too generic to avoid conflicts with other libraries.

Loading history...
22
{
23
    /**
24
     * @var Widget
25
     */
26
    protected $widget;
27
28
    /**
29
     * @var array
30
     */
31
    private static $allowed_actions = array(
0 ignored issues
show
Comprehensibility introduced by
Consider using a different property name as you override a private property of the parent class.
Loading history...
Unused Code introduced by
The property $allowed_actions is not used and could be removed.

This check marks private properties in classes that are never used. Those properties can be removed.

Loading history...
32
        'editablesegment'
33
    );
34
35
    /**
36
     * @param Widget $widget
37
     */
38
    public function __construct($widget = null)
39
    {
40
        if ($widget) {
41
            $this->widget = $widget;
42
            $this->failover = $widget;
43
        }
44
        
45
        parent::__construct();
46
    }
47
48
    /**
49
     * @param string $action
50
     * @return string
51
     */
52
    public function Link($action = null)
53
    {
54
        $id = ($this->widget) ? $this->widget->ID : null;
55
        $segment = Controller::join_links('widget', $id, $action);
56
        
57
        if ($page = Director::get_current_page()) {
58
            return $page->Link($segment);
59
        }
60
        
61
        return Controller::curr()->Link($segment);
0 ignored issues
show
Unused Code introduced by
The call to Controller::Link() has too many arguments starting with $segment.

This check compares calls to functions or methods with their respective definitions. If the call has more arguments than are defined, it raises an issue.

If a function is defined several times with a different number of parameters, the check may pick up the wrong definition and report false positives. One codebase where this has been known to happen is Wordpress.

In this case you can add the @ignore PhpDoc annotation to the duplicate definition and it will be ignored.

Loading history...
62
    }
63
    
64
    /**
65
     * @return Widget
66
     */
67
    public function getWidget()
68
    {
69
        return $this->widget;
70
    }
71
    
72
    /**
73
     * Overloaded from {@link Widget->Content()} to allow for controller / form 
74
     * linking.
75
     * 
76
     * @return string HTML
77
     */
78
    public function Content()
79
    {
80
        return $this->renderWith(array_reverse(ClassInfo::ancestry($this->widget->class)));
81
    }
82
    
83
    /**
84
     * Overloaded from {@link Widget->WidgetHolder()} to allow for controller/ 
85
     * form linking.
86
     * 
87
     * @return string HTML
88
     */
89
    public function WidgetHolder()
90
    {
91
        return $this->renderWith("WidgetHolder");
92
    }
93
    
94
    /**
95
     * Uses the `WidgetEditor.ss` template and {@link Widget->editablesegment()} 
96
     * to render a administrator-view of the widget. It is assumed that this
97
     * view contains form elements which are submitted and saved through 
98
     * {@link WidgetAreaEditor} within the CMS interface.
99
     * 
100
     * @return string HTML
101
     */
102
    public function editablesegment()
103
    {
104
        // use left and main to set the html config
105
        $leftandmain = LeftAndMain::create();
106
        $leftandmain->init();
107
        
108
        $className = $this->urlParams['ID'];
109
        if (class_exists('Translatable') && Member::currentUserID()) {
110
            // set current locale based on logged in user's locale
111
            $locale = Member::currentUser()->Locale;
112
            i18n::set_locale($locale);
113
        }
114
        if (class_exists($className) && is_subclass_of($className, 'Widget')) {
115
            $obj = new $className();
116
            // generate new id
117
            if(method_exists($obj, 'doValidate') && $obj->doValidate()->valid()) {
118
                $obj->write();
119
            }
120
            return $obj->EditableSegment();
121
        } else {
122
            user_error("Bad widget class: $className", E_USER_WARNING);
123
            return "Bad widget class name given";
124
        }
125
    }
126
}
127
128
/**
129
 * @deprecated Use WidgetController
130
 * @package widgets
131
 */
132
class Widget_Controller extends WidgetController
0 ignored issues
show
Coding Style Compatibility introduced by
PSR1 recommends that each class should be in its own file to aid autoloaders.

Having each class in a dedicated file usually plays nice with PSR autoloaders and is therefore a well established practice. If you use other autoloaders, you might not want to follow this rule.

Loading history...
Coding Style Compatibility introduced by
PSR1 recommends that each class must be in a namespace of at least one level to avoid collisions.

You can fix this by adding a namespace to your class:

namespace YourVendor;

class YourClass { }

When choosing a vendor namespace, try to pick something that is not too generic to avoid conflicts with other libraries.

Loading history...
133
{
134
}
135