From: Andy S. <an...@ee...> - 2007-02-27 19:27:50
|
I think the best design for such pages is to usually use the same .tpl and include a view / subview specific .tpl in there. Of course this is almost the same approach as including a tabbar.tpl if all the master .tpl does is define a tabbar. I think the "AdminPluginTabBar.tpl", "AdminRewriteTabBar.tpl", .. approach is the right one if there's some reuse. I don't like the tabbar.inc approach too much. - Andy Russell wrote: > The URL Rewrite module SiteAdmin uses a tab bar. It has > essentially /merged/ three separate pages into one view and > controller using a big switch. The RSS feed module does > essentially the same thing with its site admin & feed edit > pages. I feel that it would be better to separate them into > different views and controllers than have an if (mode == a) > else if (mode == b) type switch. I will be doing much the > same thing with my pages if I were to use a tab bar like it > is currently implemented, otherwise I will probably create a > tabbar.tpl file to include on each page. > > - Zimzat > > Andy Staudacher wrote: > > Now I understand, thanks. > > The tabbar.inc approach only makes sense if the reuse factor of a > > specific tabbar is very high. > > Other than AdminPlugin vs AdminRepository, are there other tabbars > > that are > > (nearly) identical (in content)? > > > > - Andy > > > > Russell wrote: > >> The tabbars.inc file would define a list of tab bars in a specific > >> module, associated by unique keys, and tabs in them, also > associated > >> by unique keys. For > >> example: > >> > >> $tabBars = array( > >> 'plugins' => array( > >> 'plugins' => array(caption, url), > >> 'downloadplugins' => array(caption, url)), > >> 'items' => array( > >> 'web' => array(caption, url), > >> 'site' => array(caption, url))); > >> > >> Now, the biggest reason /not/ to do this is because AdminThemes, > >> among several others, gets each tab dynamically based on > what themes > >> are currently installed. > >> So yeah, I just ruled out my own implementation method, > which is fine > >> by me since it isn't very flexible in the first place. > >> > >> If we put the list in the view, I suppose we would need to > extend the > >> view API. > >> But what if we have two or more views that have the exact same tab > >> bar? I'm not happy with the idea of a single view or controller > >> handling more than one or two tabs, because then we're > breaking the > >> MVC pattern by merging multiple views and controllers into one big > >> multi-switch. The only way to keep that from happening, > though, is to > >> put each tab in a different view, extract the common > elements into a > >> helper, and put the tab bar list definition into a common location > >> that can be called by all the tabs. > >> > >> - Zimzat > >> > >> Andy Staudacher wrote: > >>> I still don't see how tabbar.inc comes into play. > >>> > >>> And a small correction: > >>> Yes, I'm for a g->tabBar function. > >>> Whether to define the params in the .tpl or in the view > >> doesn't matter > >>> to me. > >>> > >>> - Andy > >>> > >>> Russell wrote: > >>>> Hello Gallery, > >>>> > >>>> Earlier today I wanted to add a tab bar to a couple of pages and > >>>> looked into how that was implemented. I was somewhat > >> disappointed to > >>>> see that in every instance it is manually created > completely from > >>>> scratch, when it is a very simple if-else statement with > >> caption and > >>>> url pairs. I then got into a discussion with valiant about > >> this and > >>>> we have differing ideas on how to implement a tab bar system. > >>>> > >>>> We both agree on a {g->tabBar} entry vector. What we > >> differ on is the > >>>> actual implementation. > >>>> > >>>> My idea is to do something like the blocks.inc file, except as > >>>> tabbars.inc. This way each page would only have to say > >> "show /this/ > >>>> tab bar, with /this/ tab being current". One problem that > >> occurs with > >>>> this method, though, is places like AdminThemes which gets the > >>>> captions and urls for the tabs based on an array that was > >> passed to > >>>> it. > >>>> > >>>> Valiant's idea is to define the caption and url pairings > >> directly in > >>>> the template and then pass them to the tab bar handler. > This would > >>>> allow places such as AdminThemes to continue functioning exactly > >>>> as-is, however, it would require the implementation of the > >> creation > >>>> of arrays directly in the smarty template system (which is > >> a little > >>>> further than I'm willing to go just for my own two pages of two > >>>> tabs), or a long drawn-out {g->tabbar url1=x1 caption1=x2 url2=y1 > >>>> caption2=y2 current=y2}. > >>>> > >>>> What I'm looking for from this email is to see if anyone has any > >>>> further ideas or suggestions on how to handle this situation. > >>>> > >>>> So, how about it? > >>>> > >>>> - Zimzat |