• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Suggestions on collections...

 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I need a state class to map the different states in my application. Each state would have a set of (predefined) sub- states associated with it and each of these sub-states would have couple of attributes.
As we proceed forward thru each state, the previous state's information (ie, sub-states & its attributes) would need to be carried along with the current state information.
Currently I'm using a round-about way which I'm not satisfied with...
Jim / others, Can I have some suggestion on how this collection can be designed.... Thanks in advance.
 
Ranch Hand
Posts: 1953
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You probably need give an example to describe how you system works. It would help others to understand your problem.
Generally, if you want to remember the history of your system for undo/redo reasons, command design pattern might help. If states are all you need, state design pattern might help. If all your substates have many specific attributes, I've a doubt: "Are they really states?" Maybe, I really did not get your problem. Sorry!
Roseanne
 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, a good place for you to start further thinking would
be the State pattern in the GoF book.
 
Shankar Ganesh
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is a workflow system with the requests having a set of states. In each state, the user (with proper authority) is taken thruough a set of screens (wizards), which make the substates (mandatory for the request to pass thru to be promoted). Each of these substates have a set of attributes. Apart from these mandatory substates, user can access all the information entered in each of the substates the request has passed so far in its life time -- this may be for View / Edit.
Users playing a particular role (applicable to the current lifecycle state of the request), can alone add / modify content to the request and promote or demote it. All other users would have just view access to the request.
Once a particular information is added to the request, it is accessible (view / edit based on role & state) to everyone.
There are 3 ways for the user to update the database with the changes done in the current state -- Save the changes & leave the request in the current state, Save changes & promote to successive state or save changes (Rejection details) and demote to previous state. Until one of this event occurs, all changes done to the request should be captured & retained in the session.
Thus whichever state the request is currently in, it should know the substates related to the current state (they are mandatory for promotion) and also all the substates so far passed by the request. User can navigate between these substates in any sequence.
Hope this gives a clear picture -- please let me know if more info is required.
 
Roseanne Zhang
Ranch Hand
Posts: 1953
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Since I don't know why you designed this way, it is hard to make recommendations.
Just add some experiences in a kind of similar situation, it might give you some very different views.
I've done many-many wizards on my pre-pre-job, sounds like centuries ago, actually only before Feb. 2000. The standard (well, kind of ) way to design wizard is making it modal, checking each step to promote to the next step, don't save anything until the wizard is total finished. Otherwise, it is aborted. Therefore, you only need keep the information inside your wizard. No complicated states are required.
This is obviously not what in your mind. However, it might give you another viewpoint. You might ask yourself or your boss a question: "Is your design overly complicated?". I'm a big believer of KISS (Keep It Simple and Stupid/Straight forward).
Just some thought. It might not be useful for you.
Roseanne
[This message has been edited by Roseanne Zhang (edited December 28, 2000).]
 
Ranch Hand
Posts: 243
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

hey gurus, I am not clear at all.
Tell me more about the different design patterns and this GoF book
 
Roseanne Zhang
Ranch Hand
Posts: 1953
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here linked 2 free design pattern books and both are easier to read than GoF book and in Java. Good places to start:
http://members.spree.com/education/developergrp/FreeBooks.HTM
Roseanne
 
Shankar Ganesh
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the responses, Roseanne.

Originally posted by Roseanne Zhang:
Since I don't know why you designed this way, it is hard to make recommendations.
Just add some experiences in a kind of similar situation, it might give you some very different views.
I've done many-many wizards on my pre-pre-job, sounds like centuries ago, actually only before Feb. 2000. The standard (well, kind of ) way to design wizard is making it modal, checking each step to promote to the next step, don't save anything until the wizard is total finished. Otherwise, it is aborted. Therefore, you only need keep the information inside your wizard. No complicated states are required.
This is obviously not what in your mind. However, it might give you another viewpoint. You might ask yourself or your boss a question: "Is your design overly complicated?". I'm a big believer of KISS (Keep It Simple and Stupid/Straight forward).
Just some thought. It might not be useful for you.
Roseanne
[This message has been edited by Roseanne Zhang (edited December 28, 2000).]


 
mohit joshi
Ranch Hand
Posts: 243
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Roseanne , you are really helpful.
What is this Gof book every one is talking about?
 
Roseanne Zhang
Ranch Hand
Posts: 1953
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Design Patterns
by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

 
reply
    Bookmark Topic Watch Topic
  • New Topic