NeoSoft's Detail Tab Pattern
Typically entering and submitting a very large number of records through a web form can be very time consuming and irritating. Typically one will use text boxes spread over a row representing each record. Now suppose your record contains 15 fields and there are 1000 records to be entered through the web form under consideration. There will be 15000 + text boxes to be submitted in one web request. If there are any validations involved (which usually are), you can just imagine the amount of time it will take to submit. In our case with the above arragement it was not possible to submit more than 150 records. The system was simply taking too much time and some times crashing.
We then decided to use only 15 text boxes (one for each field in the record) as centralized entry point in the form. By suitable java scripting we displayed the entered records in a HTML table. As soon as the record was entetred in HTML table, it was entered in a list box (hidden) as a string. In this string the individual fields were seperated by using a delimiter '<>' (any delimiter can be used here). You could select the record from the HTML table and it could be modified & copied back to the HTML table from the centralized entry point explained above. Now if typically you have 1000 record (15 fields per record) to enter, the HTML table would have 15 * 1000 = 15000 cells (1000 rows and 15 columns). In this scenerio the list box would have 1000 entries. Each string in the list box would have 15 components seperated by '<>' as described above.
Now as the request is submitted to the server only the List box described above( which is a HTML control) is submitted along with other HTML Controls (if any). The HTML table described above is for the display purpose only.
Using this arrangement, we coulld submit more than 2000 records in less than a second over the web. This typically
meets the requirements of a majority of web applications.
The advantages of what we call "Detail Tab Pattern" are
1. Lignt weight presentation tier
2. Multilingual display capability in terms of record formatting in a HTML table
3. Automation of JAVA Script work is possible if similar forms needs to be developed.
4. Obvious advantage of using a HTML table for data entry which is typically used for display purpose only.
We welcome your comments, queries and suggestions at
Nice pattern. Except that ...
Well, nobody would convince me that any user, even the data entry guys, need to display 1000 rows from a table in a single page. Simply they don't need that.
Tipically a well designed web page will display a set of 50, maximum 100 rows of data (if you display only rows from the database. You will display les then 10-15 rows if they contain images or large detailed descriptions ... ).
For a DB management solution (as the one you described, if I understood right it is used by the data entry guys) you might think of a solution to somehow group (split them in categories or even place a filter like advanced search feature of all serious search engines) the results thus limiting the number of rows in the category you want to display, and than display them in pages of maximum 50, 100 rows.
There is no need to update 1000 rows in one submit ! Update them 100 by 100. Anyways it is most safely like this. Think about a data entry guy that fills in (or updates) 1000 rows and than submits them, but unfortunately while he was filling in, your server crushed, or your ISP crushed your connection for some reason (even if only for 1 minute, hey, we are talking about the network, anything can happen, even his session can expire and if you keep login info data in session it's all lost he must relog) ! He will simply die instead of refilling all that data !
I'd say that only the guy who didn't find other solution than submiting 1000 rows at once has some design problems, or you didn't describe well the environment that forced you to do that and I got it all wrong. But for all over 20 web apps (some quite big) that I developed until now, nobody would convince me that a user (regular or admin) needs to see 1000 rows of data in one page (except if the client says 'I won't pay you if you don't do it like this', and this is all about how you manage to convince him that he's wrong without making him mad) :-).
Argh. Pretty long note. Hafta optimize my 'POST' method :-)
The problem domain you are describing (tons of data entry) is NOT THE PROBLEM SOLVED BY A WEB APP. I feel so sorry for your users, because a web-app is just the wrong solution. Give them a desktop app. Swing, for all it's faults, provides a faster, snappier, more responsive UI than any web application.
Yes Dorel ; You are right on the point that most of the web applications don't need to enter more than 50 to 100 rows at a time. but in our case which are purchase orders for an apparell industry, the users are used to enter 600 to 700 records at a time (Over old Powe Bulder Based Client server systems) and they are just not ready to enter 100 records at a time for a purchase order containing more than 1000 rows ( small items). They want same thing on a web based system also. The web based system is supposed to replace their old client server legasy system.
So after all failing in all our other efforts, we were forced to fabricate this pattern. Now the things seems to be in place and the client is happier than what he used to be.
Than you are on the right way :-) after all patterns are just patterns. And good software is allways what customer wants :-). If they are happy with the solution and they'll keep it like that for a long time, you're on the right way than
Wish ya all the best
IMHO this isn't a design pattern. It doesn't even resemble a design pattern. A GUI design "pattern" maybe :)
That doesn't mean it's not a good idea.
Well, any special construct which solves a design problem can be called a pettern in my openion. & offcourse as it deals with a GUI problem , it is a GUI pattern or presentation tier pattern as written in the title of pattern..
Well, what is or isn't a pattern depends on one's point of view. You can call just about any software design a pattern.
When I'm talking about design patterns, I'm talking about a certain POV, the one described in most design pattern books. Here is an excerpt from "Design Patterns by GOF" (IMO the definitive guide):
"Point of view affects one's interpretation of what is and isn't a pattern... The design patterns in this book are *descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context*."
it is a hack to get around a bad architectural decision. The problem being solved should not have been done with a web-app.
I believe that this is a good solution for the problem at hand given the client's stipulation that they would rather lose 900 entries when either the server or the client goes down than entering a reasonable amount of records (100 for example) at a time.
This implementation (using hidden fields) was suggested in http://www.webmonkey.com
OK Guys, We wouldn't call it a pattern any more ...But can't we appreciate the fact using this solution it is possible to enter a very large number of records through a normal JSP page which other-wise not possible.
Any comments ?
I amazed how u can call this a pattern.The correct name , for ur solution is Idiom or specific design.
Its can not be called as a standard design r a design pattern.
Anyhow its a good solution for the specific problem u faced.
Becasue client requirmnets will be so stupid that we cant do anything except find an intelligent solution for a problem.
Here I wonder the most, why we are getting too much in to whether it can be called a pattern or not. For me its very-very secondary. Why can't we just discuss the merits and demerits of this generalized solution ( as it appears to me atleast) which is enabling us to enter a large number of records through a normal JSP (Here I repeat). I am not interested in calling it as a pattern. I am just interested to know whether you can use this construct in your projects ( offcource if you face this situstion) and get benifited by it. Does it not one more tool in in your solutions armary to tackle client's problems ?
Will be sincerely interested in your feedback on this..
Thanks to ypu Gal for that reference..
it is a hack to get around a bad architectural decision.
Dave, do you work in research or sumthin ? How many customers did you turn off when they sugested "a bad architectural decision" ? I suppose none. Because when the client said web (Shailendra said: "They want same thing on a web based system also") and said I give you money for that, You don't say "Go to hell, it's a bad arch decision". Also Shailendra said that they did they could to avoid this but the client insisted. So here ya go: you make it web. If you are good, you'll make it good. No mater what it takes.
I repeat, software development isn't all the time "Pure and evolved technologies". Or what you think it is. It is the art of satisfying customer needs first.
Btw, how mwny customers told you dave: "gee you used half of gof patterns here, you're really good !" ,instead of "I want when you click here to display this message, I want that picture on the first page, and please bold that title".
Nothing personal :-). Just don't be that categoric on "hacks around bad decisions". Think from all points of view.
And Gal, I joined recently this J2EE community and I read ALL the patterns posted here, and there are tons of things that can't be called patterns in your terms of speaking :-)). But stil they are in the patterns section and 95% are usefull. which is a hell good percent and here I thank TSS and especialy to Floyd Marinescu for what he's done for the J2EE community
I've been a member of the TSS community for many years, and my criticism is not something new or specific to this pattern. I think that indeed most (I wouldn't say 95%) of the patterns on TSS are:
- pattern usecase scenarios
- pattern combinations
- pattern contexts
- pattern implementations
- specific algorithms
That doesn't mean that they are not usefull. They are usefull, but they are badly categorized and described in the wrong context and as a result they don't follow any of the standard design pattern form which makes them hard to read and evaluate. Many also offer incorrect implementations using deprecated idioms (double-checked locking, assumption of commit option A in entities, etc).
Please see this related discussion
You are right indeed on that, thanks for redirecction to "Improvements to Patterns section". The first time I entered on the TSS I was amazed about the abubdance of "patterns".
I couldn't believe that actually there could be so many "patterns" and I never heard about them. You are right about it and I think that what you've said would greatly improve the quality of the material posted there, and would help newbies to exactly understand what they can find there (and not only them).
Now that I read the thread you started I remember my first thought when I entered the Patterns section: "Where the hell did these patterns came from ? And, hack, they are many !" As I read along it became clearly that many of them were solutions in specific situations and as you pointed out "pattern" means a little more than that.
I am no expert on GUI patterns or Java Script, But....
- Why a list box. You could simply use a hidden field instead.
<input type="hidden" name="somename">
- You don't even need 15 edit boxes. Use a single edit box and populate the grid cell with it when it gets focus. All non browser grids are designed to work like this.
- What happens if the user enters 200 records and his machine crashes or there is a power failure. Does he have to enter the 200 records again?
As soon as the record was entetred in HTML table, it was entered in a list box (hidden) as a string.
BTW, How will u make a list box hidden in HTML?? I believe u mean "<select> with <options>" as ListBox..
Otherwise, u mean an array of "hidden input" as Hidden List box???
Dear J Virumbi,
i am posting a code snippet from my JSP which will answer queston; " How to make list box hidden in HTML ?"
<div id="details" style="visibility: hidden; position: absolute; z-index: 2; width: 600; height: 100; left: 21; top: 650 ; overflow:auto ">
<select name="alertList" MULTIPLE size="25"></select><br>
Hope it is useful.
does the html snippet you presented works in Netscape?
For all practical purposes it works in Netscape but the results are not exactly same as in IE..We are using it in production environment in Netscape
As a workaround it's fine, but there is something fundamentally wrong with the way you guys perform requirements gathering and analysis. Your role of the software engineer is not just to blindly implement what the customer "wants" - because sometimes customers have no clue about what implications their wishes/requirements may have when literally taken. You also have to advise them on what is appropriate in a given context and what really gets the job done, what brings the benefit to their business.
To illustrate the point: With 99.9% system availability (which is very hard to achieve) you can count on 2 hours of system downtime per year, during business hours. You can also calculate average number of incidents - connection losses, system crashes, etc. given the reliability of the whole system - workstations included. Each incident costs you a couple hundred entries in your scenario...
But what really blows my mind is the abuse of the list control hidden form fields have been around forever, and you simply cannot convince me that it can be more efficient to create a list box hidden using CSS attributes, populate it item by item than simply edit an array of strings, which is then packed into a delimited string value of the hidden form field and submitted to the server.
We did such stuff four years ago - but we never entered more than 50 items at a time - in elections business, and firm deadlines for publication of election results, you cannot afford to loose and reenter 300 records every now and then. This is especially important when you need to minimize the human error (which is typically 2%-5%), so you enforce double entry of each record by two different people!
I sincerely recommend you bring your data entry app back to drawing board, and explain the risks to the customer in detail.
Thanks For Your Comments, But I don't think there was any option available for me. I will be grateful to you if you can suggest a couple of viable options; we have to basically mimmick an old client-server application
Here client should be capable of entering multiple records without hitting server, or otherwise fix entry to some 5 or six records.
We developed a Grid like user interface using
1. Html select for grid
2. Any HTML input for data entry
3. Add, edit and delete button for record manipulation.
+--------+ +--------+ +----------+ +----------+
| <TEXT> | | <TEXT> | | <LIST> |V| | Add |
+--------+ +--------+ +----------+ +----------+
| | | Edit |
| | | Delete |
As I was new entrant to JSP, we made a quick hack to get this done, without using taglibs. We used jsp include and build the appropriate grid with some basic valdiation.
But this grid could have been done in a better fashion using taglib, like what is done in struts html forms.
If any one interested in developing it please contact me.
Missed the first para :)
Though dumping thousands of records at a time is a bad idea, part of the solution can be used to develop a new HTML component. We were developing a product, where user might be typing multiple detail records for a master record, eg: multiple ticket details in a single travel.
Can you give a bit more detail.
I need to have soemhting of this kind in our ourchase order module.
Even if the form has less than 300 cells in total, how to ensure any changes can be quickly done without coding. For example, what if a column or a bunch of rows have to be inserted, based on updated fields in a database, with validations, etc. Is there a pattern that considers forms that change fairly frequently?
We are maintaining a system currently that has too much hard coded stuff.
Any comments/pointers would be of great help.
As an alternative to using a very large web form to upload data, an Excel spreadsheet could be used for data entry. All validation would occur at the spreadsheet level (layer) and then uploaded to the server using a file upload form.
The Excel file could then be parsed (in memory) by extracting the data using Jakartas POI and then persisted to your underlying data store.
something I came across this.
I don't care if it is a pattern or not but my client
wants something like this. To enter at least 150 rows,(meaning I need to support at least 300) in a table.
each column is list or text field or a button. Also
depending on data entered, I need to 'show' sub-table as
master detail,meaning a row in a table could be either
a header of of sub-table displayed right shifted or the
row could be regular row. I have at least 15 columns.
can you post your screen shot somewhere so that I can
or anyone else interested, see what kind of screen you have?
also excel solution is not for me.
any help will be really appreciated.
I have a typical master detail type of screen. In which for a header record, we enter n number of rows in detail. As you can make out from the write up of this design , the detail part constructs of a html table supported by a list box. We have more than 20 columns in the detail part. It will not be posible for me to post the screen shot on the net. But for any help you can write me on
shailendrakadre at hotmail dot com ...If you are situated in Bangalore, I will be more than happy to see you.
I will contact you, I was on vacation for last couple of
weeks. i am not in bangalore.
design pattern ?
what design pattern .. guys ..
dont get me wrong .. please think about the approach, if your client is happy about you guys doing so
somethin is serrrrrrrrrrrioulsy misused here ..
dont tell anyone like .. he wanted this so we gave them this.. thats not providing a solution...
list box .. hmm wonder what happen to hidden params ..
div tags .. hmmm .. keep it simple guys .. KISS is always good :)
and why on earth would some one want to enter 500 records and save them at one go .. does all those 500 records related to each other .. wont the DB accept them if one by one is entered ..
Cant you guys submit things behind the scenes ? does the user always have to submit it for you ? after filling 500 records ?
Lots of options are available for you to make this thingy a simple nice easy to maintain one ..
An year from now .. some one will be maintaining your app .. dont make him curse you every single time he opens you code for him to debug ..
Just my 2cents
We had a similar requirement,
we used a light-weight Applet for allowing this kind of data entry. The UI was neat and easily done.
For pure display purposes we sticked with HTML only, but this kind of data-entry was best handled with applet.
And our client was happy working with it, given the fact that entering lots of data was very fast because of Applet UI.
How many rows/ records at a time you posted from a UI and how much was the typical transaction turn around time ? What was the type of application; Here I mean the domain ? Was your client based in hong kong, korea or Japan? I am asking this question because the users in these reagon typically hate to use mose and this makes UI navigation requirement further complecated as every thinhg has to be entered/ operated by tab movement only.
I agree to the argument that this is not a pattern but a solution to a specific problem.
Pattern in my view point is the best solution to a common problem. The solution should address all the issues of the problem and resolve them so that current/ future developers do not re-invent the wheel of developing a new solution.
We also had a similar requirement and we have developed a solution to handle the requirement.
The author, however failed to mention the disadvantages of this system.
1. By the time the user inputs all the 100 records, the session would have timed out. I assume that the web-application had session-timeout parameters.
2. If 99 records (out of the 100 records) pass through the Business logic successfully and the last record fails the business validation, then the transaction has to be rolled back and appropriate messages sent to the user to correct the data and this is a tedious process for the user to identify the nth row that had a specific problem and correct that. The problem is complex when 10 or more rows fail out of a set of 100 records.
3. Continuing on the above point, each record may fail for a different reason and appropriate messages have to be sent for those problems.
5. The system is not transaction-safe, since by the time user inputs 100 records, another user would have entered the same record in a different transaction and this would cause unnecessary load by submitting and throwing exceptions and the user again correcting the data and then re-submitting.
6. Also to make the list box hidden, he need not use a layer, but can simply use the css attribute style="display:none".
7. The server-side logic is also very complex since the user would have submitted records that need to be deleted, updated, inserted and records with no change at all(which were loaded from server for updates). The server-side logic has to be intelligent enough to handle this scenario.
There are lots like this which the author failed to mention.
On the whole this is not even the best solution to the given problem.
However, this is a trade-off that has to be decided by the client/user and not the developer and it is our responsibility to appraise the client/user about the systems limitations.
I fully agree to you that this construct is a solution to a specific problem. But the beauty of it is simply putting moe records through a UI which was not possible earlier (Atleast for us). Some of the limitations mentioned by you apply here but not all o f them.
1.We validate the record at the entry point itself and thus on submission no validation is required.
2. A single record is not likely to be entered by two persons as there is a lock when a particular document number is open, others can only view it.
3. We have solved all the cross browser java script issues without much difficulty.
4. The security requirements of this application are not very stringent. So we will be keeping a very long session time out (2 to 3 hrs). There will be a message before the session expires so that data can be saved. The session time out applies only when there is no request to the server for session time out period. If continuous requests are there board than the session will not expire even if he/she works for say 6 hrs. In such a scenerio a user needs to save his work & again open in edit mode to continue working.
5. The server side logic is very simillar to what you have mentioned but it is to be applied even if your application processes very less records at a time. So it is not dependent on the number of records handled at a time.
There are some more limitations & some of them may be of little cooncern too, but overall we and the customer are happy. One version of this construct has gone in to production with our client who is in to freight/ cargo business. They are ok with this solution. Five months are over since it has gone live. It has been implemented in Reservation Card transaction which is supposed to be the most crucial & most used one.
Tanks again for your analysis.