Chris,
My doubts:
1) To avoid writing any HTML code inside java bean,
one will send results in form of Vector,Strings and
then it will be used inside JSP to present into HTML
format. This may be a complicated table too. Whether
this will have effect on performance ? Also, Since
this is a dynamic generated table, The presentation
designer won't be able to do much. So does it make
sense to generate such tables inside bean.
2) You said application server is used to provide
business logic and DB connectivity. what is the cost
involved in locating remote objects thru ORB. Do you
keep objects in any pool to use later, or locate
objects everytime.
Pankaj
--- Chris Bartling <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> I've been converting our Web application from
> servlets to JSPs and I've made
> sure that my JSPs are dealing only with business
> objects implementing
> standard interfaces. We have a requirement that our
> persistent business
> objects be able to work with a number of RDBMSs, so
> my JSPs only "know"
> about the business object interfaces and the methods
> these interfaces
> support. I don't do any sort of JDBC access from my
> JSPs, deferring this
> responsibility to an app server (we're currently
> using Objectspace's Voyager
> product for ORB communications, but we'll be moving
> over to EJB very soon
> now). I've also created a bean which acts as a
> client on the ORB and pass
> this between JSPs through the Session object. This
> design is working great
> for us. I've noticed a huge improvement in
> productivity with JSPs over
> servlets, and I was one of these people who used
> regular expressions and
> token replacement within servlets and poo-pooed JSPs
> initially.
>
> I feel the more functionality that you can
> encapsulated into beans (whether
> in the JSP/servlet engine or in an app server), the
> better. EJB with the
> interactions of Session beans and Entity beans
> should really further this
> along. JSPs become purely presentation vehicles;
> the task at hand is dealt
> with by Session beans and their interactions with
> Entity beans. By
> encapsulating functionality at the app server, you
> can reuse your beans in
> other presentation mediums (for our situation, we
> are using Java Plugin
> applets alongside our JSPs for more complex UIs, and
> the Voyager 3.1 ORB
> allows us to communciate with COM/DCOM applications,
> dare I say it).
>
> Overall, I've been very, very pleased with the JSP
> 1.0 implementation (in
> particular Live Software's JRun implementation).
>
>
> -- chris --
>
>
>
> > -----Original Message-----
> > From: A mailing list about Java Server Pages
> specification and reference
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> Frank Starsinic
> > Sent: Thursday, August 12, 1999 3:10 PM
> > To: [EMAIL PROTECTED]
> > Subject: JSP Techniques for limiting java within
> the JSP (tms)
> >
> >
> > One issue that keeps coming up is the combination
> of java code
> > and HTML being
> > put in the same
> > place, i..e., the JSP page.
> >
> > What techniques are people using to limit the
> amount of java within a JSP.
> >
> > I realize that the use of the Bean can do just
> that; allowing the use of
> > <%=bean.getValue()%>
> > That is clear.
> >
> > What are other techniques that are being used to
> help the JSP
> > developer not
> > worry about the back end. Are Beans being
> designed in a
> > particular way to
> > make it easier for the JSP developer. It seems
> they could be and
> > i'm wondering
> > about any good rules of thumb, etc.
> >
> > Looping thru a vector of objects and then
> hashtables of stuff within each
> > object, and having to turn it all into strings and
> pump it all
> > thru html etc.
> > can require a lot of java withing a JSP page. This
> is what i'd
> > like to prevent
> > if possible. What are other people doing here?
> >
> > We do Swing development and very little Web
> development right now
> > and it seems
> > to me that our Beans could/should be designed a
> bit differently
> > if we were to
> > use JSP, for instance, having all the getters
> return strings (to
> > keep the JSP
> > developer from having to convert everything to
> strings before
> > displaying them
> > on a web page, hence, cutting down on java code in
> the JSP)
> >
> > I hope this is somewhat clear...
> >
> > thanks,
> > frank
> >
> >
> > Craig McClanahan wrote:
> >
> > > Several people have asked questions about
> writing internationalized apps
> > > with JSP. Having just done so (only with
> Western European languages so
> > > far), I have learned some things that may be
> interesting to others in
> > > the same situation. The basic components of my
> approach were as
> > > follows:
> > >
> > > (1) All internationalized strings are stored in
> resource bundles
> > >
> > > I used property resource files named
> Resources.properties (the default
> > > translation, which was English), and
> Resources_xx.properties (where "xx"
> > > is the ISO code of the language), following the
> ResourceBundle naming
> > > conventions. I heavily used the parameter
> replacement features like {0}
> > > to synthesize internationalized messages that
> contained elements that
> > > originated in the database.
> > >
> > > (2) Accessing the resource bundles from the web
> application
> > >
> > > I created a JavaBean called "BundleBean" that
> had a series of methods
> > > with calling sequences like this:
> > >
> > > String message =
> bundleBean.getMessage(locale, "label.username");
> > >
> > > and it looked in the correct resource bundle for
> the language of this
> > > locale. The bundle bean is stored in the
> application context in a
> > > startup servlet, by calling:
> > >
> > >
> getServletContext().setAttribute("bundleBean",
> bundleBean);
> > >
> > > to make it available to both servlets and JSP
> pages.
> > >
> > > (3) Internationalize the business logic
> > >
> > > We had to deal with things like the fact that
> many European cities have
> > > different names in different languages, so our
> business object for a
> > > city has two different property getters for the
> name:
> > >
> > > String getName() returns the name in the
> language of the default
> > > Locale
> > > String getName(Locale locale) returns the
> name in the language of
> > > the
> > > specified Locale, if it is different, or
> in the "canonical"
> > > language.
> > >
> > > (4) Store a Locale object for the user's
> preferrred language in the
> > > user's session
> > >
> > > When a user logs on, one of the things we know
> is their preferred
> > > language (they can switch later, if they want).
> To record that
>
=== message truncated ===
_________________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
