The action return a ShapeResult. And the shape was created in that action on the fly. As the Action is a general purpose action, like List, I want to controller the shape show/hide, order and wrapper in Module's placement.info. But it seems that the placement.info could not affect those shape return by ShapeResult.
Has any approach?
Related
I need an alternate for the EditorTemplate of an Enumerator Field that's used when the Field has a particular name (PublishingMethod).
Based on the docs, I created a view with the pattern [ShapeType__FieldName] in the same folder as the original shape:
This is not working and still uses the original. I've thought of changing the Editor method in the Driver, but I think that defeats the purpose of alternates, which is that Orchard automatically detects the correct shape as I understand from the docs:
The Orchard framework automatically creates many alternates that you can use in your application. However, you can create templates for these alternate shapes.
Note: I can't use the Shape Tracing module, it never worked even with a clean Orchard install.
The editors in Orchard work different to how Display works. I guess it is so you get a MVC-style experience. Basically, the actual shape returned is of type EditorTemplate, which then binds your model and prefix then renders a partial view with the template name you gave it. What this means is alternates wont work as expected, or as the docs state. The alternates for your field name are actually added to the EditorTemplate shape. So what you can do is add a view called EditorTemplate-PublishingMethod.cshtml with contents like:
#{
var m = (Orchard.Fields.Fields.EnumerationField)Model.Model;
}
#Html.Partial("PublishingMethodEditor", m, new ViewDataDictionary {
TemplateInfo = new TemplateInfo { HtmlFieldPrefix = Model.Prefix }
})
Then add another view called PublishingMethodEditor.cshtml with the overrides you want for your editor. All these views should go in the root of your Views folder.
Another approach would be to implement the IShapeTableProvider interface and adjust the TemplateName property on a certain condition but, meh, that requires code...
Edit 1
If you have that field name on other content types that you don't want to override you can use the override EditorTemplate-ContentTypeName-PublishingMethod.cshtml
When creating custom views, I generally create an initialization function by overriding the init(frame) function. When creating the view in my ViewController I initialize the view by passing in the .zero frame, and then set the layout using Material's layout function.
let descView = DescriptionView(frame: .zero)
However, this makes it so that my views in my custom view are not resized. For example, when setting up a custom text view in my custom view, it does not show up because I prepare it as so:
self.layout(descriptionTextView).width(self.width).height(self.height).centerVertically().centerHorizontally()
I assume it doesn't show up because when I initialize the view, its width and height are zero. What can I do to get around this?
I'd like to have the layout reflect some data from a model. However, the render method from the CController class passes the structured data only to the view file, while the layout file only gets the rendered view passed.
So, how to best have the layout display data from a model?
Two possibilities come to mind:
Make Yii's layout file a no-op, mimicking layout logic manually from the view.
Override CController's render method in its subclass.
I'm not so happy with either variant, so maybe someone has a cleaner idea on how to do it?
Another way is to define a public variable in your controller class, something like:
class MyController extends Controller {
public $test = 'foo';
....
That value can then be accessed within a layout:
echo $this->test;
And manipulated in an action:
public function actionMyaction(){
$this->test = "bar";
...
Obviously it's not ideal if you have many variables that you need to use in a layout. One solution is to use an array of parameters. Alternatively you could look at making your layout more minimal and using CWidget to create reusable components for use inside your views.
For example, you obviously wouldn't want to have the code for your main navigation duplicated inside every view, so the obvious solution is to have in the layout, but if it becomes inconvenient to handle the data you could have an instance of a widget that renders out the navigation inside each view (and you can pass data to the CWidget class) something like:
$this->widget("MainNavigation",array("params"=>$params));
I would like to make a layout with a sidebar that can have widgets from different modules. Lets say there shall always be a login widget at the top if the user isn't logged in then it shall show user info. The getting started album guide could use it to display the latest albums and so on, i hope you understand how i want to use the sidebar.
Could it be done with a config file in autoload and a small code that read that config and calls the widgets on every page load?
There are several ways of page composition in Zend Framework 2:
1. Switching between Layouts
By default, ZF2 provides you with a single layout template layout.phtml.
In real-life applications, you will probably need to have several layouts
and switch the layout for certain controller/action. In each of your layouts, you will be able to show different widgets/sidebars.
2. Partial Views
A partial view is a .phtml view template file which can be rendered by another
view template. Partial views allow to compose your page of pieces and reuse pieces
of view rendering logic across different view templates. This is accomplished through the Partial view helper.
3. Placeholder View Helper
The Placeholder is another useful view helper allowing for capturing HTML
content and storing it for later use. Thus, analogous to the Partial
view helper, it allows to compose your page of several pieces.
4. Forward Controller Plugin
With the Forward controller plugin, you are able to call an action (for example, the action rendering some widget) from another module/controller from your controller and grab the output of that action. Then you are able to incorporate that output into your page.
5. Use View Models for Page Composition
When you write action methods for the controller classes, you use the ViewModel
class as a variable container for passing the variables from controller to view template,
and for overriding the default view template name. But, actually the ViewModel class is more than just a variable container plus view template name. In fact, it is closely related to the layout and page composition.
The third big capability of the view model class is that it allows for combining several
view models in a tree-like structure. Each view model in the tree has the associated
view template name and data variables that can be passed to the view template to control
the process of rendering.
This feature is internally used by Zend Framework 2 when "combining" the layout view template and the view template associated with the controller's action method. ZF2 internally creates the view model for the layout template and assigns it with layout/layout view template name. When your controller's action method returns the ViewModel object, this object is attached as a child to the layout view model.
So, you can attach your own view models to the default view model to render the page of pieces that you want.
I want to add some rendering options to Views2 field handler (similar to 'Output this field as link' or 'Rewrite the output of this field') for a greater control over rendering of HTML markup (I need to add some extra attributes to tags). I want this additional options to be available for all (or at least most of the fields). Is it possible to replace default Views2 field handler (i.e. views_handler_field class) with my own field handler? There is a hook for submitting own handlers (hook_views_handlers) and there is a hook to tell other modules what handler should be used for given field (hook_views_data_alter). I also don't see a way to override default inheritance pattern for view_handler_field and its descendants. And extending every single field handler provided by other modules with my own classes seems to be pointless. Am I right saying that this cannot be the right way to solve this problem?
If I am right, what is another way to (1) extend field options form with some inputs and (2) alter rendering of this field based on inputs. I guess (1) could be achieved by altering form by default Drupal hook, but render method belongs to given field handler and I don't see a way to intercept its call and output altered markup.
In theory you could use a non-existant hook_views_handlers_alter to change the path of a class which is somewhere