Just wanted to say that I have been using struts on our admin site thus far
with very little problems. As far as performance, I have noticed a huge
increase in speed as far as when a form is submitted and the response is
returned. I can't pinpoint what to attribute this too, but it is impressive.
Maybe its just because Orion app server is so fast.
As far as complexity, let me tell you this much. Our "old" design was a
series of servlets, descending from one another to increase functionality
per area of our site. Each form would be submitted to a specific servlet,
all descending from DefaultServlet which was much like the "controller"
entry point. The difference being each servlet was called, instead of a
single entry servlet. We could put the same checks in DefaultServlet that
all servlets would inherit and thus one place in code would check for
security, etc. However, the complexity of this model is that when a bug
crops up, you have to look through one or more (usually alot more) source
files. Worse, if you need to modify the DefaultServlet, it is reflected in
every servlet descending from it.
With Struts, the "worst" complexity is probably the action.xml and I say
that only because if you have 150 forms, you'll have at least 150 action
mappings in action.xml. This means you'll be scrolling a bit if you need to
look for one in the file. However, this in my opinion is a good thing
because you map all your actions in one file. If it's too large, you can do
as Craig said..break your app up into separate web apps, but as he
said..keep in mind sessions don't cross web-app boundaries. I wish there was
a setting for this, because it would be nice to functionally build a .war
file and make it available as a plugin to anyones J2EE web site. Since
sessions don't cross web-apps, it makes it hard for this to work..infact, I
think its impossible.
At any rate, while your not worried about scalability, I believe the Model 2
approach and Struts will actually give you the best of both worlds..good
performance and easily scalable. You can quickly add new forms. I find my
development is very fast using Struts. It takes about 2 minutes to add in a
few mappings in the action.xml, then you create a javabean (if you want
struts to auto-populate the form into a bean). That bean is auto-populated
by the time your action class is called, thus your action class is ready to
use the elements of the form right away. So you create a javabean and an
action class. Thats it. Ofcourse..you may want to derive action classes from
base classes to inherit some common functionality. I built a simple cart
action that my admin actions derive from. This one action class handles
creating new items, deleting groups (one or more) items, searching for items
based on a generic search mask, updating a selected item, canceling (going
back), and editing (which then relies on the update). All my admin actions
derive from this and they simply have a few small methods and the rest is
done. Works out great!
Anyways..you'll get good scalability as far as adding more forms..it will be
VERY fast to do, and you'll have a good framework (Struts) to work with that
is supported by a good team of developers. There are some things that Struts
doesn't do that I Would like it to do..I have voiced those and they may or
may not make it into Struts. If not, I have the source which I can modify. I
would rather not..but its there if needed.
Hope that helps.
> -----Original Message-----
> From: A mailing list about Java Server Pages specification and reference
> [mailto:[EMAIL PROTECTED]]On Behalf Of Martin Cooper
> Sent: Thursday, August 24, 2000 9:16 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Model 2 and large applications
>
>
> Thanks for the response. I guess I should have been more clear. I'm not
> concerned about a performance impact. As you say, it should not
> be an issue.
> I *am* concerned about code complexity, manageability, and maintainability
> with as many forms as I have.
>
> --
> Martin Cooper
> Tumbleweed Communications
>
> ----- Original Message -----
> From: "Tim Fox" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, August 24, 2000 8:35 AM
> Subject: Re: Model 2 and large applications
>
>
> see below:
>
> Martin Cooper wrote:
>
> > I am currently looking at building a large application based on servlets
> and
> > JSP. The principles behind the Model 2 architecture are solid, and this
> > seems like the right approach. However, I have some concerns, and would
> like
> > to hear people's thoughts.
> >
> > The application I am building will likely comprise somewhere between 100
> and
> > 150 forms. The use of a single controller servlet, a la Model 2, is
> > attractive because it provides a focal point for security and database
> > connectivity, amongst other things. However, it raises some concern
> > regarding the manageability of so many "entry points" (for lack of a
> better
> > term).
> >
> > It seems that I would need some further structure to partition the
> > application. I have thought about creating "zones" of functionality, but
> > it's not clear (to me, at least) what the cleanest and most maintainable
> way
> > of doing this would involve.
> >
> > I have been looking at the Jakarta Struts framework, and very much like
> the
> > way that forms and actions are hooked up. However, I'm concerned that it
> > won't fly for an application with so many forms as I will have.
> >
> > By the way, this is an intranet app, not an Internet app, and, as such,
> > there will be a relatively small number of users. Scalability
> in number of
> > users is not important to me, but scalability in number of forms is.
>
> I don't see that using the model 2 type architecture will have
> any negative
> impact
> on the speed of your application.
> Just because all requests are being channelled through one servlet (the
> dispatcher)
> does not imply any any performance degradation compared to, say,
> calling the
> jsp
> files directly.
> This is assuming the dispatcher has been written correctly - the
> main thing
> to bear
> in mind is that your dispatcher must not be a thread bottleneck - this is
> ensured
> by not storing any state between requests in your dispatcher - ie
> everything
> should
> be on the stack.
>
> >
> >
> > Any thoughts would be very much appreciated.
> >
> > --
> > Martin Cooper
> > Tumbleweed Communications
> >
> >
> ==================================================================
> =========
> > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> > Some relevant FAQs on JSP/Servlets can be found at:
> >
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
> --
> Tim Fox (��o)
>
> Hyperlink interactive
> http://hyperlink.com
> email: [EMAIL PROTECTED]
> phone: +44 (0) 207 240 8121
>
> ==================================================================
> =========
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
> ==================================================================
> =========
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
