Right, but how can I do this in a more generalized way in 1.7.2?

- Ben

On Nov 21, 11:01 am, Scott González <[email protected]> wrote:
> All you need is an event to cancel. You can already do this by
> preventing the default action in tabs' select event. So we need to
> bring accordion and tabs in line with each other. Feel free to create
> a ticket for this.
>
> On Nov 21, 12:18 am, "\"Cowboy\" Ben Alman" <[email protected]>
> wrote:
>
>
>
> > So, I'm looking for a generalized method of decoupling event and
> > action in the current 1.7.2 jQuery UI Tabs and Accordion widgets.
>
> > What do I mean by "decoupling event and action" ?
>
> > First, let me say that I may have the terminology wrong. Please
> > correct me if there is a better way to describe what I'm trying to do!
>
> > Anyways.. by default, when you click a tab or accordion header, the
> > content is immediately changed to the new content. The event is the
> > "click" and the action is the "showing content". They are tied
> > together very tightly, meaning that separating them is not completely
> > intuitive (but It is possible, and I'll illustrate this below).
>
> > So, what happens when we want to use some kind of hash history plugin
> > to "keep track" of widget state changes? Well, you need to decouple
> > these two things.
>
> > Instead of Event -> Action, you'd want something like:
> > Event -> set the location.hash (window.onhashchange fires) get the
> > location.hash -> Action
>
> > And because a change in the location.hash is what causes the "action",
> > browser history can be used to effectively navigate back + forward to
> > change the state of the widget in question.
>
> > So, I've written a highly generalized window.onhashchange plugin
> > called jQuery BBQ that functions as the "mustard" in this "decoupled
> > event + action" sandwich, and my jQuery UI Tabs example works great..
> > but now that I've tried to apply the same approach to jQuery UI
> > Accordion, I've run into some snags.
>
> > Just like with tabs, it looks like I can do what I need to do with
> > accordion, but it's not particularly pretty. The code I need to use to
> > decouple event and action in accordion is quite different than the
> > tabs code, and it seems like they should be very similar.. or even the
> > same.
>
> > Take a look at this 
> > example:http://benalman.com/code/projects/jquery-bbq/examples/fragment-jquery...
>
> > Because I couldn't find any built-in "do this instead of changing the
> > content" method for clicking tabs, I needed to bind a jQuery click
> > event to override the default behavior of some widget-specific
> > internals ( ul.ui-tabs-nav a ) which feels awkward and hackish.
>
> > And since accordion also seems to lack a built-in "do this instead of
> > changing the content" method, and since the underlying code structure
> > is different, I'd need a whole different set of code to handle that.
> > The click handler would probably be similar.. but the jQuery selector
> > to find the  clickable elements and compute their index would be
> > different enough to be problematic.
>
> > Also, even though the .tabs( 'select', idx ); and .accordion
> > ( 'activate', idx ) methods work perfectly for the "action" part,
> > because they are named inconsistently, it is hard to write generalized
> > code to handle changing state across both widgets.
>
> > So let's say I want a generic handler for jQuery UI Tabs and Accordion
> > widgets (and maybe others), to convert a state object into actual
> > selected states for those widgets.
>
> > The example page I'm thinking of contains #my_accordion and #my_tabs
> > elements. The names would, in practice, be quite different, but for
> > the example's sake I'll keep it simple.
>
> > Ok, so given that, let's say that I have an object that represents the
> > selected state of all current page jQuery UI widgets: { my_accordion:
> > 1, my_tabs: 2 } which means "the selected index of #my_accordion is 1
> > and #my_tabs is 2. Now, let's say we somehow manage to reset the state
> > of the widgets (via page reload or the like) but then want to apply
> > the states in our state object to all relevant widgets.
>
> > Can anyone think of an elegant, simple way to write some generalized
> > code that allows the state of both widgets on the page to be set with
> > just that data object? How about an elegant, simple way to specify "do
> > this instead of changing the content" for both widgets? Note that you
> > can't rely on the word "accordion" or "tabs" in the name of the key,
> > and it's impractical to test "if this_key or that_key then accordion
> > else tabs" because it's just not generalized... so, ideas?
>
> > I think we need two things:
> > 1) A generalized "do this instead of changing the content" handler
> > that can figure out the proper index-to-clickable-element matrix, that
> > can be bound to the correct elements.
> > 2) A generalized "set the selected index of widget #foo to N" handler
> > that can figure out which type of widget is being referenced, so it
> > knows what method to call to set the index.
>
> > My purpose for this very long, complex question is simple:
> > I want to create a simple example that anyone can learn from, and I
> > want to show how event and action can be decoupled in jQuery UI
> > widgets, allowing anyone who understands the concept to use any
> > "history enabling" or "state changing" plugin or controller to manage
> > one or more jQuery UI Tabs / Accordion / ??? widgets in a page.
>
> > Thanks for any suggestions you might have, guys!
>
> > - Ben

--

You received this message because you are subscribed to the Google Groups 
"jQuery UI" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/jquery-ui?hl=.


Reply via email to