Ext Scheduler - Scheduling/Planning/Gantt component

Ever needed a way to schedule projects/tasks/meetings/rooms/staff? Check out this new component, the Ext Scheduler .

Attachment 29266

Live Examples: http://bryntum.com/examples.html

Current status:

• Homepage: http://www.bryntum.com
• Live Examples
• Requirements : Ext JS 4 or Ext JS3 (could be adapted to 2.x without some features)
• Feedback/bugs forum
• Documentation
• GWT Ext (GXT) component: Forum thread here, release March 2010
• IE6 Support: Hrmmm

To receive information and updates, either

• Send me an email at mats@bryntum.com.
• Join the Facebook page
• Follow me on twitter

Time for coffee, enjoy! ~o)

Just WOW =D>

Nice...

I am in the design phase of just such a component. It would be for a port of reservation system from windows to web, where users can interact with the calendar to book or change reservations. I was planning on implementing this as a grid column, so that I got the row support, grouping, sorting and so on for free, and have already built a proof of concept.

Now that I see this, I may have to rethink things, because it might make more sense to buy this component and base our work off of it.

Some questions:

- You don't seem to have used a grid as your basis. What sort of support is there for extra columns (with sorting), and letting the user quickly enable/disable grouping in different data elements?

- We would need to support both confirmed reservations (may not overlap) as tentative reservations (may overlap). Is it difficult to integrate support for these two kinds of objects in the same scheduler? Eventually we also want to use the component as a basis for our tasks/appointments planner port from windows to web, where both types may overlap with the other type, but not with themselves, and where they need to have different heights (one hiding below the other) so you can interact with them both.

- What sort of support is there for integrating business rules of where calendar items can be moved? For example, we have per-resource non-available time, which can differ from day-to-day. This would need to be marked invalid in the calendar and behave that way when you try to drop an item on it. We also have preparation and cleanup time around reservations, which prevents an item from neatly matching up to the next reservation. And then there are things like minimal time ahead, which prevents you from booking a resource too close to the time of the booking (so service providers have time to set up the reservation's requirements, such as food and cleaning services).

- Could you go into a little bit more detail of how the data backing for this component is done? I am curious how well it scales and copes with on-demand loading scenarios of large data sets (say, a 100 resources, each in week view). Can data be cached client-side? Is it possible to reuse the same data store for more than one scheduler?

- We have resource bundling. A room might already contain some equipment, and might be made up of partitions which can be reserved separately. When this is then booked, this must be indicated as a group in the calendar, and when moving those items this also has to occur as a group. Is something like this feasible to integrate?

Phew, a lot of questions there. Not all of that stuff is necessary, we might end up shipping only a subset of what the windows app does, but that's what I'm up against for converting to the web, and it's not a simple task, so if your component offers a shortcut, I'll gladly take it.

To sum up: My goal with the scheduler is not to cover every imaginable business scenario since each business has very different business logic. My goal is to provide an extensible tool where you can easily customize the scheduler to your needs.

I can answer the scaling part right away, if you throw 100 resources in the scheduler it won't be nice (haven't tried it, just a qualified guess :) ). It will support paging though, so if that is acceptable then you're good. Putting a 100 records in a standard grid without paging is just as bad, same concept in my component...

I'll give you more detailed answer when my brain starts working again. Been a long night :)

I was not intending to imply that I expect all of that as standard behavior. I guess what I need to know is exactly how extensible this component would be, because that's going to be the deciding factor in whether to use it as a base platform or not.

Regardless, it looks like an impressive component.

Rest up! :)

This is just what ive been looking for Mats..and you know it :) .. Considering ive actually seen some of the code behind this project (Ext JS Meetup Sweden) , i can guarantee this is some serious piece of component (also coding wise). Kudos for the demo you gave us. Impressive.

This looks great!

Got some sleep now hehe!

Quote:

---

Originally Posted by joeri

- You don't seem to have used a grid as your basis. What sort of support is there for extra columns (with sorting), and letting the user quickly enable/disable grouping in different data elements?

---

It's based on a gridpanel, so you'll be able to use all standard grid behaviour.

Quote:

---

- We would need to support both confirmed reservations (may not overlap) as tentative reservations (may overlap). Is it difficult to integrate support for these two kinds of objects in the same scheduler? Eventually we also want to use the component as a basis for our tasks/appointments planner port from windows to web, where both types may overlap with the other type, but not with themselves, and where they need to have different heights (one hiding below the other) so you can interact with them both.

---

This won't be a problem, you can plug any validating logic into the scheduler.

Quote:

---

- What sort of support is there for integrating business rules of where calendar items can be moved? For example, we have per-resource non-available time, which can differ from day-to-day. This would need to be marked invalid in the calendar and behave that way when you try to drop an item on it. We also have preparation and cleanup time around reservations, which prevents an item from neatly matching up to the next reservation. And then there are things like minimal time ahead, which prevents you from booking a resource too close to the time of the booking (so service providers have time to set up the reservation's requirements, such as food and cleaning services).

---

Same answer here, you can easily plug any validating logic into the scheduler. Non-availability time could be solved by either you supplying this data as regular events and just style them differently. This could be either done on the server if it's complex or you could inject your nonavailibility hours on the client too.

Quote:

---

- Could you go into a little bit more detail of how the data backing for this component is done? I am curious how well it scales and copes with on-demand loading scenarios of large data sets (say, a 100 resources, each in week view). Can data be cached client-side? Is it possible to reuse the same data store for more than one scheduler?

---

I'm currently working on a more indepth webcast which explains the whole setup with data loading etc. Reusing data in other schedulers should be fine.

Quote:

---

- We have resource bundling. A room might already contain some equipment, and might be made up of partitions which can be reserved separately. When this is then booked, this must be indicated as a group in the calendar, and when moving those items this also has to occur as a group. Is something like this feasible to integrate?

---

Could you post a screen shot of how you would like it to look? Sounds a little tricky but still doable.

Hope my answers are of use to you. If not I'll gladly answer any further questions! :)

This is sounding better and better. :)

Thinking about it, I suppose the resource bundling won't be an issue to implement. Acceptable behavior for us would be that if you select one resource, the related resources are also selected, and when you then move those resources, they are moved as a group (only horizontally ofcourse). That's the behavior we currently have in our windows scheduler component, and people find that acceptable. We're also going to need cut/paste logic to move groups of selected resources to different weeks/months, but again I think that will be easy to implement.

I'm still in the prototyping phase, I expect to be moving to full spec writing during november, so the timing matches up. I guess final decisions will be made when I see the code and the pricing model you propose.

I must say, this is really exciting and disappointing at the same time. Exciting because it means I can build something much nicer in far less time, and disappointing because this seemed like a fun challenge to set my teeth into. :)

Kudos mate! That is freakin awesome!