Goonie
Apr 3rd, 2006, 04:04 PM
Hello everyone,
I'm trying to decide wether to rewrite an application that has become rather unmaintainable with Spring Web Flow or not, or maybe some other technique.
Could you have a look at the following descriptions? You could have a look at http://3moves.net/game/demo_game.html, so you see what I mean.
A. Consider an interface to a chess game. It is only possible to enter valid moves, by clicking on piece and target square (business logic for this is already implemented). When a move is entered, it is executed and the same user can enter the next move for the next player. In this easiest scenario, the state (Game) is only stored in the users session and is not persisted. It is just needed for entering a series of moves (e.g. opening), not for actually playing against other players.
B. Now, consider an extension to A, GUI-wise: The game history is listed on the side of the game board, allowing to select a specific move in history, or single-step forward or backward. Moves can be undone by clicking on an "undo move" link. This is a game browser/analyzer for virtual games (games not contained in the database).
C. B is extended again, this time on the backend-side: Actual games are backed by a persistant game object in the database, and users can only execute their own move. If the other player is on turn, the interface is "read-only" (history can be viewed, but no move can be entered).
D. One more extension: Multiple games of type C can be viewed and played in parallel, either in multiple browser windows (each containing one game) or by having multiple games side by side in the same window. Ideally, games are refreshed in an Ajax-style (but the business logic still resides on the server).
A, B and C is mostly implemented right now (using Spring-Web), but the codebase is getting more and more unmanagable. D is on my wishlist. Do you think SWF could be a good candidate?
I think A is easily implemented, it's very similar to the SWF sample applications.
B is getting a bit more difficult, given that I want to re-use A as much as possible. Is it possible to extend flows? Which view technique would be best to "decorate" the base board with the additional controls? Currently I use JSP with JSTL includes.
C means that I actually replace the backend, or the adapter to the backend (I'm not sure).
D: Is it possible to have multiple instances of the same flow? One problem I see is the size of the flowExecutionKeys. I simple can't affort to add something like _flowExecutionKey=_s2FDE70B3-A476-7BFB-A535-C937C28FF4E1_c9C65695B-92E8-162A-5EDF-86EDBA203C55 to each link - that'll be 3 kB overhead per page just for 30 different possible moves. Since there should not be more than one flow per actual persisted game, can I also use my own game id instead and somehow link to the corresponding flow internally? "game_id=234" has to be enough...
Many questions, can you give me some hints?
Regards,
Andreas
I'm trying to decide wether to rewrite an application that has become rather unmaintainable with Spring Web Flow or not, or maybe some other technique.
Could you have a look at the following descriptions? You could have a look at http://3moves.net/game/demo_game.html, so you see what I mean.
A. Consider an interface to a chess game. It is only possible to enter valid moves, by clicking on piece and target square (business logic for this is already implemented). When a move is entered, it is executed and the same user can enter the next move for the next player. In this easiest scenario, the state (Game) is only stored in the users session and is not persisted. It is just needed for entering a series of moves (e.g. opening), not for actually playing against other players.
B. Now, consider an extension to A, GUI-wise: The game history is listed on the side of the game board, allowing to select a specific move in history, or single-step forward or backward. Moves can be undone by clicking on an "undo move" link. This is a game browser/analyzer for virtual games (games not contained in the database).
C. B is extended again, this time on the backend-side: Actual games are backed by a persistant game object in the database, and users can only execute their own move. If the other player is on turn, the interface is "read-only" (history can be viewed, but no move can be entered).
D. One more extension: Multiple games of type C can be viewed and played in parallel, either in multiple browser windows (each containing one game) or by having multiple games side by side in the same window. Ideally, games are refreshed in an Ajax-style (but the business logic still resides on the server).
A, B and C is mostly implemented right now (using Spring-Web), but the codebase is getting more and more unmanagable. D is on my wishlist. Do you think SWF could be a good candidate?
I think A is easily implemented, it's very similar to the SWF sample applications.
B is getting a bit more difficult, given that I want to re-use A as much as possible. Is it possible to extend flows? Which view technique would be best to "decorate" the base board with the additional controls? Currently I use JSP with JSTL includes.
C means that I actually replace the backend, or the adapter to the backend (I'm not sure).
D: Is it possible to have multiple instances of the same flow? One problem I see is the size of the flowExecutionKeys. I simple can't affort to add something like _flowExecutionKey=_s2FDE70B3-A476-7BFB-A535-C937C28FF4E1_c9C65695B-92E8-162A-5EDF-86EDBA203C55 to each link - that'll be 3 kB overhead per page just for 30 different possible moves. Since there should not be more than one flow per actual persisted game, can I also use my own game id instead and somehow link to the corresponding flow internally? "game_id=234" has to be enough...
Many questions, can you give me some hints?
Regards,
Andreas