I haven''t poured much thought into this, it may even be completely trivial. Some forms get too big to fit on a single page without scrolling. A common way to organize them is with tabs that only show related items at a time. An additional benefit could be avoiding to load everything up front, but rather only when the user really wants to view/edit the data. My idea is to attack this issue as generically as possible. I envision something like this: Each tab page corresponds to a partial. In the new and edit views there''s a declaration listing the tabs with title and corresponding partial. Options specify for each tab page whether it is loaded immediately or only on demand through an ajax request. Has anyone done this already and can provide advice or warn of particular problems? Are there demo pages out there demonstrating such a technique? Michael -- Michael Schuerig This is not a false alarm mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org This is not a test http://www.schuerig.de/michael/ --Rush, Red Tide
Disclaimer: I haven''t really thought through this. Just my $0.02. I''ve thought of things like this before. A majority of my apps use multi-step wizards that would probably fit nicely into a tabbed form structure like you describe, especially if there were a Rails-style DRY framework for it. I''m wondering how this would work with forms that have a lot of data dependencies. The kind of forms where each page depends on a lot of information preceding it. For example, in one of my applications I''m working on right now, I have about 20 actions over ~5 controllers that could be considered part of a multi-step process. I don''t have much Aspect-Oriented Programming experience (or respect for the buzzwords), but what would be awesome is a way to separate the "tabbed page" concern from the actual presentation. Something similar to what layouts and partials do for Action View separation of concerns. Like some part of Action View or Action Controller where I could specify "tabbed_page [:welcome, :qualify, :gather_info, :display]". In short, a key factor for acceptance would be the ability to drop this into existing code without moving all of the views into partials. Does anyone have ideas on how to accomplish this? Once these projects let up, I really need to dig into the Rails code and learn a thing or two. Thanks to DHH and all for such an intuitive framework! -- Brad Ediger 866-EDIGERS On Sep 18, 2005, at 3:20 PM, Michael Schuerig wrote:> > I haven''t poured much thought into this, it may even be completely > trivial. Some forms get too big to fit on a single page without > scrolling. A common way to organize them is with tabs that only show > related items at a time. An additional benefit could be avoiding to > load everything up front, but rather only when the user really > wants to > view/edit the data. > > My idea is to attack this issue as generically as possible. I envision > something like this: Each tab page corresponds to a partial. In the > new > and edit views there''s a declaration listing the tabs with title and > corresponding partial. Options specify for each tab page whether it is > loaded immediately or only on demand through an ajax request. > > Has anyone done this already and can provide advice or warn of > particular problems? Are there demo pages out there demonstrating such > a technique? > > Michael >
> I haven''t poured much thought into this, it may even be completely > trivial. Some forms get too big to fit on a single page without > scrolling. A common way to organize them is with tabs that only show > related items at a time. An additional benefit could be avoiding to > load everything up front, but rather only when the user really wants to > view/edit the data. > > My idea is to attack this issue as generically as possible. I envision > something like this: Each tab page corresponds to a partial. In the new > and edit views there''s a declaration listing the tabs with title and > corresponding partial. Options specify for each tab page whether it is > loaded immediately or only on demand through an ajax request. > > Has anyone done this already and can provide advice or warn of > particular problems? Are there demo pages out there demonstrating such > a technique?While this approach has some merit, it seems to me like it''s entirely client side and that Rails could and should to little to aid it. It''s just a simple matter of toggling display:block/none on the tab links. Regards, Tomas Jogin
On Sep 18, 2005, at 5:51 PM, Tomas Jogin wrote:>> I haven''t poured much thought into this, it may even be completely >> trivial. Some forms get too big to fit on a single page without >> scrolling. A common way to organize them is with tabs that only show >> related items at a time. An additional benefit could be avoiding to >> load everything up front, but rather only when the user really >> wants to >> view/edit the data. >> >> My idea is to attack this issue as generically as possible. I >> envision >> something like this: Each tab page corresponds to a partial. In >> the new >> and edit views there''s a declaration listing the tabs with title and >> corresponding partial. Options specify for each tab page whether >> it is >> loaded immediately or only on demand through an ajax request. >> >> Has anyone done this already and can provide advice or warn of >> particular problems? Are there demo pages out there demonstrating >> such >> a technique? >> > > While this approach has some merit, it seems to me like it''s entirely > client side and that Rails could and should to little to aid it. It''s > just a simple matter of toggling display:block/none on the tab links. > > Regards, > Tomas Jogin >I envisioned something more involved. As a starting point, it would be useful to have the tab pages pulled dynamically from the server. First, it helps in the case of many large pages, some of which are not needed all of the time (consider an application for auto insurance.) Secondly, and most importantly IMHO, it is the only way to deal with data-dependent form pages. It would be simple to implement some JS to toggle styles on the tabs, but I think the ultimate solution should have facilities for AJAX integration. be
On 19/09/2005, at 9:00 AM, Brad Ediger wrote:>> While this approach has some merit, it seems to me like it''s entirely >> client side and that Rails could and should to little to aid it. It''s >> just a simple matter of toggling display:block/none on the tab links. > > I envisioned something more involved. As a starting point, it would > be useful to have the tab pages pulled dynamically from the server. > First, it helps in the case of many large pages, some of which are > not needed all of the time (consider an application for auto > insurance.) Secondly, and most importantly IMHO, it is the only way > to deal with data-dependent form pages. > > It would be simple to implement some JS to toggle styles on the > tabs, but I think the ultimate solution should have facilities for > AJAX integration.I''ve been working on the JS version (display things toggled by JS tabs) for use in a couple of upcoming projects, and it works great. I can''t help thinking that an AJAX-powered solution that only grabs the tab''s content as needed is trying to solve a problem that doesn''t exist. Browsers are fast. Everyone has fast(er) connections. For me, I would see a multi-part form as something slowing me down, rather than improving a web experience -- I''d rather see it load in one hit (how big can it be? 100k? 200k?) rather than be interrupted on each tab as Ajax loads stuff. And really, what''s the difference between a multi-page form (where the whole page loads for each part of the form) and what you describe (where part of the page is reloaded for each part of the form)? Not much. I agree that you still need a solution which works for data-dependent form pages, but I doubt this could be elegantly abstracted into Rails helpers, but I could be wrong ;) --- Justin French, Indent.com.au justin.french-zULN+VWqVOIpAS55Wn97og@public.gmane.org Web Application Development & Graphic Design
On Sep 18, 2005, at 9:19 PM, Justin French wrote:> > I''ve been working on the JS version (display things toggled by JS > tabs) for use in a couple of upcoming projects, and it works great. > > I can''t help thinking that an AJAX-powered solution that only grabs > the tab''s content as needed is trying to solve a problem that > doesn''t exist. Browsers are fast. Everyone has fast(er) > connections. For me, I would see a multi-part form as something > slowing me down, rather than improving a web experience -- I''d > rather see it load in one hit (how big can it be? 100k? 200k?) > rather than be interrupted on each tab as Ajax loads stuff. > > And really, what''s the difference between a multi-page form (where > the whole page loads for each part of the form) and what you > describe (where part of the page is reloaded for each part of the > form)? Not much. > > I agree that you still need a solution which works for data- > dependent form pages, but I doubt this could be elegantly > abstracted into Rails helpers, but I could be wrong ;) >Agreed -- when I mentioned AJAX, I only introduced it to solve the data-dependency problem. I do think breaking up a 100K page into 5 20K pages with a server roundtrip is a bit unnecessary if the content is static. :-) be
On 9/18/05, Justin French <justin.french-zULN+VWqVOIpAS55Wn97og@public.gmane.org> wrote:> On 19/09/2005, at 9:00 AM, Brad Ediger wrote: > > >> While this approach has some merit, it seems to me like it''s entirely > >> client side and that Rails could and should to little to aid it. It''s > >> just a simple matter of toggling display:block/none on the tab links. > > > > I envisioned something more involved. As a starting point, it would > > be useful to have the tab pages pulled dynamically from the server. > > First, it helps in the case of many large pages, some of which are > > not needed all of the time (consider an application for auto > > insurance.) Secondly, and most importantly IMHO, it is the only way > > to deal with data-dependent form pages. > > > > It would be simple to implement some JS to toggle styles on the > > tabs, but I think the ultimate solution should have facilities for > > AJAX integration. > > I''ve been working on the JS version (display things toggled by JS > tabs) for use in a couple of upcoming projects, and it works great. > > I can''t help thinking that an AJAX-powered solution that only grabs > the tab''s content as needed is trying to solve a problem that doesn''t > exist. Browsers are fast. Everyone has fast(er) connections. For > me, I would see a multi-part form as something slowing me down, > rather than improving a web experience -- I''d rather see it load in > one hit (how big can it be? 100k? 200k?) rather than be interrupted > on each tab as Ajax loads stuff.Just keep in mind that it takes a dialup user 2 minutes to download 200KB worth of stuff.> And really, what''s the difference between a multi-page form (where > the whole page loads for each part of the form) and what you describe > (where part of the page is reloaded for each part of the form)? Not > much. > > I agree that you still need a solution which works for data-dependent > form pages, but I doubt this could be elegantly abstracted into Rails > helpers, but I could be wrong ;)
We use a similar design for one of our products at work, and the biggest problem we see is not download time, but client-side render. We''ve seen 200-500k javascript-heavy pages take waaay too long to render, so our solution was to download-as-needed each individual tab. Just something to think about. -- Mando On 9/18/05, Joe Van Dyk <joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > On 9/18/05, Justin French <justin.french-zULN+VWqVOIpAS55Wn97og@public.gmane.org> wrote: > > On 19/09/2005, at 9:00 AM, Brad Ediger wrote: > > > > >> While this approach has some merit, it seems to me like it''s entirely > > >> client side and that Rails could and should to little to aid it. It''s > > >> just a simple matter of toggling display:block/none on the tab links. > > > > > > I envisioned something more involved. As a starting point, it would > > > be useful to have the tab pages pulled dynamically from the server. > > > First, it helps in the case of many large pages, some of which are > > > not needed all of the time (consider an application for auto > > > insurance.) Secondly, and most importantly IMHO, it is the only way > > > to deal with data-dependent form pages. > > > > > > It would be simple to implement some JS to toggle styles on the > > > tabs, but I think the ultimate solution should have facilities for > > > AJAX integration. > > > > I''ve been working on the JS version (display things toggled by JS > > tabs) for use in a couple of upcoming projects, and it works great. > > > > I can''t help thinking that an AJAX-powered solution that only grabs > > the tab''s content as needed is trying to solve a problem that doesn''t > > exist. Browsers are fast. Everyone has fast(er) connections. For > > me, I would see a multi-part form as something slowing me down, > > rather than improving a web experience -- I''d rather see it load in > > one hit (how big can it be? 100k? 200k?) rather than be interrupted > > on each tab as Ajax loads stuff. > > Just keep in mind that it takes a dialup user 2 minutes to download > 200KB worth of stuff. > > > > And really, what''s the difference between a multi-page form (where > > the whole page loads for each part of the form) and what you describe > > (where part of the page is reloaded for each part of the form)? Not > > much. > > > > I agree that you still need a solution which works for data-dependent > > form pages, but I doubt this could be elegantly abstracted into Rails > > helpers, but I could be wrong ;) > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails