Closed hagealex closed 2 years ago
Hello there! Thanks for opening your first issue on this repo!
Just a heads-up: Here at Backpack we use Github Issues only for tracking bugs. Talk about new features is also acceptable. This helps a lot in keeping our focus on improving Backpack. If you issue is not a bug/feature, please help us out by closing the issue yourself and posting in the appropriate medium (see below). If you're not sure where it fits, it's ok, a community member will probably reply to help you with that.
Backpack communication channels:
backpack-for-laravel
tag;Please keep in mind Backpack offers no official / paid support. Whatever help you receive here, on Gitter, Slack or Stackoverflow is thanks to our awesome awesome community members, who give up some of their time to help their peers. If you want to join our community, just start pitching in. We take pride in being a welcoming bunch.
Thank you!
-- Justin Case The Backpack Robot
Thanks for the submission @Alexander-Hagemeier . I understand the use case, I needed this myself a few times. The thing is... this is very very difficult to achieve in "a general way", that everybody and all fields could use... using the current technology stack. It would require some back-and-forth AJAX requests on user interaction, to change the inputs (or their values).
But you know what is GREAT for this back-and-forth-AJAX-requests thing? Livewire š It would allow you to define how your component works, what inputs/values it shows... depending on another field value. Exactly what you're looking for. All in PHP (no JS).
So I bet this will be fixed automatically when we add official Livewire support in Backpack v12. Until then, you can probably still do this, by creating a custom Livewire component. I know some people already do this, but there are some fields that just don't work with Livewire (the biggest one being select2
).
I'll leave this open until we implement Livewire support, so we don't forget - this is one of the use cases where that will be very very helpful.
Cheers!
Hey @tabacitu . Thanks a lot for the quick answer! Yeah, I can imagine that this is a difficult feature to implement. I'm glad to hear that there is some work in progress that might solve this. :+1:
@Alexander-Hagemeier I think @tabacitu missed two possible solutions:
select_and_order
to a fetch
field. (so basically a select2 with ajax)include_all_form_fields => true
in the field so when user search in the select, the endpoint receives the other form inputs.You can also code an "select_and_order_ajax", where you add and remove options via JS like other ajax fields, keeping the same interface of select_and_order.
Cheers, Pedro
@pxpm Ah nice! That sounds good. I will try these approaches as soon as possible :) If they work maybe it is worth to mention them in the documentation?
@Alexander-Hagemeier It will work š¤
All I told you is documented, sorry for just pointing to the fetch documentation, here it goes the include all form fields too: https://backpackforlaravel.com/docs/4.1/crud-how-to#add-a-select2-field-that-depends-on-another-field
I agree that there could be more examples, but with 4.2 on the door all the efforts had been putting on that baby. As soon as that is lauched and we stabilize with any eventual bugs found (hope none š¤ hehe š ) we have plans on writting more realistic examples and launch them as blog posts/documentation.
If you document your jorney setting up this scenario and would like to publish it as a tutorial or something, with the deserved credits of course, we could publish it in https://backpackforlaravel.com . Pretty sure it would help you and other developers in the future when setting up similar scenarios.
Thanks, I will be closing this for now, but feel free to keep the discussion going if needed š
Merry Christmas, Pedro
@pxpm As far as I understand, the documentation for the fetch
fields says, that it's assumed that one want to fetch data from another entity. Like:
'label' => "End", // Table column heading
'type' => "select2_from_ajax",
'name' => 'category_id', // the column that contains the ID of that connected entity
'entity' => 'category', // the method that defines the relationship in your Model
'attribute' => "name", // foreign key attribute that is shown to user
In my case I don't have a relation to another entity/model. The select options only depend on values that were set before in the form.
Am I overseeing something?
Nope, that is correct.
If you are not using with a model I don't think we have a ready solution for you atm.
Is one thing we plan to achieve by having all the relationships inside the relationship fields, and the other fields make them non-relationship dependant.
I came to a solution, it's a bit hacky, but it works. Basically simulate sending the options as if they were extracted from model!
Follow me:
Fetch operation need special configuration for this:
// YourController
use \Backpack\CRUD\app\Http\Controllers\Operations\FetchOperation { fetch as traitFetch; }
public function fetchIcon()
{
return $this->fetch(request()->all());
}
public function fetch($input) {
// you should have other form fields in the $input varial, do whatever you want to do, return the options in the following format:
return [
['some_field_name' => 'banana', 'id' => 1], // assuming that ->getKey() from the model you provide is 'id'
['some_field_name' => 'juice', 'id' => 2 ]
];
}
// the field definition:
$this->crud->addField([ 'label' => 'ajax field', 'type' => 'fetch', 'name' => 'some_field_name', 'entity' => false, 'attribute' => 'name', 'model' => $this->crud->model, // provide any dummy model, we are not going to use it, just make sure it's id field name matches the same name of the array in fetch 'multiple' => true, 'method' => 'POST', 'data_source' => backpack_url('monster/fetch/icon'), //the last part of this url is what comes after fetch-Something in the function 'include_all_form_fields' => true, 'wrapperAttributes' => ['class' => 'form-group col-md-6'], 'view_namespace' => 'crud::fields.relationship' ]);
Don't forget you probably also want to cast the db column in your model to array.
Let me know if it works for you!
Pedro
Thank you so much for your effort so far @pxpm . It looks like we're going in the right direction but I think we're still not on the point.
Just to clarify:
I have an entity "Animal." It has a column "specie" (this is just a string in the animal table). I can select from various species in a select in the form. Depending on what I selected I want another field (like an select_and_order) to have specific options I can choose from.
Your approach looks like that I have to write something in the input, then the fetch requests goes out and responds with what is written within the fetch()
method on the entity.
If I want to have, for example, a select_and_order field that has it's options depending on the value I previously set in the "species" select field...I'm not sure how to achieve this by the proposed solutions :/
@Alexander-Hagemeier to use with a select_and_order you need create a custom select_and_order that works with ajax I am afraid.
Let me know if you endup creating a solution and are willing to share with others!
Sorry can't be more help here.
Best, Pedro
Feature Request
What's the feature you think Backpack should have?
Hello everyone! I have worked on some projects with Backpack so far and in two of them we had a similar use-case where we had to build some workarounds. The use-case was/is:
I have an entity, let's say "Animal". An animal can have various information: Name, specie, age and so on. Now we have the case, that some additional information I want to store to the animal depend on what species I selected. For example I want so give them specific attributes via the
select_and_order
field.So long story short: If the "species" of the animal is value "x", I want other options for the
select_and_order
Field than if the value is "y". It would be great if I could configure this dependencies in the field-configuration and then the frontend handles it.I hope it's understandable what I mean :)
Have you already implemented a rototype solution, for your own project?
No. We build workarounds but nothing that would fit here as a good example.
Do you see this as a core feature or an add-on?
Core Feature. I faced this use-case in two projects so far and I'm sure that others might have the same/similar cases.