I am working on dashboard. In which I want 4 partial view. All that partial view display same kind of data but on different criteria.
My Dashboard contain:
1) Recent requests
2) Pending Requests
3) Approved Requests
4) High Priority Requests
All view contain data like, id, name of client, name of employee, requested date.
I am just eager to know that can I use single partial view(because all has same model data) many times on a Main View?
Yes, you can use single partial view multiple times on a main view,pass parameters to the controller action using ViewDataDictionary to distinguish between partial view types in your case 1) Recent requests 2) Pending Requests 3) Approved Requests 4) High Priority Requests.
Yo need to have common viewmodel for this
Related
Background
Let us consider a hypothetical scenario. Suppose we have five different tables in our database,
Customers
Categories
Products
Orders
OderDetails
Our client wants us to add a search bar to the frontend, where a user can search for a specific product and upon tapping the search button, matching products has to be displayed on the frontend.
My Approach for Tackling This Problem
In order to add the aforementioned functionality, I came across the following strategy.
👉 I would add an input box to ender the product name and a submit button.
👉 Upon pressing the submit button, a GET request will be sent to the backend. On the query parameters, the product name that has been entered by the user will be included
👉 Once the GET request is received to the backend, I will pass it down to the ProductsController and from within a method defined inside the ProductController, I will use the Product model to query the products table to see if there are any matching results.
👉 If there are any matching results, I will send them to the frontend inside a JSON object and if there aren't any matching results, I will set a success flag to false inside the JSON object and send it to the frontend
👉 In the frontend, if there are any matching results, I will display them on the screen. Else, I will display "No Results Found!"
Problem with My Approach
Everything works fine if we only want to search the products table. But what if, later our client tells us something like "Remember that search functionality you added for the products? I thought that functionality should be added to orders as well. I think as the list of orders by a user grows and grows, they should be able to search for their previous orders too."
👉 Now, since in our previous approach to search products was implemented in the ProductController using the Product model, when we are adding the same functionality to Orders, WE WOULD HAVE TO DO THE SAME THINGS WE DID IN THE ProductsController AGAIN INSIDE THE OrdersController USING THE Order model. It does not take seconds to understand that this leads to duplication of code.
Problem Summary
❓ How do we add an API endpoint in laravel for a search functionality that can be used to search any table in our database and get results, instead of the search functionality being scoped to a specific controller and a corresponding model?
A good start would be to create a trait called something like searchable and add it to all the models you want to search and put any shared logic between the different models in there. Possibly you'd want to manually allow different columns so in each model you have an array of searchable columns which you'd refer to in your trait.
Your controller would have to point to the related model and call a method in the trait that searches.
As others have pointed out this is a high level question so I won't go too much in detail. Of course there are a million ways to implement this, just try and keep shared logic in place.
I have a Slack dialog that has two SELECTs and both are pulling data from an external data source. However, the available options of the second SELECT are entirely depending on the selected value of the first SELECT. Is it possible that slack can somehow pass the selected value of the first SELECT to the payload of the second SELECT's request?
I can't seem to find a way to do it.
Thanks!
Assuming you are doing this within a modal view, there are two ways to approach the problem:
Approach 1: stick to 1 view and update it*:
The user picks from list 1.
This triggers a block action payload to your app which gives you access to their choice.
You can then update the view with new input blocks for list 2 that you've set up correctly.
The catch here is that list 1 can not be an input block, but rather an action. It will not be part of the final payload of the form.
Approach 2: split into 2 different views*:
The user picks from list 1.
The user submits view 1
You handle the view_submission event by pushing a new view with the appropriate list 2
This question regards the structure of applications when using laravel.
I have a view for making a sale/purchase from a company. This single view contains a client search, product list, service list and a staff list. Each of the items listed above has their own model. In the view, i would say search for a client which will call a function within the controller and populate a list. Same for the products and services etc etc.
What confuses me is that for the client search i would click a button that would fire to a url like /clients/search/search string, which would return the array of clients to display on the page. This function seems as if it would be appropriate within the client controller. I am unsure as to how i would be able to maintain the information from the client search and other parts of the sale to then submit it all together under one single controller (let's call it InvoiceController).
Can controllers share the functions from other controller? Do i simply store the information in a session variable? Do i simply put all relative functions to this sale under the InvoiceController?
Thanks for any help!
I would do a search for clients against the client controller, then when you select the client add this (client_id) to your invoice form. then save this with other invoice info via the invoice controller
After much deliberation, it appeared that AJAX was the simplest answer. In this case i used Angular JS and had that running a controller to fetch each segment of the Invoice, then use the main InvoiceController in Laravel to fire the final update.
I have quite a complex class that has three one-to-many relationships and two many-to-many relationships with other classes. What I would like to do is to enable the user to fill all the details one by one - in one step or even better in multiple steps (wizard).
My class is called PeriodicTask - user has to select one Server object (which represents SQL Server instance ) and depending on the selection I need to present the user with the ability to select which databases he wants to use ( the best option would be to use checkboxes). I don't really know how to achieve this.
I would start with creating an action that returns JSON with databases for the selected server. It'll be invoked by jQuery. So far so good, but what to do then?
Should I add <input type="checkbox"> to the form for every database or maybe create another form and post to some other action? How to parse that when the form is submitted? Can I split it somehow into smaller steps ? HTTP is stateless so I somehow need to pass or remember the data that was previously submitted - how?
PS> I'm using Entity Framework here, so part of the class hierarchy is as follows:
You could do it like this:
User selects server instance from
dropdownlist.
After selection dropdownlist fires "change "event, handler of
which loads databases list to form using ajax (your action can provide JSON or html with checkboxes)
User selects checkboxes and presses
submit button
On submit you collect
checked item and post to action
using javascript
I would look at creating helpers for each of the options that would be self contained, they could maintain the state themselves.
Another cool option would be to create a tree view, where the root level is your server and next level is database. Load the data into a ViewModel so that it can be used as the data source for a tree view. It seems like a nice interface for what you have.
Believe it or not the Microsoft site is a great place to start when learning MVC
http://www.asp.net/mvc
I have a web application built on an MVC design.
I have a database which contains a large number of objects (forum threads) which I can't load into memory at once. I now want to display (part of) this collection with different filters in effect (kinda like what stackoverflow does with questions sorted by date, votes, tags etc).
Where do I implement the filtering logic? It seems to me that this must go into the model part of the application, as only models interact with the database (in my implementation). If I make the filtering a part of the view, then the view must access the database directly to get the list of filtered objects, right? I'd like to avoid this, because it exposes the database layout to the view. But at the same time, displaying different views of the same data should be implemented in the view part of the application, as they are just that -- different views of the same data.
So how do I resolve this? Do I create an additional model, say, FilteredThreadsList, and have it remember the filter to use, and then use a FilteredView to display the list of threads that FilteredThreadsList spits out?
Or do I have to build a ThreadQueryier that allows views to query the database for certain thread objects, so I can have the filtering logic in a view without exposing the database backend?
You should never query data from the view. I don't know what framework you are using in particular but as for Ruby on Rails (should be the same for other frameworks) we always pull the necessary data from the controller and store all that information into a variable. The variable will be accessed by the view which can help you avoid querying your database directly from the view.If the code to query the database gets too lengthy in the controller, insert that code into the model instead so it's more maintainable for your project in the future. Additionally, you can call this model method from multiple places in your application if needed. Good luck!
From an architectural point of view, the model should be having the code for filtering. This is so, because in many applications the code for filtering is not trivial and has a good amount of domain logic in it. (Think of filtering top gainers from a list of stocks). From your example as well, it looks the same since you might want to filter by vote or by date or by tags and then by answered or unanswered etc.
In some very simple applications that deal with search/list of entities and allows Create/Read/Update/Delete of an entity, the pagination, sorting and filtering logic is usually very generic and can be implemented in a controller base class that is inherited by all entity-specific controller classes.
The bottom line is this: if your filtering logic is generic put it in the controller else put it in the model.
Model, that's only bunch of entities.
View provides a visual representation of the data from model - use as much of views as you want. If your application is web based, you can fetch data into browser just once (AJAX) using and re-use them for different UI components rendered in the browser.
As for what entities and what view to use for their representation, I think it's work of Controller. If you need some support for it on "model layer", add it but avoid tight coupling.