Re: OReilly Struts book

[Hertzel Karbasi - OPTinity eBusiness Solutions <he...@optinity.com>]

Great!!
1. IMO it's better to cover Struts 1.1 as I see in your TOC there is a just
and appendix
    for changes in 1.1.
2. Are you going to cover some design patterns related to J2EE+EJB in
reference to Struts?
3. An Order Entry/Shopping Cart application would be more usable and popular
than Banking.
4. What about XML/Wap in view components?
5. What about extending Struts (Workflow, Service Manager, Data Formatting,
...)?

Hertzel
----- Original Message -----
From: "Chuck Cavaness" <cc...@NetVendor.com>
To: "'Struts Users Mailing List'" <st...@jakarta.apache.org>
Sent: Tuesday, January 29, 2002 7:57 PM
Subject: RE: OReilly Struts book


> Thanks for the input; all of it is right on track of what others have been
> mentioning. I plan to tackle many of the more finer-grained issues like
> request versus session storage, when to forward versus redirect, wizards,
> etc... I'm going to try to wrap them into real-world, albeit small,
> examples. As with any book, the problem boils down to space and time. I'm
> sure that Ted and the other Author doing the Struts book for Wiley are
going
> through the same issues right now.
>
> In the end, I won't be able to cover every single topic that involes
Struts
> or web development. It's just not possible to do so. What I have to do is
to
> hit all of the major topics and as many of the smaller ones that I can.
> OReilly books tend to be more for the intermediate or advanced, rather
than
> the absolute beginner. That's tough because it always leaves a group out,
> but as someone mentioned to me earlier, you have to cut the line
somewhere.
>
> Tiles will definitely be a topic and topics like the Struts Console from
> James Holmes deserve some coverage. The IDE topic is an interesting one
and
> definitely worthy, but it's a question of how do I cover all of the
possible
> IDE's that people use. For example, here at my company, people create,
edit,
> and debug Struts with everything from JBuilder5, SlickEdit, TextPad, vi,
and
> several more. These guys are all good and have excellent debugging skills.
I
> believe that it's true that using an IDE and stepping through code will
save
> debugging time. However,  we also don't force a standard IDE down
someone's
> throat as long as they can code and debug fast with good quality. So that
> one scares me a little. I might be able to select a few IDE's, but someone
> will always get left out. The good news is that I'm still flushing out
about
> half of the chapters and sections, so nothing is out at this point.
>
> Chuck
>
> -----Original Message-----
> From: Sandeep Takhar [mailto:sandeep_takhar@yahoo.com]
> Sent: Tuesday, January 29, 2002 9:49 AM
> To: Struts Users Mailing List
> Subject: RE: OReilly Struts book
>
>
> this looks quite impressive.
>
> Some thoughts...
>
> The examples that you give should be more than just a
> banking application I think.
>
> I believe you should have some value-add in the book.
> For example -- when to use session storage vs request
> storage.
>
> I know there are new featues such as forwarding
> actionforms (I think there is something mentioned
> about this.)  It would be nice to know a practical
> example of using this.
>
> I like what you are doing with security and
> exceptions.
>
> two other people mentioned having something about
> tiles and something about using ide's.  This has my
> vote as well.
>
> I think that you should have as many references to
> other complimentary books.
>
> Is the EJB section as complete as it can be?
>
> How about team based development.  Setting up
> sandboxes, issues with config files.
>
> Are you using tomcat for examples?  How about some
> configuration issues with other containers.  I am
> thinking of weblogic...
>
> Which tools to use for developing with custom tags (I
> have hear of ultradev and it's add-ons is good).
> Other tools -- There have been numerous mentioned in
> this list -- there was one today about tables and
> another about struts code generators etc.
>
>
> I also think you should keep in close contact with who
> the developers are -- I bet they have some great ideas
> on what to document -- what to expect etc.
>
> just some thoughts
>
>
> Sandeep
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>