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

viewRender/beforeViewRender trigger #15

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@rubenv

rubenv commented Jan 12, 2011

Hi, in a project I'm currently working on, we need to know when the calendar is going to be rendered. To do this, I needed to add this trigger. Would it be possible to have this merged upstream?

In case you're wondering, I need this for the following:
http://yokohama.savanne.be/tmp/.github/redlines.png

It adds a new background table to the calendar, which shows lines that indicate whether or not the slot is free / busy.

These lines need to be cleared upon switching to a new week, which is why I need the trigger.

Add a beforeRender trigger to renderView.
This makes it possible to know when the view rendering is in progress.
@arshaw

This comment has been minimized.

Show comment
Hide comment
@arshaw

arshaw Feb 28, 2013

Member

Would the existing viewDisplay trigger be enough for you? It fires after the view has already been rendered (doesn't wait for events though), so it's not exactly what you want, but it'd probably look the same from the user's perspective. The clearing of the background you described doesn't seem like it would mind if the new cells represent different dates, since it would all happen instantly.

Is viewDisplay good enough?

Member

arshaw commented Feb 28, 2013

Would the existing viewDisplay trigger be enough for you? It fires after the view has already been rendered (doesn't wait for events though), so it's not exactly what you want, but it'd probably look the same from the user's perspective. The clearing of the background you described doesn't seem like it would mind if the new cells represent different dates, since it would all happen instantly.

Is viewDisplay good enough?

jbreton added a commit to jbreton/fullcalendar that referenced this pull request Mar 4, 2013

@jbreton

This comment has been minimized.

Show comment
Hide comment
@jbreton

jbreton Mar 4, 2013

I stumbled on a situation where I need to be able to cancel the rendering. Since some options can't be change dynamicaly (i.e. weekends), it was the only way I found to have the current calendar state before it rendered. It allows me be able to destroy it and rebuild the calendar with different options.

jbreton commented Mar 4, 2013

I stumbled on a situation where I need to be able to cancel the rendering. Since some options can't be change dynamicaly (i.e. weekends), it was the only way I found to have the current calendar state before it rendered. It allows me be able to destroy it and rebuild the calendar with different options.

@arshaw

This comment has been minimized.

Show comment
Hide comment
@arshaw

arshaw Jul 27, 2013

Member

Ok, understood. Thinking out loud: Seems like we should have a new viewRender trigger, which gets called AFTER a view has been freshly rendered. This is similar to viewDisplay, except that viewDisplay gets called even when no rerender is needed. For example, when a user switches away from and then back to a view that has already been rendered. viewRender will only get called when the HTML skeleton of the view needs to be rebuilt.

Then, we should have another option called beforeViewRender, which is what you want @rubenv. Gets called before any view needs to be rerendered. Returning false should cancel the render.

No need for further code changes. I'll worry about this

Member

arshaw commented Jul 27, 2013

Ok, understood. Thinking out loud: Seems like we should have a new viewRender trigger, which gets called AFTER a view has been freshly rendered. This is similar to viewDisplay, except that viewDisplay gets called even when no rerender is needed. For example, when a user switches away from and then back to a view that has already been rendered. viewRender will only get called when the HTML skeleton of the view needs to be rebuilt.

Then, we should have another option called beforeViewRender, which is what you want @rubenv. Gets called before any view needs to be rerendered. Returning false should cancel the render.

No need for further code changes. I'll worry about this

@arshaw arshaw referenced this pull request Jul 27, 2013

Closed

beforeViewDisplay trigger #111

@arshaw

This comment has been minimized.

Show comment
Hide comment
@arshaw

arshaw Jul 27, 2013

Member

I'm changing my mind about returning false to cancel rendering. I am specing out a new option called beforeViewDisplay, in PR #111 , and probably in there you could return false and cancel the view switch.

Seems like canceling the display of the view should happen before the "rendering" phase is entered.

Regardless, you should be able to achieve what you want with these new options.

Member

arshaw commented Jul 27, 2013

I'm changing my mind about returning false to cancel rendering. I am specing out a new option called beforeViewDisplay, in PR #111 , and probably in there you could return false and cancel the view switch.

Seems like canceling the display of the view should happen before the "rendering" phase is entered.

Regardless, you should be able to achieve what you want with these new options.

@rubenv

This comment has been minimized.

Show comment
Hide comment
@rubenv

rubenv Jul 29, 2013

@arshaw cool, thanks!

rubenv commented Jul 29, 2013

@arshaw cool, thanks!

@arshaw arshaw referenced this pull request Aug 1, 2013

Closed

callback before render #112

@arshaw

This comment has been minimized.

Show comment
Hide comment
@arshaw

arshaw Aug 7, 2013

Member

i came up with the viewRender and viewDestroy callbacks in the upcoming release branch. to be documented.

Member

arshaw commented Aug 7, 2013

i came up with the viewRender and viewDestroy callbacks in the upcoming release branch. to be documented.

@arshaw arshaw closed this Aug 7, 2013

@arshaw

This comment has been minimized.

Show comment
Hide comment
@arshaw

arshaw Aug 11, 2013

Member

just released in v1.6.3

Member

arshaw commented Aug 11, 2013

just released in v1.6.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment