Developer Forum

I am a JSP developer and am constantly feeling like I am missing the
boat by not using any of the other frameworks out there.

However, the couple I have looked at (JSF and Rails) don't impress me.
In JSP, I keep all of my logic in Servlets/Beans and all of my
presentation in the JSP file, making custom tags when I need to do some
HTML that involves some logic. So Servlets and Tags are the glue to the
JSPs and Beans. I don't see what is wrong with this model. The
biggest advantage is its flexible.

An example of my frustation with JSF (which is different than all the
other complaints) was attempting to popup a JSF page in a new window, I
had to to some hokey stuff to make it happen. Rails seems to claim how
easy it is to get something up and running. Well, I don't mind taking
a day (or a week) to get my foundation right, and then having a
flexible, high performance base from which to develop from. I don't
want 80% to be easy and then the last 20% to be practically impossible.

And, finally, I am confused by all the other choices that I haven't
even mentioned. However, I'm not looking for a dozen replys that say
'Go try this or that'.

I would like to know: What is wrong with a JSP/Custom
Tags/Servlet/Beans design (Not necessarily the full J2EE model 2)?

Thanks
Sam

In my book, nothing is wrong with that. As a contractor, however, I
often feel that using Struts (previously, now converting to JSF) is
safer, easier to maintain and upgrade.

It's too inconvenient to use for me. Take a look at tapestry 4, the
page is just plain html with extra attribute for components, so web
designers can co-work with you at the same time. And it supports IoC,
annotations, and better state management, etc.

I also happen to read the JSF specification lately, I guess by using
JSF framework , i think we are looking at a framework that
doesnt restrict to HTML, HTTP and some other constraints that we are
used to.
May be I can quote the introduction here for you to understand what is
JSF and its punch line.

"JSF's core architecture is designed to be independent of specific
protocols and
markup. However it is also aimed directly at solving many of the common
problems
encountered when writing applications for HTML clients that communicate
via
1-8 JavaServer Faces Specification February 2004
HTTP to a Java application server that supports servlets and JavaServer
Pages (JSP)
based applications.
JSF tackles the following challenges associated with these
applications:

Managing UI component state across requests

Supporting encapsulation of the differences in markup across
different browsers
and clients

Supporting form processing (multi-page, more than one per page, and
so on)

Providing a strongly typed event model that allows the application to
write
server-side handlers (independent of HTTP) for client generated events

Validating request data and providing appropriate error reporting

Enabling type conversion when migrating markup values (Strings) to
and from
application data objects (which are often not Strings)

Handling error and exceptions, and reporting errors in human-readable
form
back to the application user

Handling page-to-page navigation in response to UI events and model
interactions."

Guess the gist is more than this.

Rgds
Sanjay

...

<zen question>
What 'hokey stuff' does the end user need to do/install to
avert that (often irritating, and uninvited) pop-up/new window?
</zen question>

--
Andrew Thompson
physci, javasaver, 1point1c, lensescapes - athompson.info/andrew

You'd probably find that Struts is a very lightweight add-on to whatever
it is you're currently doing. It's just a lightweight framework for
structuring things in the way you're already doing them, but taking some
of the logic out of the code and putting it into config files.

If it isn't (and I think it probably is) then go read "Bitter Java". If
that _still_ doesn't make you re-think your application structures at
the design pattern level, then you're probably missing the boat
completely - the code probably sucks and looks more like ASP than decent
JSP/Servlets. (or, &deity; forbid, it looks like PHP).

"Sam" < XXXX@XXXXX.COM > wrote ...
: I am a JSP developer and am constantly feeling like I am missing the
: boat by not using any of the other frameworks out there.
:
: However, the couple I have looked at (JSF and Rails) don't impress me.
: In JSP, I keep all of my logic in Servlets/Beans and all of my
: presentation in the JSP file, making custom tags when I need to do some
: HTML that involves some logic. So Servlets and Tags are the glue to the
: JSPs and Beans. I don't see what is wrong with this model. The
: biggest advantage is its flexible.
:
: <snip>

I also come from a similar view point. Regardless of the framework in use, having a clean separation
between presentation and logic is a design I strive for. I have seen examples of JSF (also EL in JSP
2.0) and it feels wrong, to me. In terms of what JSF "tackles", they can all be done with the
JSP/Servlet model. In fact JSF is just a higher level of abstraction build on top of JSP/Servlet.

I think JSF is more useful for page designers as they can "add" logic to their application without
learning Java, servlets or custom tags. The trade-off is they have to maintain spaghetti code.

.k

Thanks for all the replys.

All I am trying to say is what is so wrong with a "well architected"
JSP/Custom Tags and Servlets/Beans? Is it really that much more
complicated? Too slow to develop in? Hard to maintain? I just don't
see any of these as problems.

I admit there are some things that each Framework does better (Rails -
gets you up and running quickly, JSF - handling page to page navigation
and UI control stuff like maintaining state) but they also have their
drawbacks.

With so many frameworks it just confuses developers and makes all of
the frameworks "less than they could be" by creating FUD (as to which
one to use, am I using the right one) and spreading the expertise too
thin.

It's really a shame...

Sam

I am really glad you started this thread. I had similar questions a few
months ago in this group and I guess I didn't expose my idea clearly
enough: I got only two answers telling something like "framework sucks"
with no real explanation.
I am currently working on a new web application, which today is basic
ASP, i.e. presentation, business logic and UI control are all mixed in a
indigestable (does that word exist ? :) ) messy soup of M$ code.
We are moving to J2EE, and we are exploring the differenct frameworks.
We came to similar conclusions: frameworks are great stuff to help you
do basic or "not-too" advanced web-app. But as soon as you have specific
need, or you want something the meets only your needs (i.e. not a
generic reusable multipurpose code) to optimize the application, then
the only way we found is to design our own framework.
The task is not too complex, as we got our inspiration from those
existing framework, but we take only the things that are usefull to us
and rebuild it the way we need it.
It has however a drawback: if you have an important turn-over in your
staff (here in Thailand this is crazily important), then the new staff
has to learn your framework. The learning curve is a little bit slower.
If you use struts for ex., then in your job description you can filter
easily.
Also, the framework you design might need some time to be "bullet-proof"
and stable.
One good point is that it is interesting to design and create.

But we really think it is better this way and we are actually quite
confident in what we have done so far. We are not done yet, but I would
say we are about 40% from a nice (small) framework.

Good luck

--
JSC

I believe that large, complex web sites can benefit from an MVC
framework like struts. However, for the benefits to pay off, the site
must be well designed from the ground up...looking at the flow of
information, databases, business objects/processes, authentication,
security, i18n, rapid/dynamic customization, etc.

From my experience, struts does not lend itself to quick and dirty.
Just my $0.02.

-Missaka

There is nothing wrong with it. After all, these frameworks are also
built on top of those technologies as well. It sounds as if you already
have a framework of your own code built up. So unless you find it too
complicated, too slow to develop in or too difficult to maintain just
keep on truckin'.


HTH,
Ray

--
XML is the programmer's duct tape.