Two Laptop Bag*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: Create, delete, and read in GUI Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: Create, delete, and read in GUI" Watch "NX: Create, delete, and read in GUI" New topic
Author

NX: Create, delete, and read in GUI

Jim Thompson
Greenhorn

Joined: Oct 02, 2003
Posts: 14
My requirements, for URLBird, for the User interface, just mention the search and booking a selected record. Does this mean I do not add read, create, and delete in the GUI, and just create those functions for possible future use? I will use read for the update function, but not use the create and delete in my project.
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
Hi Jim,
My requirements, for URLBird, for the User interface, just mention the search and booking a selected record. Does this mean I do not add read, create, and delete in the GUI, and just create those functions for possible future use?

YES. My GUI contains only 2 buttons, for search and book.
I even do not provide the user those "not being used" buttons.

I will use read for the update function, but not use the create and delete in my project.

I guess we need to implement all functions that declare in the interface that provided by SUN, even though those functions are not being called.
Nick.


SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Xie Ruchang
Ranch Hand

Joined: Dec 25, 2003
Posts: 160
Hi,
I have on top of [Search] and [Book] buttons, a [Unbook] button in case customer cancel booking over the phone or CSR book wrongly. The argument against this approach is what happens if another CSR deliberately unbook a booking and give it to another? Since there is no security, this feature is given and used based on TRUST.
The nice thing about this feature is that you can test the program easily by booking and unbooking with searching.
Best Regards
Jim Thompson
Greenhorn

Joined: Oct 02, 2003
Posts: 14
Thanks
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Frankie,
I have on top of [Search] and [Book] buttons, a [Unbook] button in case customer cancel booking over the phone or CSR book wrongly. The argument against this approach is what happens if another CSR deliberately unbook a booking and give it to another? Since there is no security, this feature is given and used based on TRUST.
The nice thing about this feature is that you can test the program easily by booking and unbooking with searching.

As you say, your Unbook solution has pros and cons, and because of the latter you could loose points IMO.
So what about an "Undo" feature instead ? If you hide your "Unbook" button, keep the unbook code and maintain a stack of the last bookings client-side, I think you can implement an Edit|Undo command very easily.
Best,
Phil.
Xie Ruchang
Ranch Hand

Joined: Dec 25, 2003
Posts: 160
From the perspective of GUI Design, undo is only for those operations that are not persistent. After booking, database has been changed, there shouldn't be an undo function. The ACID principle tells us that a transaction has to be durable, cannot undo. It is a good design before committing the booking to the database to ask the user for confirmation.
Whether have unbook function or not, the same inherent problem of security exists, so that is not the issue and I don't think marks will be deducted IMO.
Usually, in Use Case Analysis, when we describe "Book Accomodation" use case, it can includes CRUD. (Create, Replace, Update and Delete). So I think I can adequate justify my decision.
Regards
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Frankie,
From the perspective of GUI Design, undo is only for those operations that are not persistent. After booking, database has been changed, there shouldn't be an undo function. The ACID principle tells us that a transaction has to be durable, cannot undo. It is a good design before committing the booking to the database to ask the user for confirmation.

The most important thing with GUI Design (and it goes over all GUI design principles IMO) is ... giving the user the best possible experience (in on other words make a user-friendly GUI).
The problems with confirmation message boxes are that
  • they make user's work slow
  • they are inefficient


  • Slow, because they force the user to confirm all operations, even the correct ones.
    Inefficient, because after 2 days working fulltime, an average CSR will even not read the message box anymore : he will just press "Enter" or click on "Yes".
    But anyway, Frankie, what are the differences between "Unbook" and "Undo" after all ?
    Unbook is an *additional functionality*. Your client didn't ask for it and may accept it or ... not. And in this context, the fact that a CSR is able to cancel bookings made by another CSR is probably a feature.
    Undo is *an additional feature of an existing functionality*. It's just another way to provide the "Book" functionality, without the need of a confirmation message box and with enhanced security (against mistakes which can be corrected).
    Regards,
    Phil.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: NX: Create, delete, and read in GUI