RE: Development/Redesign tabs
Keiron Liddle wrote: With regard to the faq, I just last night sliced out nearly all of the contents of the dev/faq.xml file. As far as I could tell, it was a duplicate of an old version of the faq.xml. Those changes are not reflected on the site yet (I have emailed Jeff to try to find out why not). It wasn't quite a duplication of the old version. So where should the new/updated information be put? It should be put somewhere so the information can be updated as we a\go and not be lost while still have the old version available. OK, I'll go back do a more thorough review of what was in there put any useful content back in place. I don't care a lot about whether we have 1 or 2 developer tabs -- I just want to clarify what they are, not only so that I know what to put where, but also so that the web site users understand what they are seeing. It is confusing enough to have two branches of development, but to have our documentation mixed up or unclear is a serious problem. A case could be made that we don't want a developer tab for the maintenance branch, because we don't really want anyone developing for it. I kind of thought that was what was going on when I saw the index for it with the title FOP 1.0 development. I propose the following for a 3-tab structure (I am not ignoring the Alt Design tab, it just isn't affected by this): Home Release Development 1.0 Development If you prefer to combine the developer doc, then: Home Development I'm inferring from your comments that you prefer the 3 tabs described above, so I'll just go ahead implement them, and work on changing the content to match that scheme. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Development/Redesign tabs
Victor Mote wrote: I'm inferring from your comments that you prefer the 3 tabs described above, so I'll just go ahead implement them, and work on changing the content to match that scheme. After thinking through this further, I am convinced that there will be no practical way to maintain one tab for each of the development lines. There is a lot of overlap, and I don't think anyone wants to maintain two sets of documents. For documents that are clearly for the redesign only, we can mark them so in various ways to avoid confusion. We have a similar problem for users when we do a release from the trunk. If we combine the 2 development tabs into one, I think that eliminates the Forrest problem that was discussed recently, where clicking an item in tab 1 can jump you to tab 2. Any comments? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Development/Redesign tabs
I made some decent progress today on getting my head into the trunk code, and to document some of what I have learned. I am still confused by the Development and Redesign tabs. At first, I thought that maybe Development was for those who might be developing on the maintenance branch, and Redesign for those on the trunk, but the title to the index document under Development seems to belie that. I see that we have some problems with the left nav bar that result from our directory structure. For example, first click http://xml.apache.org/fop/design/index.html, then click on the tab entitled Understanding, and watch the left nav bar change, which you would think it should not. Perhaps we made the two tabs to ease that problem? Assuming that I can find the Forrest solution to that problem, is there any objection to merging these two tabs into one entitled Development? Hi Victor, The original idea of the development was for user documentation for the current development. So it can be updated as the API and other such details are changed. For example with the faq, it had some different information on things such as text in SVG. Maybe it would be better to only have the new information there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Development/Redesign tabs
Keiron Liddle wrote: The original idea of the development was for user documentation for the current development. So it can be updated as the API and other such details are changed. If user documentation means developer documentation, and current development means maintenance branch development, then I think I understand. That would make the redesign tab be for the new development. If that is what we want, then I'll go to work on making that more clear. For example with the faq, it had some different information on things such as text in SVG. Maybe it would be better to only have the new information there. With regard to the faq, I just last night sliced out nearly all of the contents of the dev/faq.xml file. As far as I could tell, it was a duplicate of an old version of the faq.xml. Those changes are not reflected on the site yet (I have emailed Jeff to try to find out why not). I don't care a lot about whether we have 1 or 2 developer tabs -- I just want to clarify what they are, not only so that I know what to put where, but also so that the web site users understand what they are seeing. It is confusing enough to have two branches of development, but to have our documentation mixed up or unclear is a serious problem. A case could be made that we don't want a developer tab for the maintenance branch, because we don't really want anyone developing for it. I kind of thought that was what was going on when I saw the index for it with the title FOP 1.0 development. I propose the following for a 3-tab structure (I am not ignoring the Alt Design tab, it just isn't affected by this): Home Release Development 1.0 Development If you prefer to combine the developer doc, then: Home Development Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Development/Redesign tabs
With regard to the faq, I just last night sliced out nearly all of the contents of the dev/faq.xml file. As far as I could tell, it was a duplicate of an old version of the faq.xml. Those changes are not reflected on the site yet (I have emailed Jeff to try to find out why not). It wasn't quite a duplication of the old version. So where should the new/updated information be put? It should be put somewhere so the information can be updated as we a\go and not be lost while still have the old version available. I don't care a lot about whether we have 1 or 2 developer tabs -- I just want to clarify what they are, not only so that I know what to put where, but also so that the web site users understand what they are seeing. It is confusing enough to have two branches of development, but to have our documentation mixed up or unclear is a serious problem. A case could be made that we don't want a developer tab for the maintenance branch, because we don't really want anyone developing for it. I kind of thought that was what was going on when I saw the index for it with the title FOP 1.0 development. I propose the following for a 3-tab structure (I am not ignoring the Alt Design tab, it just isn't affected by this): Home Release Development 1.0 Development If you prefer to combine the developer doc, then: Home Development Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Development/Redesign tabs
On Mon, Mar 24, 2003 at 03:36:30PM -0700, Victor Mote wrote: I made some decent progress today on getting my head into the trunk code, and to document some of what I have learned. I am still confused by the Development and Redesign tabs. At first, I thought that maybe Development was for those who might be developing on the maintenance branch, and Redesign for those on the trunk, but the title to the index document under Development seems to belie that. I see that we have some problems with the left nav bar that result from our directory structure. For example, first click http://xml.apache.org/fop/design/index.html, then click on the tab entitled Understanding, and watch the left nav bar change, which you would think it should not. Perhaps we made the two tabs to ease that problem? Is 'understanding' a subsection of 'design', as the directory structure suggests? The menu changes because there are two different book.xml files (which generate the menus): src/documentation/content/xdocs/design/book.xml src/documentation/content/xdocs/design/understanding/book.xml As for tabs, they are completely reactive things. The tab with the longest matching @dir is on. So FOP's tabs.xml has: tab label=Home dir=/ tab label=Development dir=dev// tab label=Redesign dir=design// tab label=alt design dir=design/alt.design// When viewing design/* or design/understanding/*, the longest matching tab is Redesign. HTH, --Jeff Assuming that I can find the Forrest solution to that problem, is there any objection to merging these two tabs into one entitled Development? Victor Mote (mailto:[EMAIL PROTECTED]) 2025 Eddington Way Colorado Springs, Colorado 80916 Voice +1 (719) 622-0650 Fax +1 (720) 293-0044 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Development/Redesign tabs
Jeff Turner wrote: On Mon, Mar 24, 2003 at 03:36:30PM -0700, Victor Mote wrote: I made some decent progress today on getting my head into the trunk code, and to document some of what I have learned. I am still confused by the Development and Redesign tabs. At first, I thought that maybe Development was for those who might be developing on the maintenance branch, and Redesign for those on the trunk, but the title to the index document under Development seems to belie that. I see that we have some problems with the left nav bar that result from our directory structure. For example, first click http://xml.apache.org/fop/design/index.html, then click on the tab entitled Understanding, and watch the left nav bar change, which you would think it should not. Perhaps we made the two tabs to ease that problem? Is 'understanding' a subsection of 'design', as the directory structure suggests? Yes, but they are probably logically part of the same tab/left nav bar on the web site. The menu changes because there are two different book.xml files (which generate the menus): src/documentation/content/xdocs/design/book.xml src/documentation/content/xdocs/design/understanding/book.xml I understood that, and I assume that the book.xml that is in the same directory as document.xml is the menu that attaches to document.html when it is generated. The question then is, can that be overridden? As for tabs, they are completely reactive things. The tab with the longest matching @dir is on. So FOP's tabs.xml has: tab label=Home dir=/ tab label=Development dir=dev// tab label=Redesign dir=design// tab label=alt design dir=design/alt.design// When viewing design/* or design/understanding/*, the longest matching tab is Redesign. Interesting unexpected. Now I see why I got the counter-intuitive effect that I saw. I don't know how well it fits with the Cocoon processing model (I have a book on order that I hope will connect a few dots about Cocoon for me), but a more clear parent-child hierarchical relationship in the site setup would seem to be more flexible. In my mind, the left nav bar is a subset of the tab that it is under. I might be able to be talked out of that. I guess I would like to see: site tab desc=Tab 1 menu desc=Tab 1, Menu 1 doc desc=Doc 1 path=abc.html/ doc desc=Doc 2 path=xyz/abc.html/ /menu menu desc=Tab 1, Menu 2 doc desc=Doc 3 path=xyz/pdq/abc.html/ /menu /tab tabTab 2/tab /site Each document would get tab nav information from the structure that it is in. The above separates the directory structure from the web site hierarchy. Although this seems good to me, it may rob Cocoon or Forrest of some of their power (I'm not sure yet), and there may be other good reasons not to do it. Anyway, thanks for the info. That does save me a bunch of work. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
