I have a simple nattable with column header layer. But when I click on column header entire column gets selected. I have to have a selection layer for only bodydata layer.
Also I want to disable all selection/click events on Column headers.
The default selection bindings are configured via DefaultSelectionBindings configuration. This is automatically registered when creating the SelectionLayer with autoconfigure turned on.
You can either turn the autoconfiguration off and register customized configurations. The easiest way would be to create a subclass of DefaultSelectionBindings and override configureColumnHeaderMouseClickBindings() to do nothing. And then create a subclass of DefaultSelectionLayerConfiguration where you override addSelectionUIBindings() to register your binding configuration. This customized selection layer configuration then needs to be added to the SelectionLayer.
The other way would be to try to unregister the applied ui bindings after NatTable#configure(). But for that approach you need some more in-depth knowledge to know what you need to unregister.
Related
I am trying to extend an update view to include a list view of some related items below the edit form.
I have two models, Publishers and Volumes, which have a many to many relationship. What I am trying to do is this.... when a user clicks on the edit button for a publisher, I want them to go to a page with the standard edit fields, but also have a list view below the form that lists all of the volumes that are connected to that publisher via their relationship.
Is there an easy way to do this?
I hope this makes sense.
As #tabacitu mentioned, Backpack doesn't currently have an built in solution for this. That said, this could maybe work for you:
This would allow you to use all functionality of the nested list view including interacting with the entities without conflicting at all with the parent
Step 1, Build your normal CRUDs
Build out two normal CRUDs, one for Publishers, and one for Volumes
Step 2, Make a frameless layout
copy vendor/backpack/base/layout.blade.php
name it frameless-layout.blade.php
remove #include('backpack::inc.main_header') and #include('backpack::inc.sidebar')
Step 3, Make a custom list view
copy vendor/backpack/crud/list.blade.php
name it sub-list.blade.php
change the top line to #extends('backpack::frameless-layout')
Step 4, Make a custom field
Create a custom form field that contains an iFrame
Inside your custom field template, have it set the url of the iFrame to the "list" url of the related resource
You'd also need to utilize List Filters and a method for setting them dynamically so that the sub-list shows only the records related to the parent
Step 5, Configure and use the field
In your crud controllers, use the addField to add the the configuration for the new field and its related model
Indeed, there's no standard functionality to do that in Backpack. It's a pretty unusual way to do things. But it's not too difficult to achieve it.
If there aren't too many Vendors for one Publisher (as I expect it's the case here), I would keep it simple and NOT try to include the entire Backpack list view (with ajax, buttons, filters, etc) on top of the form. I would add a standard HTML table with the entries (and optionally buttons to Edit Vendor with target=_blank).
Here's how I would go about it:
In the Publisher CRUD, I would use a custom view for the Edit operation; you can do that using $this->crud->setEditView('edit_publisher_with_vendors') in your setup() method;
In that custom edit view (edit_publisher_with_vendors.blade.php in my example), I would copy-paste everything inside the edit.blade.php view that Backpack/CRUD is using, and add a table with the Vendors on top of the Edit form; notice you have the current entry as $entry in this view; since there's a relationship on the model, you would be able to check if it has vendors using $entry->vendors()->count(), and get the vendors using $entry->vendors.
Hope it helps.
I have successfully populated a TreeView via creating a TreeDataProvider and customized the icons and its collapse-able property. Now I want to be able to drag and drop its ViewItem(s) onto a WebView. There are unfortunately no samples for drag and drop. Reading through the TreeView source, ViewItem(s) are created in HeightMap.OnInsertItems() via the TreeView.createViewItem(), from the derived class.
The public TreeView.onInsertItem() would appear to be a great extension point, extending TreeView and onInsertItem() and capturing its ViewItem parameter. This Unfortunately, the creation of the concrete class, ExtHostTreeView, that is ultimately created, is buried in layers of private methods (createExtHostTreeViewer()).
Strangely, the ViewItem has a setter for draggable. However, how would you ever get a reference to the ViewItem to set it? If there is a way to do this please point me at an example. If there is not, I would be glad to fork and implement it. Leaving the existing onInsertItem and perhaps add an array of handlers to be added to with an addOnInsertItemListener() method? Or perhaps use RxJS?
There are so many places this could be used. You could drag template fragments into documents or code, DSL rules into a expert system, configuration file values into parameters or right hand values (generating the code to retrieve the value). Thank you for any assistance.
It seems that drag and drop in custom views is currently not supported. There's a (fairly popular) feature request for it here:
Add drag and drop for contributed tree views (#32592)
As of version 1.66 (March 2022) there is a TreeDragAndDropController which can be used for some drag & drop actions.
In April 2022, their sample focuses on drag & drop within a tree view: https://github.com/microsoft/vscode-extension-samples/blob/main/tree-view-sample/src/testViewDragAndDrop.ts
It is also possible to use the text/url-list type as described in the documentation to allow for dragging files to the editor panel: https://github.com/microsoft/vscode/blob/dc2f5d8dd1790ac4fc6054e11b44e36884caa4be/src/vscode-dts/vscode.d.ts#L9843-L9859
It is not clear to me yet whether it is possible to drag arbitrary data to webviews or to use standard HTML5 drag & drop API in a webview to allow dragging data to a custom tree view.
I am working on a eclipse rcp application where I am using TableViewer component on a wizard page. I was able to add editing support to the table columns and was able to save the data on the viewer object. Does this edit get saved to actual data? if yes how can I get this updated data within my application to do further processing?
Assuming you are using org.eclipse.jface.viewers.EditingSupport to provide cell editors for the table.
The EditingSupport.setValue method is responsible for setting the new value in the original object provided by the content provider.
To validate values you will either have to write your own CellEditor or use a class derived from one of the existing call editors such as TextCellEditor and overriding appropriate methods.
GWT's Editor framework is really handy and it can not only be used for editing POJOs but also for read-only display.
However I am not entirely sure what the best practice is for doing inline edits.
Let's assume I have a PersonProxy and I have one Presenter-View pair for displaying and editing the PersonProxy. This Presenter-View should by default display the PersonProxy in read-only mode and if the user presses on a edit button it should allow the user to edit the PersonProxy object.
The solution I came up with was to create two Editors (PersonEditEditor and PersonDisplayEditor) that both added via UiBinder to the View. The PersonEditEditor contains
ValueBoxEditorDecorators and the PersonDisplayEditor contains normal Labels.
Initially I display the PersonDisplayEditor and hide PersonEditEditor.
In the View I create two RequestFactoryEditorDriver for each Editor and make it accessable from the Presenter via the View interface. I also define a setState() method in the View interface.
When the Presenter is displayed for the first time I call PersonDisplayDriver.display() and setState(DISPLAYING).
When the user clicks on the Edit button I call PersonEditDriver.edit() and setState(EDITING) from my Presenter.
setState(EDITING) will hide the PersonDisplayEditor and make the PersonEditEditor visible.
I am not sure if this is the best approach. If not what's the recommended approach for doing inline edits? What's the best way to do unit-testing on the Editors?
If you can afford developing 2 distinct views, then go with it, it gives you the most flexibility.
What we did in our app, where we couldn't afford the cost of developing and maintaining two views, was to bake the two states down into our editors, e.g. a custom component that can be either a label or a text box (in most cases, we simply set the text box to read-only and applied some styling to hide the box borders).
To detect which mode we're in, because we use RequestFactoryEditorDriver (like you do), we have our editors implement HasRequestContext: receiving a null value here means the driver's display() method was used, so we're in read-only mode. An alternative would be to use an EditorVisitor along with some HasReadOnly interface (which BTW is exactly what RequestFactoryEditorDriver does to pass the RequestContext down to HasRequestContext editors).
Yes,Presenter-View pair should be. But Here two ways to achieve this feature if you like to go with:
1) Integrate Edit/View code design in one ui.xml i.e.Edit code in EDitHorizonatlPanel and View code in ViewHorizontalPanel.The panel has different id. By using id, show/hide panel with display method. if getView().setState() ==Displaying then show ViewHorizontalPanel and if getView().setState()==Editing then show EditHorizontalPanel.
2) Instead of using labels, Use textboxes only. set Enable property is false when you need it in view mode otherwise true
You have created two Presenter/view but I think if Edit/View function has similar code so no need to rewrite similar code again and again for view purpose.
If a big project has so many Edit/View function and you will create such type of multiple View/Presenter than your project size become so huge unnecessary.
I think that whatever I have suggest that might be not good approach but a way should be find out which help to avoid code replication.
I have a GWT App and I am using GWT MVP with Places / Activities.
My application layout is something like
MENU | CONTENT
The Menu and the Content displays will change dynamically and one changes separately from the other. What I mean by this is that when the Content display changes I do not want to have to update the Menu display and vice versa. Both displays need to be able to respond to PlaceChangeEvents and update themselves when these occur. The problem is that each display should only update in response to certain PlaceChangeEvents, ignoring PlaceChangeEvents that are directed at the other display. However this does not work using the 'standard' GWT MVP pattern because even when each display has it's own ActivityManager they will automatically pick up ALL PlaceChangeEvents because there is a single PlaceController listening on a single EventBus. The only way I can see to do this is by having two EventBus's and two PlaceControllers - one for the Menu and one for the Content. So my question is whether this is a good solution or is there a simpler/better way that I am missing? One problem with this solution is that the PlaceHistoryHandler can only be registered with one of the EventBus's.
Place changes are actually controlled by ActivityMappers. They get a Place and return the corresponding Activity. This is where you control how Places are mapped to Activities:
You need to create two ActivityMappers (MenuActivityMapper, ContentActivityMapper) and then instantiate two ActivityManagers each with it's own ActivityMappers. Then for each ActivityManager you call setDisplay(AcceptsOneWidget display) where for each you pass in an area (display) where it will show it's content.
For menu you will probably only use one Activity, since it's available in all Places. So MenuActivityMapper.getActivity() will always return the same instance of the MenuActivity. To enable MenuActivity to still adapt it's look based on place changes, MenuActivity should listen to PlaceChangeEvents.