Re: [Freeipa-devel] BA-BBQ
On 2010-08-23 16:41, Adam Young wrote:
On 08/23/2010 07:51 AM, Pavel Zuna wrote:
On 08/23/2010 04:12 AM, Adam Young wrote:
Pavel,
Thoughts of jquery.ba-bbq have been marinating in the back of my brain.
I know that the Back button doesn't work so well with hjashparams, and
that BBQ purports to fix this, but I had some sort of mental shift I had
to make. I think I have it now.
BBQ, and in fact the whole AJAX approach works off of client side code,
which means the whole hash params approach. What I didn't get was that
the best approach to dealing with this was to drive the site off of the
event that happens when the url hash changes. We need to do this.
Bascially, navigation.js registers:
$(window).bind( 'hashchange', function(e) {
...
}
This function gets called each time the URL hash changes, which happens
on either a tab click or on a back button (lets start with those two,
there will be more)
So bascially, this function is our dispatach. Instead of having to
register the onclick functions for each of the tabs, we know that they
will all end up in this function, and then we let it parse the params
for us.
BBQ has the concept of a stack, where we can push and pop state. Thyis
might be useful for pushing a query, going to the details page, and then
popping the query afterwards. I'm still mulling this over.
Note, we will want to replace the custom hash param working we are doing
with JQuery.deparam and JQuery.param calls, as they are much more
mature, and it is less code we have to debug.
Sure, from what I've read in jQuery docs, it looks more powerful than
what we currently have.
The thing I have to figure out now is what this will do to navigation on
the details, add and groups pages.
I don't think it will be a problem. Functional links (such as Reset,
Update, Add, Remove) are only used to run javascript functions - the
URL, query string or hash doesn't change. Most of these action are
also "one way" only. We don't want the user to be able to go Back
after he updated an entry. (Going back in this case should probably
bring him back to the search page).
Pavel
I notice he uses JQuery.ui Tabs for his demo. I wonder if we want to
move to that as well?
http://benalman.com/code/projects/jquery-bbq/examples/fragment-jquery-ui-tabs/
You mean this example, right? It looks good and if it can simplify our
code, why not. I'll take a look at the API a maybe play around with it a
little.
Pavel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] BA-BBQ
On 08/23/2010 07:51 AM, Pavel Zuna wrote:
On 08/23/2010 04:12 AM, Adam Young wrote:
Pavel,
Thoughts of jquery.ba-bbq have been marinating in the back of my brain.
I know that the Back button doesn't work so well with hjashparams, and
that BBQ purports to fix this, but I had some sort of mental shift I had
to make. I think I have it now.
BBQ, and in fact the whole AJAX approach works off of client side code,
which means the whole hash params approach. What I didn't get was that
the best approach to dealing with this was to drive the site off of the
event that happens when the url hash changes. We need to do this.
Bascially, navigation.js registers:
$(window).bind( 'hashchange', function(e) {
...
}
This function gets called each time the URL hash changes, which happens
on either a tab click or on a back button (lets start with those two,
there will be more)
So bascially, this function is our dispatach. Instead of having to
register the onclick functions for each of the tabs, we know that they
will all end up in this function, and then we let it parse the params
for us.
BBQ has the concept of a stack, where we can push and pop state. Thyis
might be useful for pushing a query, going to the details page, and then
popping the query afterwards. I'm still mulling this over.
Note, we will want to replace the custom hash param working we are doing
with JQuery.deparam and JQuery.param calls, as they are much more
mature, and it is less code we have to debug.
Sure, from what I've read in jQuery docs, it looks more powerful than
what we currently have.
The thing I have to figure out now is what this will do to navigation on
the details, add and groups pages.
I don't think it will be a problem. Functional links (such as Reset,
Update, Add, Remove) are only used to run javascript functions - the
URL, query string or hash doesn't change. Most of these action are
also "one way" only. We don't want the user to be able to go Back
after he updated an entry. (Going back in this case should probably
bring him back to the search page).
Pavel
I notice he uses JQuery.ui Tabs for his demo. I wonder if we want to
move to that as well?
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] BA-BBQ
On 08/23/2010 04:12 AM, Adam Young wrote:
Pavel,
Thoughts of jquery.ba-bbq have been marinating in the back of my brain.
I know that the Back button doesn't work so well with hjashparams, and
that BBQ purports to fix this, but I had some sort of mental shift I had
to make. I think I have it now.
BBQ, and in fact the whole AJAX approach works off of client side code,
which means the whole hash params approach. What I didn't get was that
the best approach to dealing with this was to drive the site off of the
event that happens when the url hash changes. We need to do this.
Bascially, navigation.js registers:
$(window).bind( 'hashchange', function(e) {
...
}
This function gets called each time the URL hash changes, which happens
on either a tab click or on a back button (lets start with those two,
there will be more)
So bascially, this function is our dispatach. Instead of having to
register the onclick functions for each of the tabs, we know that they
will all end up in this function, and then we let it parse the params
for us.
BBQ has the concept of a stack, where we can push and pop state. Thyis
might be useful for pushing a query, going to the details page, and then
popping the query afterwards. I'm still mulling this over.
Note, we will want to replace the custom hash param working we are doing
with JQuery.deparam and JQuery.param calls, as they are much more
mature, and it is less code we have to debug.
Sure, from what I've read in jQuery docs, it looks more powerful than what we
currently have.
The thing I have to figure out now is what this will do to navigation on
the details, add and groups pages.
I don't think it will be a problem. Functional links (such as Reset, Update,
Add, Remove) are only used to run javascript functions - the URL, query string
or hash doesn't change. Most of these action are also "one way" only. We don't
want the user to be able to go Back after he updated an entry. (Going back in
this case should probably bring him back to the search page).
Pavel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
