Looking to rebuild account pages for users of a Laravel 8 based application using something like Inertia/Livewire, Vue/React to make just the account area an SPA. User accounts currently have many pages in which to manage their items and have a dashboard that summarises item data that link to item listing pages for managing.
Ideally the new dashboard will have component based widgets which would load the HTML with temporary place holders for the items whilst the data is being requested. Not sure what would make a better user experience, having the whole page show temporary place holders for dynamic data and then all populate at the same time or populate each component as and when the data is ready.
Would it be more efficient to have each component request its own data individually or should each component specify what data it needs to the parent component (dashboard) which then does one request for all widgets?
The widgets would link to item listing pages where users can manage items. The way the listing pages should work is very similar to that of Asana, when an item is selected it opens a panel to the right of the list which loads the data related to that item. Again, when the panel opens it has place holders until the data requested has been fetched.
With Inertia the data can be queried in the controller and then passed as props to the view that Inertia renders. Items would be passed in this way and then listed on a listing page component. The URL should update from /items to /item/123 when clicking an item so it would have its own dynamic route that passes the item id to the relevant action.
Would this have its own action separate from the one that gets the initial list of items?
The list still needs to be there and used to click between items so was thinking it could actually use the same action?
Items could be in the thousands and will have filtering options so pagination and throttling will be necessary.
Been looking at Inertia with Vue so far and it looks to meet requirements, can’t change from using Laravel 8, just wondering what approach would be most suitable or if there is another approach that should be considered. Interested to hear how others might go about it.
Related
I would like to be able to include a link in a view on the contact entity of dynamics crm that will pop a custom window that we have built. The custom window needs the contact id and the user id in order to function. Our users have requested that such a link be on the view rather than having to go into the contact record itself.
So, is it possible to create a dynamic URL that will be utilized from the view and will be able to determine the contact id and the user id?
I would assume I need to do this with a web resource, but I've only ever used a web resource in an iframe.
I have tried to build a web resource and just use the web resource's link to put into a field and display that field on the view, but obviously that didn't work.
Essentially the link would build a url and then pop up a new window with that url. Here's my url structure: https://example.com/mscrm/ticketing/Activity/PhoneCallSave.aspx?cId=00000000-0000-0000-0000-000000000000&id=%7b00000000-0000-0000-0000-000000000000%7d&orgname=00000000-0000-0000-0000-000000000000&userid=%7b00000000-0000-0000-0000-000000000000%7d&type=contact&token=Zf7Hi3PFokqRn3RnTD6hPA
This is an interesting request that I have not encountered before...
I thought about using a URL-formatted field, and the fact that D365 by default will hyperlink lookup fields. But, with those options you'd have to write data into a field on each Contact or create an entire new record for each Contact, on the fly.
What about creating a separate web resource that contains a table with only one column to hold the dynamically generated URL's? Run the same query as the view to get the Contacts, then generate the URL's and populate them into that "mini-grid". Put the main Contacts view in one section (say two-columns wide), and the mini-grid web resource in a single-column section right next to it, with no border and the same row height.
This way you rely on the main Contact grid for the Contact info, with the mini-grid holding your dynamic URL's (with proper link names of course, rather than raw URL's).
The high-level steps would be:
Get the user's id from the form context.
OnLoad of the sub-grid, get the set of Contact Id's.
Generate the URL for each Contact.
Populate the URL's into the mini-grid in the same order as the Contacts in the sub-grid, so each row in the mini-grid lines up with its Contact row to the left.
Another idea would be to look into the custom icon functionality in V9 to see if there are any hooks in there where you can add a dynamic URL.
You could also write a RetrieveMultiple plugin to dynamically populate a URL-formatted text field. RetrieveMultiple plugins have their caveats. But, how bad is it?
An unsupported option might be to hack the DOM and put your dynamic URL into a blank URL-formatted field in the view.
My current setup looks like this(from here, mostly):
This is the result of my home view. What I intend on doing is keep those 2 sidebars in place and refresh only the content part.
My question: What is the obvious solution to this in django?
From what I read so far it seems to be using Ajax to see what exactly the user clicks on the sidebars and return only a part of the HTML which would be the div where all the content is. (or return a JSON and refresh that div depending on the JSON values?)
I need to avoid refreshing the entire page, it seems useless. I could forget about Ajax and just run on separate views but I would have to pass every time a context variable to populate the sidebars depending on the user and this seems to be an overkill.
Even more specific: On the push of a button on the navbar now that is a href- links to another page. In order to make it refresh only part of the page what should the button trigger? Should it trigger a jquery function or is there a better option?
If your concern is only about left sidebar calculations, then you can go with caching
Django allows to cache part of page - sidebar is ideal item for caching. If sidebar is different for users (I see at least playlists menu item), then it's also possible to implement fragment caching per user, check Vary on headers part of documentation.
Using ajax will complicate your development process - generate html/json encode/render it on user side, etc, etc. And now almost no one uses django in this way. If you want pure single page application, then I suggest you to take a look at some javascript framework like Angular, Vue or React + Django API backend.
I am currently working on a project in ServiceNow that requires me to configure around 500 descendants of the Configuration Item table by adding multiple form sections to the CI's with around 10-20 fields in each of these form sections. I currently am doing this by going into the Form Design for each CI, and manually adding these form section and fields for every CI individually, which takes far to long to do for 500 CI's.
Is there a way to add a form section to multiple CI's without having to go into the form design on every CI you want to change and adding it manually?
Technical answer: yes, because all of that form layout data is stored in tables (sys_ui_form_section, sys_ui_section, sys_ui_element, etc) that you could script to insert relevant records. However, due to the complexity (form sections, form elements, ordering) and the potential to run into conflicts (forms differ between tables), I would recommend this only as a last resort.
I think the real question is why is it required to have all of those fields displayed on the forms? If you're populating data from Discovery or a large import, can those fields just be visible by a list page, or just be available to use in filters? Will users actually be clicking to view a CI record and need to see that data on the form? The other part to consider is which view you are adding all of these form sections and fields to. As an example, a user won't see the data on a reference field hover if you're only making changes to the Default view, and won't see any of the fields on a mobile device if you don't add to the Mobile view.
In Angular, speed is the name of the game and rendering views with useful data as quickly as possible is always sought after. Angular allows us to reference data between the Controller and the View seamlessly using Angular's templating engine, which can make rendering views with correctly bound data lightning fast.
For example, lets say we have a simple Angular App which is simply a table of contacts with fields like First Name, Last Name, Phone, Email, and Address. We then want a Details view that appears when you click on a table row. We can wire up the <tr> to change views on click like this
<tr ng-repeat="contact in Contacts" ng-click="showDetails(contact)">
Then we can change the view and "instantly" show contact data in the new view. For example, we can change an <h1> at the top of the page to be Contact - John Smith using the data that was provided in showDetails.
While this data is being shown, more data can be retrieved from the server asynchronously that will then fill in the rest of the fields.
However, what do we do if we want to get to this details page directly from the url? If the contact table was sitting at /contacts and the details page was something like /contacts/detail/1 then attempting to go directly to /contacts/detail/1 would result in the <h1> above to be blank.
This is clearly because we did not use the showDetails() method to invoke the view and pass the clicked contact into it directly. In this case, we would need to take the contact id in the URL and run an AJAX request to get ALL of the data.
My question is, at what point do we draw the line between trying to make our views and data quickly accessible and making them robust?
Robust is a must.
So we need to start there. Then we can move forward to optimize and make data "quickly accessible", as you put it, as much as possible.
In order to do that, every view in an SPA that is directly correlated to a URL needs to be initially stateless. That basically means that a reload on any url will load the desired view correctly and completely.
We can get the best of both worlds by using nested routes. If every route loads only what it needs, but also draws on parent routes (loading them if necessary, or just using them if they have already been provided) then you can achieve both robustness and "quick accessibility" to data.
In your particular example, the base route would be contacts. Then there could be a nested route inside of that which would display the details of a particular contact, contacts/detail/{id}. Loading the base url would load the list of contacts, and loading the details view would load both the list of contacts and the details of a particular contact. To provide quickly accessible data when going to the nested view, we could include logic that checks to see if the parent view data is already loaded, and only load if necessary. Then when navigating from the contacts to the contacts/detail/{id} view, we could quickly display data from the parent view in the child view, while loading data specific to the child view. A reload at contacts/detail/{id} would simply load both. When navigating back to the parent, the parent data would already be loaded.
If you were to use something like ui-router to create complex routes, then you would not use showDetails() to alter the model, you would use showDetails() to alter the route. Then your model would set itself up based on the route, and your view would follow.
For example, you could have something like:
$scope.showDetails = function(contact) {
$state.go('contacts.detail', { contactId: contact.id });
};
Then the controller could use $stateParams to retrieve any data you wanted for the specific contact from the server (asynchronously using promises). You could also include your own flavour of caching/loading via services to manage things like performance if you found it necessary.
I'm trying to get my head around Joomla 3.2's new framework and develop a capability/feature in a custom component (lets call it com_custom) that can load com_content's category blog view within com_custom's view, using the category blog's menu item id!
There are quite a few codes that I saw here and around the web that only load the default view of the 'imported' component, rather than the view specified in the imported component's assigned menu parameters. Also, most of these codes use deprecated functions, so I'm quite lost now.
So what I need to be able to add is:
Include a category blog view (say from menu item id 223) within com_custom's current view.
It should import all of the parameter setting of the category blog's menu item.
It should not be in an iFrame
Any help is much appreciated!!!
You can't include com_content because it makes use of the JPATH_COMPONENT constant in 14 different places, most notably in content.php (the main file that's loaded, even before the controller) and in most views, in order to load helpers.
These are the first two ways that come to mind to overcome this limitation:
Instantiate the articles model, load the data, and use your view to display it; you'll need to dig into the menu table to find the params related to your menuid; Bewre: Search engines might consider the duplicate content as spam.
Insert a jquery ajax call to get the url of the menuid adding &tmpl=component i.e.
index.php?option=com_content&view=category&id=13&Itemid=522&tmpl=component
The latter will be much easier to implement. Search Engines will NOT see the different content under different urls, since it's ajax.
Regarding the limitation, see also this question:
Joomla how can i create model from other component