Re: Users guide
On 2/13/07, Paul Benedict <[EMAIL PROTECTED]> wrote: Yup. Spring uses Docbook. That's what I am going to try: single html page (everything), multiple html pages, and PDF. For DocBook under Windows, I've been having good luck with * TextPad * xlstproc * Apache FOP The trick is to use xmllint frequently to catch any formatting oversights. TextPad has plugins for DocBook syntax. The TextPad cliplibraries work surprisingly well for XML formatting, and give you more control over the source. An issue with the IDEs is that they tend to format everything as one long line, making repository change logs useless. (And repository change logs is one very good reason to use DocBook!) Besides supporting a variety of output formats, another key benefit for geeks is that the code examples can be stored as external files, so you can continue to edit and test them with programming tools, or maybe even suck them in from the distribution, snippet style. DocBook ReadMeFirst * TextPad DocBook - http://www.scottnesbitt.net/techdocs/docbook_textpad.html * CodeProject DocBook - http://www.codeproject.com/winhelp/docbook_howto.asp * DocBook XSL - http://www.sagehill.net/book-description.html * DocBook Guide - http://www.oasis-open.org/docbook/documentation/reference/html/docbook.html DocBook Downloads * DocBook XLS - http://sourceforge.net/projects/docbook/ * DocBook DTD - http://www.oasis-open.org/docbook/xml/ * DTD Character Entities - http://www.oasis-open.org/docbook/xmlcharent/index.shtml * TextPad - http://www.textpad.com/ * SDocBook clip library - http://www.textpad.com/add-ons/cliplibs.html * DocBook syntax - http://www.textpad.com/add-ons/syna2g.html * xsltproc - http://www.zlatkovic.com/pub/libxml/ - libxml, libxslt, zlib, and iconv ** libxml2-2.6.27.win32(includes xmllint) ** libxslt-1.1.17.win32 ** zlib-1.2.3.win32 ** iconv-1.9.2.win32.zip * Apache FOP - http://www.apache.org/dyn/closer.cgi/xmlgraphics/fop ** Java Advanced Imaging (JAI) https://jai.dev.java.net/binary-builds.html#Release_builds ** Objects for Formatting Objects http://sourceforge.net/projects/offo/ If there's ever a week when I'm not rolling a Struts 2 release, I might blog about DocBook under Windows. :) -- HTH, Ted. * http://www.husted.com/struts/ ... or, maybe when wrestling season is over and I get my Saturdays back. My son just won the Sectional wrestling championship hereabouts, which puts him one step away from the NYS tournament. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Users guide
Ok, any chance for a summary with roles on who's going to do what, and in what timeframe ? Although limited in spare time (aren't we all), I'm definitely willing to work on this (and I assume Musachy as well), but I would appreciate directions or a concrete plan. Shoot. Phil On 2/14/07, Ted Husted <[EMAIL PROTECTED]> wrote: On 2/13/07, Paul Benedict <[EMAIL PROTECTED]> wrote: > Yup. Spring uses Docbook. That's what I am going to try: single html > page (everything), multiple html pages, and PDF. For DocBook under Windows, I've been having good luck with * TextPad * xlstproc * Apache FOP The trick is to use xmllint frequently to catch any formatting oversights. TextPad has plugins for DocBook syntax. The TextPad cliplibraries work surprisingly well for XML formatting, and give you more control over the source. An issue with the IDEs is that they tend to format everything as one long line, making repository change logs useless. (And repository change logs is one very good reason to use DocBook!) Besides supporting a variety of output formats, another key benefit for geeks is that the code examples can be stored as external files, so you can continue to edit and test them with programming tools, or maybe even suck them in from the distribution, snippet style. DocBook ReadMeFirst * TextPad DocBook - http://www.scottnesbitt.net/techdocs/docbook_textpad.html * CodeProject DocBook - http://www.codeproject.com/winhelp/docbook_howto.asp * DocBook XSL - http://www.sagehill.net/book-description.html * DocBook Guide - http://www.oasis-open.org/docbook/documentation/reference/html/docbook.html DocBook Downloads * DocBook XLS - http://sourceforge.net/projects/docbook/ * DocBook DTD - http://www.oasis-open.org/docbook/xml/ * DTD Character Entities - http://www.oasis-open.org/docbook/xmlcharent/index.shtml * TextPad - http://www.textpad.com/ * SDocBook clip library - http://www.textpad.com/add-ons/cliplibs.html * DocBook syntax - http://www.textpad.com/add-ons/syna2g.html * xsltproc - http://www.zlatkovic.com/pub/libxml/ - libxml, libxslt, zlib, and iconv ** libxml2-2.6.27.win32(includes xmllint) ** libxslt-1.1.17.win32 ** zlib-1.2.3.win32 ** iconv-1.9.2.win32.zip * Apache FOP - http://www.apache.org/dyn/closer.cgi/xmlgraphics/fop ** Java Advanced Imaging (JAI) https://jai.dev.java.net/binary-builds.html#Release_builds ** Objects for Formatting Objects http://sourceforge.net/projects/offo/ If there's ever a week when I'm not rolling a Struts 2 release, I might blog about DocBook under Windows. :) -- HTH, Ted. * http://www.husted.com/struts/ ... or, maybe when wrestling season is over and I get my Saturdays back. My son just won the Sectional wrestling championship hereabouts, which puts him one step away from the NYS tournament. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- iDTV System Engineer "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." - John F. Woods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Users guide
I don't have the time to work on a significant refactoring this year. The most I can do is help keep what we have patched and up-to-date. As a PMC member, I would be opposed to any project-sanctioned effort that is going to create a set of redundant documents that would be made part of a release. We have to be very sensitive to the limited time our volunteers have available. We're lucky if we have time to update the project documentation in one place, let alone three or four different places. But, if someone wants to start something on the S2 wiki site (S2WIKI), or in the sandbox, to see if there's traction among other volunteers, the rules of revolution would apply. As to other parts of this thread, I'm not convinced that an XML format would be the best thing for Struts 2. There's a lot to be said for people being able to make changes in real time. With Confluence, anyone with a CLA on file can pitch in and help. (And thanks very much to those that already do!) Without a wiki, we're back to patches that have to applied by committers. Of course, there is a DocBook Wiki, but first we'd have to address the infrastructure issues. Since the Struts 1 project documentation is already in XML, that's "a horse of a different color". -Ted. On 2/14/07, Philip Luppens <[EMAIL PROTECTED]> wrote: Ok, any chance for a summary with roles on who's going to do what, and in what timeframe ? Although limited in spare time (aren't we all), I'm definitely willing to work on this (and I assume Musachy as well), but I would appreciate directions or a concrete plan. Shoot. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
So, tonight is last call on 2.0.6. Please try to take a look at the TODO list, if you have a chance. * https://issues.apache.org/struts/secure/IssueNavigator.jspa?mode=hide&requestId=10764 A fix for WW-1711 that didn't break the tests (or updated tests) would be especially welcome! -Ted. On 2/13/07, Ted Husted <[EMAIL PROTECTED]> wrote: I'd like to go ahead and tag the 2.0.6 release on Thursday between 1pm and 3pm PST. If you have a chance to preview the build, please do so, since we've removed the dependencies on the new API. Any of the other simple changes on the Struts 2.0.6 list would be welcome as well, otherwise we can push these over to 2.0.7. -Ted. -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Users guide
I understand we don't want duplicated docs, but at the moment, we have to realize our Developers Guide is a mix of a Users Guide, Developers Guide and Reference Guide. If we take the following 'definitions' into account: - Developers: in-depth architecture, creating and extending Interceptors, Results, Validators, Themes, Templates, Plugins, .. - Users: explain the high level architecture, create Actions, create Views, configuration of the webapp (struts.xml, using annotations, mapping, ..), .. - Reference: contains the explanation and docs for each Validator, Interceptor, Result, Annotation, .. by using the snippet macro. I believe we can rearrange the docs fairly easily based on the list above (I understand it would mean a lot of work - but I'm ok with that and willing to step up for it). The amount of duplicated docs should be reduced to a minimum. Otoh, we could keep the current Developers Guide, and just provide an 'easy' outline or view for users that links to the current Developers Guide. Thoughts ? Phil On 2/14/07, Ted Husted <[EMAIL PROTECTED]> wrote: I don't have the time to work on a significant refactoring this year. The most I can do is help keep what we have patched and up-to-date. As a PMC member, I would be opposed to any project-sanctioned effort that is going to create a set of redundant documents that would be made part of a release. We have to be very sensitive to the limited time our volunteers have available. We're lucky if we have time to update the project documentation in one place, let alone three or four different places. But, if someone wants to start something on the S2 wiki site (S2WIKI), or in the sandbox, to see if there's traction among other volunteers, the rules of revolution would apply. As to other parts of this thread, I'm not convinced that an XML format would be the best thing for Struts 2. There's a lot to be said for people being able to make changes in real time. With Confluence, anyone with a CLA on file can pitch in and help. (And thanks very much to those that already do!) Without a wiki, we're back to patches that have to applied by committers. Of course, there is a DocBook Wiki, but first we'd have to address the infrastructure issues. Since the Struts 1 project documentation is already in XML, that's "a horse of a different color". -Ted. On 2/14/07, Philip Luppens <[EMAIL PROTECTED]> wrote: > Ok, any chance for a summary with roles on who's going to do what, and > in what timeframe ? > > Although limited in spare time (aren't we all), I'm definitely willing > to work on this (and I assume Musachy as well), but I would appreciate > directions or a concrete plan. > > Shoot. > > Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- iDTV System Engineer "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." - John F. Woods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Users guide
In Struts in Action, as with many text books, we included "Developer information" at the foot of a section or chapter as appropriate. So first, we covered the "user" material and then we covered the "developer" material, without creating two content streams. I don't see that mixing the two is a bad thing, or that separating the two is a good thing. Users do need to know that the framework is extensible, even if they don't want to extend it today. I would agree it would be helpful to add more "Developer information" to the project documentation, by adding pages for "Writing Interceptors" and "Writing Actions". * http://struts.apache.org/2.x/docs/guides.html People who don't want to write such things now, can just skip past those pages, until the occasion arises. Once place where I'd say we could use a separate guide is where we get into internal components, like the ObjectFactory and ActionMappers, which could be push into a separate "Architects Guide". * http://struts.apache.org/2.x/docs/architects-guide.html I would also agree that the bootstrap tutorial should be extended to include a CRUD tutorial. After a longer tutorial, I believe any reasonable person could read and understand the rest of the documentation. -Ted. On 2/14/07, Philip Luppens <[EMAIL PROTECTED]> wrote: I understand we don't want duplicated docs, but at the moment, we have to realize our Developers Guide is a mix of a Users Guide, Developers Guide and Reference Guide. If we take the following 'definitions' into account: - Developers: in-depth architecture, creating and extending Interceptors, Results, Validators, Themes, Templates, Plugins, .. - Users: explain the high level architecture, create Actions, create Views, configuration of the webapp (struts.xml, using annotations, mapping, ..), .. - Reference: contains the explanation and docs for each Validator, Interceptor, Result, Annotation, .. by using the snippet macro. I believe we can rearrange the docs fairly easily based on the list above (I understand it would mean a lot of work - but I'm ok with that and willing to step up for it). The amount of duplicated docs should be reduced to a minimum. Otoh, we could keep the current Developers Guide, and just provide an 'easy' outline or view for users that links to the current Developers Guide. Thoughts ? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Users guide
Ok, sounds fine to me. Then we'll drop the User Guide, and start writing on those missing chapters. Btw, the crud tutorial: should we make a part II where we use a real database (in combination with Spring and Hibernate) ? I've updated it and verified it to work on S2, but WW-1711 is used in the tutorial, so I'm not closing the Jira issue yet. Cheers, Phil On 2/14/07, Ted Husted <[EMAIL PROTECTED]> wrote: In Struts in Action, as with many text books, we included "Developer information" at the foot of a section or chapter as appropriate. So first, we covered the "user" material and then we covered the "developer" material, without creating two content streams. I don't see that mixing the two is a bad thing, or that separating the two is a good thing. Users do need to know that the framework is extensible, even if they don't want to extend it today. I would agree it would be helpful to add more "Developer information" to the project documentation, by adding pages for "Writing Interceptors" and "Writing Actions". * http://struts.apache.org/2.x/docs/guides.html People who don't want to write such things now, can just skip past those pages, until the occasion arises. Once place where I'd say we could use a separate guide is where we get into internal components, like the ObjectFactory and ActionMappers, which could be push into a separate "Architects Guide". * http://struts.apache.org/2.x/docs/architects-guide.html I would also agree that the bootstrap tutorial should be extended to include a CRUD tutorial. After a longer tutorial, I believe any reasonable person could read and understand the rest of the documentation. -Ted. On 2/14/07, Philip Luppens <[EMAIL PROTECTED]> wrote: > I understand we don't want duplicated docs, but at the moment, we have > to realize our Developers Guide is a mix of a Users Guide, Developers > Guide and Reference Guide. > If we take the following 'definitions' into account: > > - Developers: in-depth architecture, creating and extending > Interceptors, Results, Validators, Themes, Templates, Plugins, .. > > - Users: explain the high level architecture, create Actions, create > Views, configuration of the webapp (struts.xml, using annotations, > mapping, ..), .. > > - Reference: contains the explanation and docs for each Validator, > Interceptor, Result, Annotation, .. by using the snippet macro. > > I believe we can rearrange the docs fairly easily based on the list > above (I understand it would mean a lot of work - but I'm ok with that > and willing to step up for it). The amount of duplicated docs should > be reduced to a minimum. > > Otoh, we could keep the current Developers Guide, and just provide an > 'easy' outline or view for users that links to the current Developers > Guide. > > Thoughts ? > > Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- iDTV System Engineer "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." - John F. Woods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Users guide
Sadly, Hibernate's a bit of sticky wicket, because of the whole LGPL thing. We could do iBATIS, or Spring JDBC, or JPA, or anything under a compatible license. * http://people.apache.org/~cliffs/3party.html I've been wondering if Hibernate or iBATIS plugins would make any sense. As to the CRUD sections, we could just start by adding a "Accessing Data" section after after "Localizing Input", or create a "Part 2: CRUD", if that seems more appropriate. -Ted. On 2/14/07, Philip Luppens <[EMAIL PROTECTED]> wrote: Ok, sounds fine to me. Then we'll drop the User Guide, and start writing on those missing chapters. Btw, the crud tutorial: should we make a part II where we use a real database (in combination with Spring and Hibernate) ? I've updated it and verified it to work on S2, but WW-1711 is used in the tutorial, so I'm not closing the Jira issue yet. Cheers, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Users guide
--- Ted Husted <[EMAIL PROTECTED]> wrote: > So first, we covered the "user" material and then we > covered the "developer" material, without creating > two content streams. FWIW, I think two completely separate content streams is definitely a Bad Thing. I'd rather see a tutorial with sidebars containing more detailed information, links to more detailed information, or both. One thing that would help "clean up" the wiki guides is to format it more like a book: sidebars really work and are much less disruptive than a browser-width highlighted section. I don't know if that's possible with Confluence, but it sure could be handy. Another nice thing would be to have links to both wiki Guide sections and even JavaDocs throughout the pages (particularly the tutorial-level pages) for all the elements discussed on the page: configurations, annotations, classes, related tasks, etc. > Users do need to know that the framework is > extensible, even if they don't want to extend it > today. Figuring out where and *why* to extend things is critical... In S2 one great place to add functionality is in the interceptors, even if it's just configuring an existing one. The note on the wiki that says you probably won't need to do that is somewhat misleading, IMO. For example, yesterday I wanted a trivial way to add behavior to arbitrary methods on a per-Action basis without changing any Action code. So I wrote an interceptor that took as parameters "methodName: monitor1,monitor2" etc. That was great and worked until I discovered such an interceptor already existed, it just wasn't listed on the interceptor Guide page (MethodFilterInterceptor). Much lighter-weight than Spring AOP, and perfect for what I needed. For all I know there's a still-better way to implement it (wouldn't surprise me). Highlighting trivial extensibility goes a *long* way towards users a) not asking dorky questions (like me :) and b) really understanding the simplicity of the framework and utilizing its extensibility and cleanliness--my Action code is like 15 lines long but I can bolt on non-invasive functionality by writing a simple class and adding it to the list of "extra crap to do" items. My time is pretty limited these days, but I'm happy to help clean up, expand, notate, whatever the documentation (best way to learn!) as much as I can (and I even write real good sometimes :D and if I am pointed at something specific will take the time to do it up all purty-like. Dave Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Users guide
--- Niall Pemberton <[EMAIL PROTECTED]> wrote:
> [...]
I guess there's also a {float...} element; I tried a
little test on the Result annotation page (not much in
it, proof-of-concept).
It might be a good way to get links to additional info
w/o breaking the default "flow" of the page.
Dave
8:00? 8:25? 8:40? Find a flick in no time
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Users guide
On 2/14/07, Dave Newton <[EMAIL PROTECTED]> wrote: One thing that would help "clean up" the wiki guides is to format it more like a book: sidebars really work and are much less disruptive than a browser-width highlighted section. I don't know if that's possible with Confluence, but it sure could be handy. Stripes uses confluence and has index/contents on the left: http://stripes.mc4j.org/confluence/display/stripes/Home http://raibledesigns.com/rd/entry/confluence_installed_for_appfuse_2 Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: archetype
I'm getting this again on my windows box, could this be coming from the sitemesh plugin who has 2 optional references to velocity? : java.lang.NoClassDefFoundError: org/apache/velocity/app/VelocityEngine at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2395) at java.lang.Class.getDeclaredMethods(Class.java:1763) at com.opensymphony.xwork2.inject.ContainerImpl.addInjectors(ContainerImpl.java:102) at com.opensymphony.xwork2.inject.ContainerImpl$1.create(ContainerImpl.java:83) at com.opensymphony.xwork2.inject.ContainerImpl$1.create(ContainerImpl.java:81) at com.opensymphony.xwork2.inject.util.ReferenceCache$CallableCreate.call(ReferenceCache.java:155) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at com.opensymphony.xwork2.inject.util.ReferenceCache.internalCreate(ReferenceCache.java:81) at com.opensymphony.xwork2.inject.util.ReferenceCache.get(ReferenceCache.java:121) at com.opensymphony.xwork2.inject.ContainerImpl$ConstructorInjector.(ContainerImpl.java:328) at com.opensymphony.xwork2.inject.ContainerImpl$5.create(ContainerImpl.java:298) at com.opensymphony.xwork2.inject.ContainerImpl$5.create(ContainerImpl.java:297) at com.opensymphony.xwork2.inject.util.ReferenceCache$CallableCreate.call(ReferenceCache.java:155) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at com.opensymphony.xwork2.inject.util.ReferenceCache.internalCreate(ReferenceCache.java:81) at com.opensymphony.xwork2.inject.util.ReferenceCache.get(ReferenceCache.java:121) at com.opensymphony.xwork2.inject.ContainerImpl.getConstructor(ContainerImpl.java:559) at com.opensymphony.xwork2.inject.ContainerImpl.inject(ContainerImpl.java:457) at com.opensymphony.xwork2.inject.ContainerImpl$7.call(ContainerImpl.java:498) at com.opensymphony.xwork2.inject.ContainerImpl.callInContext(ContainerImpl.java:546) at com.opensymphony.xwork2.inject.ContainerImpl.inject(ContainerImpl.java:496) at com.opensymphony.xwork2.config.impl.LocatableFactory.create(LocatableFactory.java:32) at com.opensymphony.xwork2.inject.ContainerBuilder$4.create(ContainerBuilder.java:134) at com.opensymphony.xwork2.inject.Scope$2$1.create(Scope.java:49) at com.opensymphony.xwork2.inject.ContainerImpl$ParameterInjector.inject(ContainerImpl.java:428) at com.opensymphony.xwork2.inject.ContainerImpl.getParameters(ContainerImpl.java:443) at com.opensymphony.xwork2.inject.ContainerImpl.access$000(ContainerImpl.java:47) at com.opensymphony.xwork2.inject.ContainerImpl$MethodInjector.inject(ContainerImpl.java:287) at com.opensymphony.xwork2.inject.ContainerImpl$2.call(ContainerImpl.java:116) regards musachy Musachy Barroso wrote: It is working now. Thanks Wendy! musachy On 2/9/07, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 2/9/07, Musachy Barroso <[EMAIL PROTECTED]> wrote: > Creating a project with the maven starter archetype: > > mvn archetype:create -DgroupId=tutorial -DartifactId=tutorial > -DarchetypeGroupId=org.apache.struts > -DarchetypeArtifactId=struts2-archetype-starter > -DarchetypeVersion=2.0.3-SNAPSHOT > -DremoteRepositories= http://people.apache.org/repo/m2-snapshot-repository I updated the starter archetype to use the released 2.0.5 jars, and deployed a new snapshot. Change to 2.0.5-SNAPSHOT in your command above, and try it again, mvn jetty:run worked for me. Is there a reason that Spring 1.2.8 is declared in the pom generated from the archetype, instead of letting the struts2-spring-plugin determine the version? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[S2] wiki width
One thing that might help wiki readability is to reduce the width of the page; it's hard to read wide pages like that. Just an ideer. d. Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] wiki width
That's driven by the Confluence template used by the autoexport plugin. I checked in a copy of what we are using now. I think the only change from the default was to embed the licensing and copyright blurbs. * http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/site/confluence/ but, this isn't something I'm prepared to fuss with right now. Though, many cwiki projects just like ours are creating interesting autoexport sites. * http://cwiki.apache.org/ACTIVEMQ/home.html * http://cwiki.apache.org/ODExSITE/ * http://cwiki.apache.org/geronimo/ Among others. -Ted. On 2/14/07, Dave Newton <[EMAIL PROTECTED]> wrote: One thing that might help wiki readability is to reduce the width of the page; it's hard to read wide pages like that. Just an ideer. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] wiki width
On Feb 14, 2007, at 2:38 PM, Ted Husted wrote: That's driven by the Confluence template used by the autoexport plugin. I checked in a copy of what we are using now. I think the only change from the default was to embed the licensing and copyright blurbs. * http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/site/ confluence/ but, this isn't something I'm prepared to fuss with right now. Though, many cwiki projects just like ours are creating interesting autoexport sites. * http://cwiki.apache.org/ACTIVEMQ/home.html * http://cwiki.apache.org/ODExSITE/ * http://cwiki.apache.org/geronimo/ We're pretty proud of ours too: * http://cwiki.apache.org/OPENEJB/ Throwing that in there for fun :) -David Among others. -Ted. On 2/14/07, Dave Newton <[EMAIL PROTECTED]> wrote: One thing that might help wiki readability is to reduce the width of the page; it's hard to read wide pages like that. Just an ideer. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
