Tag Library and Struts Framework

[mini mehta]

I wanted know : What does Struts Framework gives, which can't be achieved by creating the Tag libraries. Is Struts bunch of Tag Libraries?

[Tony Alicea]

Struts ( http://jakarta.apache.org/struts/index.html ) is a framework and also uses tag libraries.
Some of the new WROX books on JSPs have a chapter or two on Struts.

[Adam Hardy]

There was the link to a good article on struts posted on javaranch 1 or 2 days ago. Try searching for struts

[Tim Holloway]

I got confused on that myself originally, and I'm afraid that most of the writeups and examples were done by people who already knew so well they thought it was obvious.
Gratuitous plug. Keep an eye out for the April issue of Java Pro magazine (it's available online if you can't get the print edition), where Your Humble Servant attempts to explain exactly what Struts really IS, And hopefully doesn't make too big a fool of himself trying.
Even in 4000 words (considered an oversize article for that publication) it's hard to completely explain what Struts contains and how to use it, but very briefly:
Struts is a collection of JSP tag libraries
AND
A "master dispatcher servlet" that breaks down URIs and routes them to user-written secondary dispatchers
AND
a set of extensible classes to implement these secondary dispatchers
AND
another set extensible of classes to assist in providing a data model to pair with JSP views of those models
AND
miscellaneous "helper" classes they found useful.
All of which fits in a remarkably small JAR and can be used (or ignored) as needed. One thing I like about Struts is that it's not one of these systems where you have to commit utterly to it or not use it at all. Makes migration much easier.

[Stephen Pride]

Tim,
Do you find learning/using Struts easier than going it alone (eg., implementing the similar MVC framework used as an example in David Geary's Advanced JavaServer Pages, whereby he uses a similar concept using a lone Action servlet as the Control, etc.)?
I have dabbled in Struts, but am sort of torn between learning/using Struts "full force" or "reinventing the wheel" so-to-speak. Currently, I've been learning/using the MVC approach by way of Geary's approach, since I have a guide (his book) and it appears to be taught at a lower level (but this may be my inability to dig deeper into Struts).
Regards ...

[Tony Alicea]

"One thing I like about Struts is that it's not one of these systems where you have to commit utterly to it or not use it at all."
Yep! About 1.5 years ago before Struts was released in "release version" 1.0, my manager used the concept and since then we have based all our web apps on that framework without downloading/using the actual Struts...

[mini mehta]

Originally posted by Tim Holloway:
I got confused on that myself originally, and I'm afraid that most of the writeups and examples were done by people who already knew so well they thought it was obvious.
Gratuitous plug. Keep an eye out for the April issue of Java Pro magazine (it's available online if you can't get the print edition), where Your Humble Servant attempts to explain exactly what Struts really IS, And hopefully doesn't make too big a fool of himself trying.
Even in 4000 words (considered an oversize article for that publication) it's hard to completely explain what Struts contains and how to use it, but very briefly:
Struts is a collection of JSP tag libraries
AND
A "master dispatcher servlet" that breaks down URIs and routes them to user-written secondary dispatchers
AND
a set of extensible classes to implement these secondary dispatchers
AND
another set extensible of classes to assist in providing a data model to pair with JSP views of those models
AND
miscellaneous "helper" classes they found useful.
All of which fits in a remarkably small JAR and can be used (or ignored) as needed. One thing I like about Struts is that it's not one of these systems where you have to commit utterly to it or not use it at all. Makes migration much easier.

Cheers Tim. That is the explaination I was looking for.

[Adam Hardy]

Plus Struts makes it easier to implement:
connection pooling
multi-lingual options
server-side form field validation
Which makes me think I've just got to use it. I found a line on the website which mentioned that in certain scenarios which you can implement:

If you declare such beans in your ActionMapping configuration file (see " Building the Controller Components"), the Struts controller servlet will automatically perform the following services for you, before invoking the appropriate Action method:
* Check in the user's session for an instance of a bean of the appropriate class, under the appropriate key.
* Blah blah

Doesn't storing big things like bean instances in a session make your app unscalable?
Adam

[Jason Menard]

You don't have to store things in session in Struts, you can just as easily place things into request scope. Looking at the following example struts-config.xml file we see that the viewMyForm action of type myPackage.ViewMyFormAction is using the ActionForm myForm of type myPackage.MyFormBean, in request scope.

<form-beans>
   <form-bean name="myForm"
              type="myPackage.MyFormBean"/>
</form-beans>
<action    path="/viewMyForm"
           type="myPackage.ViewMyFormAction"
           name="myForm"
           scope="request"
           input="/MyForm.jsp">
  <forward name="success" path="/Confirm.jsp"/>
</action>

[Adam Hardy]

Pardon my ignorance but what's the point of that? What is request scope? Scoped to all requests or just to each individually?

[Jason Menard]

Originally posted by Adam Hardy:
Pardon my ignorance but what's the point of that? What is request scope? Scoped to all requests or just to each individually?

The short answer is individually. The long answer... Objects in session scope remain (unless removed of course) for the life of the session. Objects in request scope live for the life of the request.
I like to think of a request's lifespan like this. If you are on an HTML page, when you click a link or submit a form, a new request is sent to the server. When the next page finishes being displayed, that request is dead.
To put it in terms of struts, a request is sent to the ActionServlet (the control, as generated by the struts-config.xml file), the servlet passes this request to the Action so the Action can do its thing (which might include placing objects into the request), then the ActionServlet forwards that request to the JSP view, which can then make use of any objects that were placed in the request along the way. In the case of an ActionForm, the form object is placed into the specified scope by the ActionServlet.
You would use session scope for objects that need to be persistant through the lifetime of the user's session, such as an object that maintains user state. You would use request scope for objects whose data only needs to persist long enough to be displayed by the view, or only long enough to be accessed by some other servlet that the request may forwarded to. And while we're on a roll, application scope is for objects that need to persist for the lifetime of the entire servlet (such as a connection pool perhaps), and page scope is for objects that are instantiated in the view and whose data only persists for that view (maybe a bean that displays the current date).

[Adam Hardy]

There are certainly many rivers to cross. I don't understand how the action mappings file works yet - it's different to the web.xml file is it?
I've worked out scope though, thanks.
I'm just launching myself into Struts (I'm still sliding down the launch slipway). Actually you only answered the Struts question indirectly - so in connection to that quote above, why would you want to put beans in your session? Especially if you can use the request?
Adam

[Jason Menard]

I am working on a project where one of our objects is a User object. The User object maintains certain information about the user logged into the system. Besides the obvious thing like name and other identifying info, including the "role" of the user. The user's role determines to what extent he can interact with the system. For example a user with a role of "ordering officer" can generate an order form but not fill out the financial information, whereas a user with a role of "budgeting officer" can fill in the financial information but cannot alter what the ordering officer has entered. In turn different roles may be presented different options on a screen than somebody with a different role.
So this is information that we need throughout the system as long as this user is logged in (as long as he is in session), but we only want to load it from the database once. Therefore when the individual logs into the system, we instantiate a User object for him, populating it with info from the database, and then place this object into session.
If we wanted to use request scope, we would have to constantly determine who the user was so that we can instantiate a new User object for him, make the database call to populate the User object, and then place the object into the request.
So basically you use session for anything specific to one user that you need to maintain state for. Another example of using session scope would be a shopping cart. You need to maintain the state of the shopping cart while the user is shopping since he may be continuously adding items to the cart while jumping around the different pages of your site. This is also information that is specific only to this user. Once the user logs out maybe you will save the info off to the database for access next time he goes shopping, or maybe you will just destroy the shopping cart, either way you no longer need to keep this object around since the user who owns the shopping cart is no longer logged on. So the shopping cart satisfies the criteria of something you need to maintain state on, that is particular to the user.
To get a little more complicated, my User object "has" a ShoppingCart object. I keep the User in session, so since the User has a reference to the ShoppingCart, the ShoppingCart is also maintained for the life of the User object. But I only need to give the view access to the ShoppingCart on a couple of pages. In this case what I do is in my Action where the system needs to display the shopping cart contents, grab the User from session, get the ShoppingCart from the User, and place it into request for use by the view that the Action forwards to. This makes housekeeping a little easier, particularly since you need to worry more about keeping the session relatively clean than you do the request.

[Adam Hardy]

Presumably your User object and ShoppingCart object are not very big, memory-wise? I.e. if you get a surge of users logging on to your site, it's not going to bring it down?

[Jason Menard]

There are no problems with memory.