There are really a lot of things i have to consider. Especially security. Here Are Some Of The Considerations I Guess
1.) To View (Subset) Records But Not Edit Or Delete Them 2.) Users must not be able to edit reference tables. Tables that are referenced by others. 3.) Users must be able to enter transactions(Purely Insert,Transaction Recording Only) with client side validation and observance of limits and rules of course which were defined during online mode. ( Store This Queue Somewhere) I'm not reallyh sure that I want to go through with this however, this is just a prototype idea. On Sun, May 3, 2009 at 4:55 PM, Johan Compagner <jcompag...@gmail.com>wrote: > I cannot believe that a typical wicket application (and a banking app > fall under that category) does well in offline mode, to me offline > mode works if the app is just about personal data (like gmail for your > email) because if that is not the case and loads of none peronal == > shared data is used, how are you pushing that to the client? Maybe if > the data is not thah much (not very likely in a banking app if you > ask me) then you can push it to the client. But then when he gets > online again you have to merge everything and resolve conflicts in the > data... > > But wicket doesnt really play well for this at all. GWT or just > another fat client like air or just java webstart would be better > > On 03/05/2009, Carlo Camerino <cmcamer...@gmail.com> wrote: > > hmm, you have a point here.however, every requirement is different. > > > > I know that it may sound weird, but still I believe that it depends on > the > > nature of the application. > > There are lots of types of applications that banks use. > > Some I know would have to always have a central server managing it. > > > > There are different types of Technical Architectures that we cater for in > > our applications. > > There are some applicationms that always require online mode regardless > adn > > there are applications that the user just > > needs to be able to view customer information ,etc.... > > > > > > actually it's hard to decide here. > > on the downside, I heard that GWT consumes a lot of resources on the > client > > side, it's also a consideration. > > > > Failsafe servers are of course an option but again, the network is still > a > > factor here. > > For example a very slow connection to the central server makes my > > productivity a lot less. > > Some places suffer from low bandwidth, unreliable networks, etc... > > > > I saw the value of distributed or offline applications that uses > > synchronization. > > It will be harder for the developers of course sicne they have to cater > to > > two modes. > > On Sun, May 3, 2009 at 1:55 PM, Vladimir K <koval...@gmail.com> wrote: > > > >> > >> I would install failsafe cluster rather satisfying every client request > >> about > >> offline workability. You may end up implementing all the front-end and > >> middle-end features in offline mode :) > >> > >> I believe offline mode should be used with care. The email applications > >> are > >> by nature offline. If you are certain that what the user does is offline > >> by > >> nature - implement it. If you have concerns that it should be involved > >> into > >> transaction (I mean a bit wider meaning than DB transaction) - implement > >> it > >> online and think about fail-safe servers. > >> > >> Concerning front-end and middle-end, AFAIK, every unit of work is a > >> transaction which is done with multi-level authorization, including > >> business > >> authorization. You either implement all the authorization offline > >> (insecure > >> at all, and impossible in some cases) or defer authorization untill > online > >> mode (non-transactional). If a request of some client was satisfied (in > >> offline mode) and then hasn't passed online authorization (for instance > it > >> violates some limits which can be thruly calculated on the server side > >> only), you will have to call the client and tell him your appologises > (or > >> not directly you, then the bank. but the bank will then call you and > tell > >> you something awesome). > >> > >> Or just tell me the name of the bank. I will never become its client :) > >> > >> > >> Carlo Camerino wrote: > >> > > >> > it's not for the public to use. but rather for people within the > banks. > >> > internal applications. sometimes central connection is not available. > >> > > >> > On Fri, May 1, 2009 at 9:37 PM, James Carman > >> > <jcar...@carmanconsulting.com>wrote: > >> > > >> >> Are you sure a banking application would be the right place for a > >> >> gears-based implementation? Wouldn't it be kinda important to make > >> >> sure the main server knows where everything is, when money is > >> >> concerned? > >> >> > >> >> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <cmcamer...@gmail.com > > > >> >> wrote: > >> >> > Hi, > >> >> > > >> >> > Is there any project which has Wicket And Google Gears Integration? > >> >> > Wicket has really done a lot of us in speeding up development time. > >> >> Coming > >> >> > from a struts we saw the power of Wicket in terms its reusability > and > >> >> i've > >> >> > noticed that > >> >> > wicket already did most of the tasks that we would have to manually > >> >> > do > >> >> using > >> >> > struts application, like session timeouts, redirects, etc.... > >> >> > > >> >> > One of our main concerns however are that clients > >> >> > are asking for our applications to be available even if the network > >> >> > is > >> >> down > >> >> > or if the central server is down.. > >> >> > Currently we implemented our applications in a distributed fashion > >> >> wherein > >> >> > every branch ( Remote Location) has its own server. > >> >> > However, this has implications of cost and administration issues. > >> >> > However, if offline mode is enabled we can just begin syncing > right. > >> >> > > >> >> > I think that Wicket WIth Google Gears Application will make it even > >> >> better . > >> >> > > >> >> > > >> >> > I think this is really a plus when it comes to marketing it to > >> >> customers. > >> >> > Most of the applications that we create our banking applications > and > >> >> any > >> >> > downtime is costing our clients. > >> >> > > >> >> > Hopefully we can also do this to offload the central servers and to > >> put > >> >> > processing into client machines. > >> >> > > >> >> > One large problem I see though is that most code wil have to be > moved > >> >> to > >> >> the > >> >> > Browser Layer. > >> >> > I'm thinking of how to create a wicket application which is mostly > >> >> > run > >> >> by > >> >> > java classes work on the client side. > >> >> > Looks as if there will be a lot of code changes... > >> >> > I'm not really sure if it would be a totally different programming > >> >> model. > >> >> > > >> >> > Anyone out there tried to integrate Gears And Wicket > >> >> > > >> >> > Carlo > >> >> > > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> >> For additional commands, e-mail: users-h...@wicket.apache.org > >> >> > >> >> > >> > > >> > > >> > >> -- > >> View this message in context: > >> > http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23352910.html > >> Sent from the Wicket - User mailing list archive at Nabble.com. > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
