Would a layout like Groovy make what we have more accessible?
* http://groovy.codehaus.org/
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
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
--- 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
--- 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 co
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
uppens <[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:
>
>
e 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 Devel
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 extendi
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.
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 Hu
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 f
Yup. Spring uses Docbook. That's what I am going to try: single html
page (everything), multiple html pages, and PDF. Spring distro has this:
We're using the DocBook XSL distribution for HTML and PDF
generation. The best results can be achieved with the
Saxon XSLT processor (don't use Xalan
On 2/13/07, Paul Benedict <[EMAIL PROTECTED]> wrote:
I agree with Ted's comments on the S1 layout. I am going to try some
experimenting with the Struts 1 User Guide for the 1.4 release and what
else we can do with it. I'll just do it for fun and see if I can make
HTML and PDF documents from one s
I agree with Ted's comments on the S1 layout. I am going to try some
experimenting with the Struts 1 User Guide for the 1.4 release and what
else we can do with it. I'll just do it for fun and see if I can make
HTML and PDF documents from one source. Stay tuned.
Ted Husted wrote:
After six ye
Based on this thread, and some others, I've rearranged the pages in
the Core Developers Guide to follow the natural flow of the framework.
* http://struts.apache.org/2.x/docs/guides.html
For now, I've also added markers for some "missing pages" that would
help fill in the gaps. For example, we d
ides we want (installation guide, user guide,
developer guide, reference, tutorial, ..), and what the goal/outline
for each guide is.
I admit: the current guide and outline is not for newbies. Part of
Struts success was its excellent Users Guide, something I really want
to see in Struts 2 - because
Could we merge the "users guide" with the bootstrap tutorial? Adding an
introduction/overview and explaining the concepts along the tutorials?
musachy
Philip Luppens wrote:
On 2/12/07, Tom Schneider <[EMAIL PROTECTED]> wrote:
Just to add my 2 cents...
I agree with Ted that t
r guide,
developer guide, reference, tutorial, ..), and what the goal/outline
for each guide is.
I admit: the current guide and outline is not for newbies. Part of
Struts success was its excellent Users Guide, something I really want
to see in Struts 2 - because it would greatly impact the succes
is supposed to give insights into the inner
> workings of Struts 2, about extension points (Interceptors, Plugins,
> PreResultListeners, ..), but right now, it looks more like the
> reference guide.
>
> So, let's decide what guides we want (installation guide, user guide,
> d
ultListeners, ..), but right now, it looks more like the
reference guide.
So, let's decide what guides we want (installation guide, user guide,
developer guide, reference, tutorial, ..), and what the goal/outline
for each guide is.
I admit: the current guide and outline is not for newbies.
On 2/12/07, Musachy Barroso <[EMAIL PROTECTED]> wrote:
I think the idea is just to organize the info in a way that a user new
to struts 2 can understand. From my personal experience, when I started
with S2, I couldn't make sense out of the wiki, I had to read WW in
Action, and after that, the wik
It's also not clear whether the intention is to create new content or
link to the old.
I think the idea is just to organize the info in a way that a user new
to struts 2 can understand. From my personal experience, when I started
with S2, I couldn't make sense out of the wiki, I had to read WW
After six years of maintaining the Struts 1 User Guide, for what its
worth, here's some personal feedback.
* Separating the content into model, view, and controller sections is
often problematic since most workflows cross that boundary. It's hard
to discuss a routine task beginning to end.
* It'
Phil and I started to work on a "User Guide" that resembles the one from S1,
to help new users learn S2:
http://cwiki.apache.org/confluence/display/WW/User+Guide
Every time you contribute to this guide, a donation will be made to the New
Users Foundation :)
musachy
--
"Hey you! Would you help
24 matches
Mail list logo
