This argument does not hold much strength. I am a GUI designer and you would
load up all icons you might be asked to use in one batch (or subsequent
updates if necessary). You could identify each icon as a *String* that is
passed over. You should be able to recreate state from a small amount of
information as possible (bandwidth protectors kept happy).
-----Original Message-----
From: Louth, William (Exchange) [mailto:[EMAIL PROTECTED]]
Sent: 27 April 2000 04:53
To: [EMAIL PROTECTED]
Subject: Re: Cached Rowsets-do we need to use them
To Richard and Chris,
I do recognize your concerns regarding bandwidth especially when sending
alot of extra data not required. But please consider that the client (UI)
designer might not be the same guy designing the session bean interface. The
client designer might decide that to better help the user he will add icons
to the list to aid selection visually. The determination of the icon for
each cell item will require the client (or some framework) to inspect other
properties of the object in question. This inspection could possibly change
throughout the products development as the UI designer strives to increase
the usuability of the client. With this in mind you can see why it is not
ideal that we send strings as representations of the user's conceptual model
to the client.
I do recognize Strings are fully feldged objects but lets be honest we are
diluting the OO model - thus my concern. I want to build clients that are
powerful, of high usuability and at the same time thin. To achieve this
requires the client to treat every object as an user object which has
certain charcateristics. Using this construct we can build a interface (i.e.
browser, list component) which can interact with many different types of
objects as render them in a consistent manner throughout the interface.
Using the String solution leads to duplication of repetitive code through
the client which could possibly be inconsistent - their goes the usuability
and most likely the project/product.
"If a systems one-on-one [user-computer] interaction with its human is not
pleasant and facile, the resulting deficiency will poison the performance of
the entire system, however fine that system might be in its other aspects."
- Jef Raskin , The Humane Interface (Great Book - I highly recommend it)
[richard] In the case of listing behavior it makes sense to present lists of
data as lists and not graphs of domain objects.
[chris] However the problem is that without a "value holder" approach you
end up serializing a lot of extra stuff to the client.
[william] The Detail object normally does not send the whole object graph. I
try to just package the simple fields and leave collections to other
operations. This is a trade-off which we both recognize has to made be when
building distributed systems.
[richard] Send over an array of detail objects or a serializable
implementation of a ResultSet.
[william] I think we are agreeing some what here apart from I do like the
ResultSet concept since its origins stem from relational database
technology. There is others ways to interact with user objects instead of
through some table like interface - you are flatening the structure.
[richard] This is far easier for the client to work with then a complex
graph of Employee objects with lots of superfluous information (information
not specific to my current needs).
[william] This is the point that I am attempting to raise above. I hate to
say this but change is constant.
[richard] Objects do not always represent business concepts, in fact objects
usally represent more utilitarian concepts like String, Socket, and
TextArea.
[william] I think you know what I meant. If we do flatten the structure and
send it over the wire this then requires the client to to build around this
structure a more user aligned object. This results in more work and a fatter
client. I thould point out that normally I try to get my session beans to
call getDetails() or something like this on my entity beans so to me making
a resultset is flattening.
[richard] OO representations of Lists are OO at its finest because these
constructs make it easier for programmers to work with the data.
[william] The Java Collections is a nice OO framework but my point is not to
de-objectfy (if there is such a word) my data and behavior constructs. An
example would be converting a List interface to a plain array. We lose
something here...agree?
[richard] Another point was made that its wasteful to convert information
from objects to lists. This seems like an odd point since the data is
accessed (in most cases involving lists) directly from the database which is
usually relational.
[william] I think the point was made with regard to converting the
properties of an object into an array of strings.
[richard] This idea that good OO requires all business data to be housed in
business objects at every tier is misguided.
[william] Its strange that we move from the database to entity bean/session
bean (more OO like) and then to table of strings. To me it would seem that
the closer the data gets to the user the more OO like it would appear. Maybe
this is because of the constraints placed on us by GUI frameworks.
[richard] The point is, you give the client what it wants - nothing more and
nothing less. Don't force the client applications to deal with graphs of
domain objects simply because it ideologically more conformable.
[william] "I want more of this and less of that" - agreed. Its the
determination of the more and less thats so tricky and requires proper task
analysis which is sometimes ignored in favour of just wrapping around some
database. I believe we can give more and achieve the less at the same time.
[richard] Enterprise JavaBeans provides an objectified view of the an
enterprise system.
[william] Then why de-objectify? I think our apparent differences stem from
what we consider what the client framework should be like. I try to build an
underlying OO framework directly beneath the client UI components to achieve
my goal of creating a great OOUI. This can be achived through your methods
but I have found this to be more work and more open to interface bugs. This
is my experience maybe others have found all this part quite difficult and
approached it differently.
I will admit that my method does require more design upfront but then again
I try to attempt to spend my time designing and less building. Also what I
propose is geared towards the user interfaces I build others building more
primitive interfaces would mostly benefit more from your solution. This all
comes down what type of system your building for now and then and that where
us architects come in and perform are magic (designing with trade-off).
"There is no progress without struggle" - Fredrick Douglas
[richard] Lets use good OO practices where appreciate but not at the expense
of performance and simplicity.
[chris] Good OO" has to be balanced with pragmatism when the distributed
nature of these environments is taken into consideration.
[william] Yes, I am always battling with these issues constantly. What I try
to do is start with the ideal solution solution and then perform devils
advocate on it with regard to these constraints. I am a logical designer who
is a reluctant physical designer.
[chris] When the "network really Is the computer" this may change. But we
ain't there yet! Are the bandwidth guys listening? ;-)
[william] I await.
I think this is my email qouta for today...bye.
William Louth
"Nothing is more impossible that to write a book that wins every readers
approval" - Miguel de Cervantes
> -----Original Message-----
> From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, April 26, 2000 11:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Cached Rowsets-do we need to use them
>
> William,
>
> I would like to address the circumstances under which the client requires
> a list
> of data; data that is conceptually organized in a table format. This is
> not
> intended to be take personally, it simply a response to your post.
>
> In the case of listing behavior it makes sense to present lists of data as
> lists
> and not graphs of domain objects. The reason is quite simple, you
> eliminate all
> the overhead associated with accessing complex object graphs on the
> client. If,
> for example, a client wants a list of all the employees and their current
> salaries then that is exactly what should be delivered to the client.
> Send over
> an array of detail objects or a serializable implementation of a
> ResultSet.
> This is far easier for the client to work with then a complex graph of
> Employee
> objects with lots of superfluous information (information not specific to
> my
> current needs). Personally I like the use of serializable ResultSet
> object
> because the the object manages the data and the list itself.
>
> To say that a list of data, whether its an array of detail objects or a
> serializable ResultSet, is not OO certainly seems indicative of a
> misunderstanding of objects. Objects do not always represent business
> concepts,
> in fact objects usally represent more utilitarian concepts like String,
> Socket,
> and TextArea. The idea behind OO is two fold: (1) It provides simple
> unified
> interface to data and behavior; (2) It provides more flexibility and
> extensibility to systems. The first point is particularly important in
> this
> case. OO representations of Lists are OO at its finest because these
> constructs
> make it easier for programmers to work with the data.
>
> Another point was made that its wasteful to convert information from
> objects to
> lists. This seems like an odd point since the data is accessed (in most
> cases
> involving lists) directly from the database which is usually relational.
> I
> would say that its more wasteful to covert relational data into domain
> objects
> just so that it can be presented in a tabular format on the client. This
> idea
> that good OO requires all business data to be housed in business objects
> at
> every tier is misguided. Data is data and If I want my data in a list
> then
> that's how I should get it. If I need more complex behavior or
> relationships
> then I'll model it as business objects with a complex graph. The point
> is, you
> give the client what it wants - nothing more and nothing less. Don't
> force the
> client applications to deal with graphs of domain objects simply because
> it
> ideologically more conformable.
>
> Enterprise JavaBeans provides an objectified view of the an enterprise
> system.
> It allows us to model business concepts and provide a component model that
> can
> assembled, reused, and re-assembled into new solutions while maintain
> transaction and security control. In short it makes it simpler to
> assemble
> solutions from existing components. While EJB, like MTS and CORBA is
> objectified these are certainly not your father's objects. They are
> distributed
> server side components and the paradigm that they live in is different
> from
> traditional OO. Lets use good OO practices where appreciate but not at
> the
> expense of performance and simplicity.
>
> Richard
>
> "Louth, William (Exchange)" wrote:
>
> > Hi Sesh,
> >
> > Personally I do not believe in database-like view of the world that is
> > constantly being advocated in list and tabular server operations. What
> you
> > typically see is an collection of objects on the server side being
> > transformed into an array x array of strings before transmitting to
> client.
> > What happen to OO? I prefer to send my domain objects (State or Details
> > objects, whatever you call them) to the client and rely on an good OOUI
> to
> > solve the problem of mapping each object into what component it needs to
> be
> > displayed in. I have an article coming up in JavaReport detailing how to
> > better solve this great divide titled "Bridging the gap between Java
> Clients
> > and Enterprise Java Beans using XML". To me OO concepts should be
> brought
> > more and more into the design of client interfaces - please do not reply
> > regarding widgets.
> >
> > kind regards
> >
> > William Louth
> >
> > > -----Original Message-----
> > > From: Sesh Kumar Jalagam [SMTP:[EMAIL PROTECTED]]
> > > Sent: Wednesday, April 26, 2000 6:28 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Cached Rowsets-do we need to use them
> > >
> > > Hai how is every one listing the data from the entitybeans. Does any
> one
> > > use Cachedrowsets. I tried to use them but I was only able to use them
> > > with BMP's . I couldn't find any way to convert an Enumeration to
> > > CachedRowset.
> > >
> > > The method i am following to list the data to the users is by
> collection
> > > of immutable objects (JavaBeans. with only getter fields).Are there
> any
> > > other better ways to do this (
> > > <http://www.ejbnow.com/ejbtips/ejbtip_4.html)>
> > >
> > > I want to know how others are doing this
> > > Thank you
> > > Sesh
> >
> > ***********************************************************************
> > Bear Stearns is not responsible for any recommendation, solicitation,
> > offer or agreement or any information about any transaction, customer
> > account or account activity contained in this communication.
> > ***********************************************************************
> >
> >
> ==========================================================================
> =
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
> --
> Richard Monson-Haefel
> Author of Enterprise JavaBeans, 2nd Edition
> Published by O'Reilly & Associates
> http://www.EjbNow.com
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
***
This e-mail is intended only for the addressee. This e-mail and any files transmitted
with it may contain confidential or privileged information. If you are not the named
addressee or the person responsible for delivering the message to the named addressee,
please contact [EMAIL PROTECTED]
This e-mail has been scanned by MIMEsweeper.
Visit the Prebon Yamane web site at http://www.prebon.com
***
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
