It may have been mentioned here before, but O'Reilly has put out a book on
EJB. Richard Monson-Haefel authored it and it's a good read (as are most
O'Reilly books).
Just a thought.
-- chris --
> -----Original Message-----
> From: A mailing list about Java Server Pages specification and reference
> [mailto:[EMAIL PROTECTED]]On Behalf Of Pankaj Malviya
> Sent: Friday, August 13, 1999 3:03 AM
> To: [EMAIL PROTECTED]
> Subject: Questions on JSP Techniques for limiting java within the JSP
> (tms)
>
>
> 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".
>
===========================================================================
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".
