Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Other HTTP Methods #106

Closed
devajmeireles opened this issue Sep 5, 2023 · 8 comments
Closed

Support for Other HTTP Methods #106

devajmeireles opened this issue Sep 5, 2023 · 8 comments

Comments

@devajmeireles
Copy link

Perhaps this is not the purpose of Folio and therefore this ticket can be closed, but considering that we have different types of HTTP methods, it would be extremely useful if Folio supported this following the following pattern:

contact.blade.php // GET ...
create.post.blade.php
destroy.delete.blade.php
update.put.blade.php

I could suggest that this feature is possible via the FolioServiceProvider, but if Folio intends to support routes via files, IMO the best place would be the prefix shown above.

If I'm totally wrong and the Folio will never support other HTTP methods instead of GET, then shouldn't this at least be documented?

@crynobone
Copy link
Member

It doesn't make sense to have "views" for POST, PUT, and DELETE, as it should handle form requests and redirect/throw errors.

@driesvints
Copy link
Member

I don't think it was ever intended for Folio to have routes other than GET, sorry.

@devajmeireles
Copy link
Author

I don't think it was ever intended for Folio to have routes other than GET, sorry.

So this should at least be documented? We need to care about new users too.

Why will the "Controller" class be kept even though it is apparently useless? To guide new users perhaps? It's the same reasoning.

@inmanturbo
Copy link
Contributor

If you just want to eliminate the need for controllers and/or route entries altogether, you can use https://github.com/livewire/volt together with folio to handle CRUD functionality from right within your views

@jeffturcotte
Copy link

jeffturcotte commented Feb 6, 2024

Can this be reconsidered?

In a situation where you are using HTMX or similar client library, it is not uncommon to have all methods GET/PUT/POST/DELETE returning HTML to swap into the dom. It would be amazing and incredibly convenient to be able to use Folio's page-based routing in such scenarios. I don't see why the limitation is needed here and seems to just have been inherited because (I believe) the standard Route::fallback handler is used. Traditional "page-based routing", where you'd throw a bunch of PHP files into a directory, worked with every method. :)

Ideally, there'd be a way to configure this via the ServiceProvider for a given folio path. I'm not advocating for the filename based solution in the original post.

From the HTMX docs:

Submitting a form via htmx has the benefit of no longer needing the Post/Redirect/Get Pattern. After successfully processing a POST request on the server, you don’t need to return a HTTP 302 (Redirect). You can directly return the new HTML fragment.

Thanks!

@inmanturbo
Copy link
Contributor

inmanturbo commented Feb 6, 2024

@jeffturcotte I use this for working with HTMX https://github.com/inmanturbo/turbohx/blob/main/src/TurboHX.php

You can install it with composer require inmanturbo/turbohx
no docs or readme yet but I suppose I'll get around to it if others are going to use it. PR's welcome.

@jeffturcotte
Copy link

Thanks @inmanturbo! My comment still stands, but I'll take a look at your package. 👍 :)

@inmanturbo
Copy link
Contributor

@jeffturcotte It depends on Folio, binds another manager and brings in all methods. Also a few matchers for catching many routes in a single file as described in this pr: #119

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants