Pankaj,
Regarding your doubts....
> -----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.
Someone else remarked about having beans generate HTML. I see the utility
in this, but I personally am going to avoid its use. What if I want to use
XML with XSL, or whatever the stylesheet standard will be? The HTML
generator bean won't do much good now. I think its safe to say that JSP
will be intimately tied to XML (I know that the JRun implementation already
uses XML tools heavily). I also do a lot with transforming business objects
into Javascript objects and collections.
> 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.
Currently I use our app server in the following way: I locate the servant
which handles all the requests for persistent business objects. The
servant, lets call it DBServant, encapsulates the functionality of
externalizing and internalizing business objects. For our situation, we're
using Objectmattter's VBSF 2.03, but I've also used Watershed Technologies'
Relational Object Framework with similar success. These two tools map
relational tables, subset of tables, and supersets of two or more tables to
Java objects. Now, if one wants to do some sort of object caching within
the DBServant, that requirement can be satisfied through the use of these OR
mapping tools (to varying degrees). I'm fairly sure there are other OR
mapping tools that do this same sort of thing.
When I locate an object, I'm locating the service object, DBServant, which
handles the business object externalization and internalization. I don't
currently locate each business object on the ORB. My DBServant is acting
much the same as an EJB home interface. I believe that in EJB, you locate
the busines object container first before locating the actual business
object (the EntityBean or SessionBean). I keep a reference to the DBServant
in a session lifecycled JSP bean, so I'm not locating it everytime I want to
use it. Note that this situation of every session keeping a reference to
the DBServant may change in the future to some sort of DBServant reference
pooling.
I originally thought that I would take a significant performance hit using
the ORB. In reality, the only real perceivable performance hit is the
initial lookup of the servant. For our situation, the performance
degradation that we seen is satisfactory to us, as we need the flexibility
of accessing our business logic from other presentation vehicles besides JSP
and servlets. If there's one thing you can count on, it's that your UI will
change over time. The UI is a **paper cup**, so make it easy to change
without rippling changes through the rest of your applications dependent on
shared business logic. We'll see how all this turns out; it seems like
we're always learning ways to do things better and this project is no
exception.
Hope this helps.
-- chris --
>
> 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".
