vanstyn / RapidApp

Turnkey ajaxy webapps
http://rapi.io
Other
48 stars 15 forks source link

Cannot use custom grid for relationship columns #194

Open sammakkoinen opened 3 years ago

sammakkoinen commented 3 years ago

I would like to use custom grid as editor for some relationship columns (to show only a few columns, i.e. use different include_colspec, different toggle_edit_cells_init_off setting). At first glance it seems to be possible with setting auto_editor_type => 'grid', display_columns and auto_editor_params. However the grid setting is effectively disabled in Catalyst::Plugin::RapidApp::RapidDbic, line 233:

 if(!$TSconfig->{auto_editor_type} || $TSconfig->{auto_editor_type} eq 'grid') {
      $class->TableSpec_set_conf(
        auto_editor_type => 'custom',

Yet somehow it still works in CoreSchema (RapidApp::CoreSchema::Result::SavedState), can't still figure out how. What is the intended way to use the 'grid' auto_editor_type, how do I use custom grids for relationship columns and why is it disabled?

vanstyn commented 3 years ago

@sammakkoinen - when you have NavCore enabled, which I assume you do, you can setup a default view in Source Default Views under CoreSchema, which can be any saved search you like. This is probably the bit you're missing. When a default view is set, that is used in all locations that a grid display is shown for the source. A feature I'd also like to add is the ability to have different default grid views for different contexts, such as for specific relationships, FK selectors, etc. But as of now, there is only either the view that is implied by the include_colspec, or the default view. If getting the separate default views for different contexts is something you'd be interested in contributing on to make happen, let me know

sammakkoinen commented 3 years ago

Yes, I was looking for the latter feature (namely, different grids for FK selectors), however, as I have found, it seems to be already mostly implemented and working in CoreSchema Admin: when you enter "Source Default Views" and Cell Editing is On, clicking on a cell in View column brings up a customized grid with only one column and no Add/Edit controls - which seems to be set up in RapidApp::CoreSchema::Result::SavedState:

__PACKAGE__->TableSpec_set_conf( 
    title => 'Saved View',
    title_multi => 'Saved Views',
    iconCls => 'ra-icon-data-view',
    multiIconCls => 'ra-icon-data-views',
    display_column => 'title',
  auto_editor_type => 'grid'
);

This is very close to what I need (but I still may need Add/Edit controls and Cell Editing On toggle). Also, if I remove the $TSconfig->{auto_editor_type} eq 'grid' part in the line I mentioned above, it starts behaving the same way outside of CoreSchema too. Is there any problem with this way to go?

vanstyn commented 3 years ago

Yes - remove auto_editor_type config. you don't need it unless you want to change the default behavior, which is already a "grid" but a better version of the 'grid' override you are applying. Usually the only reason you would want to define a value for auto_editor_type is if you want yo set it to "dropdown" which makes it a dumb dropdown list, or "combo" which makes it a smart drop down list with type-ahead search ability. But if you want it to just be a grid and to use the same default view, you leave the value unset because that is already the default.

If you haven't already, I suggest you watch the "Chinook" demo which goes these topics in detail and the associated rationales: http://www.rapidapp.info/demos/chinook

vanstyn commented 3 years ago

also, I was not in the channel for a while because the PC that I had dedicated to my IRC took a dump and I hadn't found the time to fix, but I have now and so you can find me again in #rapidapp in irc.perl.org

sammakkoinen commented 3 years ago

But if you want it to just be a grid and to use the same default view, you leave the value unset because that is already the default.

Yes, but I need a grid with a different view, not the default. So, for example, the default view for a source is to show all the columns and have Cell Editing On, but if the same source is used as a FK for a related table, it should show only a few columns (or one) and have Cell Editing Off, but still have pagination and Add New button (that's why dropdown/combo is not an option).

vanstyn commented 3 years ago

But if you want it to just be a grid and to use the same default view, you leave the value unset because that is already the default.

Yes, but I need a grid with a different view, not the default. So, for example, the default view for a source is to show all the columns and have Cell Editing On, but if the same source is used as a FK for a related table, it should show only a few columns (or one) and have Cell Editing Off, but still have pagination and Add New button (that's why dropdown/combo is not an option).

Right, and as I mentioned, that would require adding a new feature that will allow that. It is of course possible to try to hack the internals, but I highly advise against it as none of that would be considered part of the exposed API and would more than likely break in the future (and you'd probably not be able to figure it out anyway). The right solution is to add the feature that allows more than one "default" view, based on the context, which I already have ideas on how that could work and be clean.

Are you interested in discussing a collaboration to get a new feature like that added? As I mentioned, this is something that I'd like to see added as well, but it is not high enough on any lists for it likely to happen in the near future, unless one of our clients needs it (that's how most RapidApp features end up getting made). However, if you/your organization want the feature enough to be willing contribute to its creation in some manner, either financially or by writing code yourself directly, then let's talk

sammakkoinen commented 3 years ago

Yes, let's discuss it, I think it's possible for me to contribute to the code.