Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Variable entities
Wondering if there is an undocumented AddEntities method?
I find myself in a position where the addition of a new appointment may well need the addition of an entity as well to accommodate the new appointment. Is this possible or would it require resetting the entitylist completely.
If the latter, would resetting the entity list affect the existing appointmentlist that is would I need to recreate that as well after the entitylist property change?
I find myself in a position where the addition of a new appointment may well need the addition of an entity as well to accommodate the new appointment. Is this possible or would it require resetting the entitylist completely.
If the latter, would resetting the entity list affect the existing appointmentlist that is would I need to recreate that as well after the entitylist property change?
Comments
I'm still trying to determine how to best represent the data but even in the simplest form there's still a great potential for changing well, mostly adding of entities. Creating all the entities in advance is not really an option in most cases or I could end up with an entitylist 500,000 entities long to cater for an appointmentlist of 150-200.
I will rethink the approach to bring the numbers down. That will mean though, providing an external option to change what I was thinking of having as a group, which is fine but will then lead to regularly changing the appointment list. However, thinking about it, that could leave the entitylist alone regardless.
Can I expect any trouble with regularly replacing the appointmentlist as opposed to adding to it?
It's a casual labour force of which potentially any one person could work at any number of locations on any given day.
I was thinking of having the locations as groups and the individuals as entities but in that mode, to build all entities in advance would require having maybe 300 staff listed under each of maybe 1500 locations. Not really viable. This is just an example of possible numbers but fairly accurate for the database I'm looking at at the moment.
So I will go with just listing all staff as entities and have another means of selecting the location. If the user changes the location, then I'll need to change the appointment list but the entitylist will remain the same.
I'll see how that plays out and then determine if I need to have another rethink.
Yes, teams are an option but in this space, they're a preference not an absolute hence the original request about adding entities. These are the five people who normally work here but on any given day any one of the other 300 people we have on the books could be thrown into the mix.
Normally we work weekly/fortnightly so everything currently works out of edittables but a change in direction for a particular customer means that a daily view would be more appropriate and the schedule control is so much nicer to use. It's also the type of view the customer has seen whilst reviewing other products and they like it too.
Interestingly, I made the point at the time of these reviews that all these demos consisted of a handful of staff (entities) and would likely not be nearly as nice or efficient if they were to be implemented with real data.
It was an observation acknowledged as true but it's hard to beat the bells and whistles.
I shall persist. Not dead in the water yet.
Assume John, Suzy and the other 300 are equally qualified. They're not but they could be for the job required.
We have a location that regularly requires work. We always send John and Suzy because they live nearby, they know the place, they're experienced and they do good work. They're the preferred team.
Today, that same location calls up and says we need someone this afternoon for four hours. We can't send John or Suzy because they've both been working this morning. We don't turn down the work because we've got ten other people that are available today that normally perform the same functions, just at other locations. Any one of them can go. Potentially any one of the 300 could go if they were available.
Admittedly, those numbers go down when you start considering other factors like geographical regions, qualifications etc so I have to decide the best way to get an accurate subset and then strongly encourage the customer to maintain their data to conform.
Think technician that goes around to houses/businesses to connect up the internet. You have 300 technicians and a whole city of potential customers.
We have a client that does something similar. He uses the control to track trucks on the road. However, the application also displays the driver's name in the entity. The drivers aren't always driving the same truck each day so the application needed a way to dynamically swap the driver to the truck being driven on a particular day. We make this association on-the-fly based on how the driver is scheduled for each day.
Or is there a way to 'hide' unused entities in the tree as well?
I've been assuming perhaps incorrectly that when we're talking about hiding entities we're referring to unchecking the entitychecked property which hides them from the schedule but not the tree.