> For Struts, O'Reilly has a pretty good book, the title of which elludes
me at the moment,
Programming Jakarta Struts 2nd ed - Chuck Cavaness
Stuts The Complete Reference - James Holmes was the first Struts book I
read and was very helpful. Each chapter gave a good overview before
getting into the details and the code example was simple and manageable.
Bart
"Frank W. Zammetti" <[EMAIL PROTECTED]> wrote on 12/08/2004 11:11:01 PM:
> Sounds good! You'll find that the people here are extremely helpful,
> but they do tend to shy away from general questions (unless they are SO
> general as to be theoretical, in which case EVERYONE has an opinion :)
> ), so the more specific a question you can ask, the better.
>
> As for books to read, I would highly recommend grabbing the latest copy
> of Head First Servlets and JSP. It's not Struts-specific, but it is
> really necassery to know what is going on beneath Struts, and it is the
> best I've seen in this area (I'm currently using it as a study guide for
> the SCWCD exam, but it's good for anyone I'd say). Frankly, if you get
> everything in that book, most of Struts will make sense almost
> immediately. For Struts, O'Reilly has a pretty good book, the title of
> which elludes me at the moment, but I suspect it's the only one they
> sell. At times it goes into a little TOO much detail for people trying
> to get a start in Struts, but most of it is excellent.
>
> As for your specific architecture questions... Generally speaking, your
> concern about putting all application state for a user in session is
> valid. This isn't what session is for. It's really for fairly small
> BITS of state information, things that will in all likelihood change
> frequently, and certainly nothing that should persist beyond a session
> (hence the name!). But, in your case, since you are just using it as an
> example, I wouldn't worry about it, go ahead and use session, it'll be
> easier.
>
> In Struts, Actions can be shared across requests, which means that if
> you have class-level variables, they are, potentially, shared across
> multiple requests. Clearly this is a formula for disaster.
>
> There are two ways you could go here... one is to use session as I said,
> the other is to have a "data storage class" that just has some static
> members, most probably a Map of some sort. You can use this as
> something of a poor man's database. Think of a HashMap for instance as
> a database table. Now, assume each element you add to the HashMap is
> itself a HashMap. You can think of these "inner HashMaps" as rows in
> the table. Then, each element in that inner HashMap is a field in the
> table. Make sense? You can go so far as to create insertRow(),
> deleteRow() and updateRow() methods for your data storage class... These
> would do the functions their name implies on the HashMap, and you can in
> that way "key" your data, i.e., each "row" has an element recordKey
> let's say. So, your insert method can throw an exception if a "record"
> exists with that key already. In fact, you could go so far as to throw
> a SQLException, and in that way you could replace that data storage
> class with a class that talks to a database down the road, and nothing
> that uses that class should have to change.
>
> But that's getting ahead of ourselves a bit :) If you intend to build
> something that you know would usually use a database, then the second
> approach is a good idea. Be sure to synchronize your access to your
> Maps (which would be a bottleneck in a real application, but you can get
> away with it here, and in general in any application that isn't going to
> have a big load). But, using session might be easier, depends on how
> much work (and control) you want. For a shopping cart, the volume of
> data isn't going to be great, so no worries there.
>
> But, the golden rule with Struts to remember is no class-level
> variables! That's what all this is designed to avoid.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> Simon MARTIN wrote:
> > Hi,
> >
> > thanks for your offering of help.
> > I know that my Struts knowlegde is not the best yet -- no question
about
> > it -- but I'm willing to change that, as far as my time allows it.
> >
> > Fortunately, my lecture is not of that importance you might have
> > assumed, as I'm 'only' giving a presentation at school. However, I of
> > course want to present something I know about, so this does not really
> > change the situation.
> >
> > As I can see what you're telling me, I think my learning has been to
> > practice-orientated and too less theory-orientated, which brings me
into
> > trouble when the requirements change.
> > So far, I've only strictly written Spring apps with Struts MVC or
> > without Struts MVC, but, in any case, with Hibernate as ORM-framework.
> > Therefore, I really came into troubles when using Struts alone, and
then
> > even doing so without a database.
> > Of course, I had thought about putting the stuff into the session,
> > either, but putting complete client-state into the session seemed
> > unclean to me, as I personally had prefered some kind of
> > property-setting statically.
> > Please let me know about further architectural mistakes I've done.
> >
> > I've started reading Wiley's 'Mastering Jakarta Struts', which
> > unfortunately seems kind of outdated to me. Please let me know about
> > better alternatives.
> >
> > Furthermore, I'd appreciate any kind of help.
> >
> > Kind regards and thanks in advance,
> > Simon
> >
> >
> > [EMAIL PROTECTED] wrote:
> >
> >> PLEASE do not take offense from what I am about to say. I do not mean
> >> to be anything but constructive and helpful...
> >>
> >> I am concerned that you are trying to build an example for those you
> >> will be teaching because I can see some fundamental misunderstandings,
> >> or gaps in your knowledge. I'd be willing to guess that someone (your
> >> emoployer?) asked you to teach some people because you were the best
> >> of the group, and if that's the case I most certainly commend you for
> >> taking on the task.
> >>
> >> However, I think it would be in your best interest, and certainly in
> >> your students' best interest, to take some time and become more
> >> familiar with the topic(s) you are going to be teaching. I and others
> >> here could give you the answers, and we'd be happy to do so, but the
> >> questions you are asking are things that you really should be able to
> >> answer yourself in light of the fact that you are going to be
> >> teaching, and might face the same questions, or others that will test
> >> your fundamental knowledge. I'm not just talking about learning
> >> Struts here, which certainly is a big part of it. I sense you may
> >> have some learning to do with regard to web application development in
> >> general.
> >>
> >> Again, I hope I have not offended you, that is not my intent in any
> >> way. If your just learning this stuff yourself, that's great, we'll
> >> all help any way we can, but I would really try and hold off on the
> >> teaching for a while until you see these answers yourself.
> >>
> >
> >
> > > On Tue, December 7, 2004 1:59 pm, Bill Siggelkow said:
> > > Simon,
> > >
> > > Actions should not hold client-state; instead, you can create a
> > > ShoppingCart in the Action but then save it in the HttpSession.
> > >
> > > Without going into to many details, I suggest you take a look at the
> > > Struts MailReader example distributed with Struts.
> > >
> > > -Bill Siggelkow
> > >
> > >
> > > Simon MARTIN wrote:
> > >
> > >> Hi,
> > >>
> > >> I'm currently writing a short Struts application without a database
(I
> > >> know that this would be better, but as it is only for teaching
> > purposes,
> > >> I don't want to 'overflow' my audience with databases and ORM).
> > >> It should be a small online sales system -- I've got ShoppingItems,
> > >> ShoppingUsers (which are not yet used) and ShoppingCarts.
> > >>
> > >> I want a ShoppingCart which stores the ordered items per user. I
had
> > >> something like this:
> > >>
> > >> public class ShoppingCartAction extends DispatchAction {
> > >> private ShoppingCartManager shoppingCartManager;
> > >> ...
> > >>
> > >> public ActionForward order(...)
> > >> ...
> > >>
> > >> public ActionForward list(...)
> > >> ...
> > >> }
> > >>
> > >> and thought that it would work. Unfortunately, each user (which is
not
> > >> authenticated or anything yet) gets the same shopping cart when he
> > calls
> > >> shoppingCart.do?method=list.
> > >>
> > >> So I did some research and found this:
> > >> http://www.jguru.com/faq/view.jsp?EID=1057609
> > >>
> > >> So I created an ShoppingCartMapping class
> > >>
> > >> public class ShoppingCartMapping extends ActionMapping {
> > >> private ShoppingCartManager shoppingCartManager;
> > >> ...
> > >> }
> > >>
> > >> and call it like this
> > >>
> > >> public ActionForward list(ActionMapping mapping, ActionForm form,
> > >> HttpServletRequest request,
> > >> HttpServletResponse response)
> > >> throws Exception {
> > >> request.setAttribute("orderedItems",
> > >>
> > ((ShoppingCartMapping)mapping).getShoppingCartManager().getItems());
> > >> return mapping.findForward("list");
> > >> }
> > >>
> > >> which gives me a ClassCastException.
> > >>
> > >> Do I have to set my custom ActionMapping in web.xml or
> > >> struts-config.xml?
> > >> Am I on the right way, or is there a better way of doing this?
> > >>
> > >> Thanks in advande and kind regards,
> > >> Simon
> > >>
> > >> PS: Please cc me in your answers.
> > >
> > >
> > >
---------------------------------------------------------------------
> > > 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]
> >
> >
> >
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> 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]
