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".
