Fine. You're absolutely right about my misunderstanding you. From this
posting it appears you are condoning the use of state messages to update
other resident objects. This is where the confusion arose:
The objects you are sending represent the STATE of objects that reside on
your client. So for example you send a model for a view over the wire, (not
the view and model). This seems reasonable in terms of bandwidth. Which is
definitely offset by good OO things like type checking on the client.
-----Original Message-----
From: Louth, William (Exchange) [mailto:[EMAIL PROTECTED]]
Sent: 27 April 2000 08:30
To: [EMAIL PROTECTED]
Subject: Re: Cached Rowsets-do we need to use them
Hi Neil,
I just had to reply to this one. You are reading my posts wrongly. I am
saying _not_ to send the icon or its _name_ over the wire but send the
_simple_ object state so that the client developer can use whatever
properties he wants in determining how to render each object and your
server-side is oblivious to this.
[neil] It's inefficient, and can go out of date (try using different
versions of the jvm with this stuff and see the version issues you run
into).
[william] Sorry I am lost here. I understand the Java serialization
mechanism but do not understand how this relates to the thread. My
assumption is that the class is consistent across jvms. There are many
_technical_ ways to solve this issue.
[neil] So at every stage of your system you have objects. And all the lovely
things that objects provide. It's just you supply the object's state via the
wire not the object itself.
[william] I supply the _details_ like object (its has state) NOT just the
state embedded in some string array or compressed string or not even that
just a string. I do not mind the wire protocol flattening my objects when
transmitting this is the plumbing and its transparent to me. I do not want
my client side developers have to construct another _object_ around the
state (string array) that was constructed by the server side developer. This
seems wasteful - creating work for both side. Most client side developer
prefer to work with real user objects than just strings with attached icon
string names. The session bean should return to the client side objects that
represent the users conceptual model it does not matter that these objects
are not a mirror images of the entity bean model.
what I am advocating :
public class CustomerDetails implements java.io.Serializable {
public String getFirstName()..
public String getLastName()..
public CustomerType getCustomerType();
.....
}
CustomerDetails customer
// get first name
customer.getFirstName();
// get last name
customer.getLastName();
// get customer type
customer.getCustomerType(); // this is an object which can also have its own
rendering
....
what I think others are advocating:
String[] customer = new String[..];
// get first name
customer[0];
// get last name
customer[1];
// get customer type
customer[2]; // there is no way to render because of the de-objectifying
.....
This is like comparing RMI programming to Socket programming.
[previous post] Why not put some methods on are objects like getIcon(),
getCaption(), getEditor()?
[william] I was being _sarcastic_. This is another thing I do not want along
with the string arrays. This goes back to my statement regarding keeping the
layers relatively clean.
Tell me am I not been clear enough.
kind regards
William Louth
"Since humans are more pliable than computers, it can be easier to make a
human fit the computer's limitations than to design the computer to fit the
human's needs. When that happens, the human becomes a prisioner trapped by
the computer rather than liberated by it. "
-Karla Jennings
> -----Original Message-----
> From: Neil Thorne [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, April 27, 2000 1:24 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Cached Rowsets-do we need to use them
>
> Will. This isn't that ridiculous. Okay so what are you using to render the
> stuff on the the client. A Swing component with a renderer of some kind
> right? The client can build its renderer if it is supplied with the
> appropriate state for that renderer. (What I believe your saying is that
> you
> should send over the whole object including its icon etc.) You should just
> send what state you need and specify the minimum interface for each
> component to rebuild itself from that state. I'm definitely NOT saying
> don't
> use objects. I'm saying don't send objects *down the wire unless you
> really
> have to*. It's inefficient, and can go out of date (try using different
> versions of the jvm with this stuff and see the version issues you run
> into).
>
> So at every stage of your system you have objects. And all the lovely
> things
> that objects provide. It's just you supply the object's state via the wire
> not the object itself.
>
> -----Original Message-----
> From: Louth, William (Exchange) [mailto:[EMAIL PROTECTED]]
> Sent: 27 April 2000 06:05
> To: [EMAIL PROTECTED]
> Subject: Re: Cached Rowsets-do we need to use them
>
>
> Hi Neil,
>
> [neil] 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).
> [william] The mechanism of how to cache icons in the client memory loaded
> from some jar (I hope your not advocating sending them over the wire) has
> nothing to do with this thread. Sorry, but this is off the point and does
> not weaken my argument in anyway.
>
> [neil] 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).
> [william] I was hoping not to hear this. What you are advocating if I
> understand correctly is that your server side now determines what the so
> called name of the icon to use for the displaying of the string in the
> list.
> So now the server side must inspect the objects properties on the server
> side and determine the icon to use on a per-object basis. What happened to
> keeping each layer relatively clean of each others needs? Why not put some
> methods on are objects like getIcon(), getCaption(), getEditor()? Impure
> thoughts. Your solution brings the following passage to mind:
>
> [neil] You should be able to recreate state from a small amount of
> information as possible (bandwidth protectors kept happy).
> [william] The funny thing about this all is that in building a better
> interface more in tune with the users abilities and tasks you nearly
> always
> reduce your bandwidth (please look at my comments on the large page size
> thread). There are numerous ways to solve this bandwidth problem other
> than
> flattening our OO constructs.
>
> JavaScript, the ultimate hack
>
> In desperation, the good folks at Netscape threw together JavaScript, a
> patch necessary to keep the fledgling company and their thousands of
> drowning developers alive. What the engineers failed to realize was that
> only programmers like themselves were being thrown a life preserver; while
> the majority of their site developers slowly drowned.
>
> So what was-and is-so wrong with JavaScript, and what about it cut all but
> professionals out of the loop?
>
> The JavaScript creators had to figure out how to combine their new code
> with
> existing HTML, and they had to do it fast! As a result, they lacked the
> time
> to sit down and figure out how to extend HTML in a fundamentally new
> direction. Instead, they opted to just run the two together at high speed,
> and depend on users to understand enough about the fundamental nature of
> computer languages to figure out the bizarre result.
>
> Let's hide it!
>
> The earlier browsers were most unforgiving of new constructs popping up in
> the middle of web pages, so the JavaScript developers decided they had to
> hide the code, resulting in the greatest, most persistent hack in computer
> history. Instead of writing the code in the normal code space, they hid it
> inside the comments of the other language! Now, for those of you without
> an
> engineer's superior ability to handle illogic, this one may be a little
> hard
> to follow, so permit me a metaphor......
> -Bruce "Tog" Tognazzini
>
> I have another question how would you go about displaying a table of data
> where each cell could possibly have a icon representation. Would you send
> over a ResultSet with each cell have 2 strings one for the caption the
> other
> for the icon. Come on this is getting ridiculus.
>
> I really cannot reply anymore on this topic for now but please post your
> replies and I will take up the cause again later on (after work). My
> silence
> will not be indicative of anything.
>
> kind regards
>
> William Louth
> Inspired Consultancy
>
> > -----Original Message-----
> > From: Neil Thorne [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, April 27, 2000 11:23 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Cached Rowsets-do we need to use them
> >
> > 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".
>
>
> ***********************************************************************
> 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
> ***
***********************************************************************
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".
