Thanks for the replies so far guys. To clarify, I'm after the scenario where the server is fired up in one mode or the other, and anyone who accesses the site will be using that mode - there won't be simultaneous use of both modes. The difference in the client between demo/normal modes is quite minor, and I believe deferred binding would be an overkill compared to a couple of if statements.
Again, the big difference in functionality is in the server side (re the original concept, this is a system that emails generated reports - in demo mode, the server sends all emails generated by the logged in user to an email address that is entered at login. In normal mode, the user is not asked for an email address at login, and emails are sent to predetermined addresses). All this functionality has already been implemented: 1) User goes to web app URL 2) Client fires GWT-RPC to determine from server whether server is in demo mode If server is in demo mode: 3a) Login screen shows an extra field to ask for an email address 4a) For all emailing operations done by that user, server sends emails to the user-entered email address from 3a If server is in normal mode: 3b) Login only shows the username and password fields 4b) Emailing operations are sent to pre-determined addresses Re web.xml - after reading that page, I guess that should do the trick, but would require manual modification to the web.xml file each time. Is there a way to achieve this configurability outside of the WAR file? thanks Sunny On Apr 23, 5:20 am, Stefan Bachert <[email protected]> wrote: > Hi, > > It is the other way. Only the client know whether demo is right or > not. > The client has to tell the server whether demo-mode applies or not. > > I have the impression you think the server runs in either mode (demo > or not). > your server will potentially run in both modes at the same time. > A server may have lots of connections. > > Stefan Bacherthttp://gwtworld.de > > On 21 Apr., 20:53, "[email protected]" <[email protected]> wrote: > > > > > > > Thanks for the reply. Having read through the deferred binding I can > > see how it can be useful on the client side to determine whether the > > normal/demo is loaded. > > > However, whats bothering me more is how to determine this on the > > server side. I guess this is not exactly specific to GWT. Say I have > > my application compiled and deployed from a WAR file. What approach > > can I take to "tell" the server side code to use the demo workflow and > > logic? If I can do this, then the client can also determine what mode > > to run in using a simple GWT-RPC call. > > > Sunny > > > On Apr 22, 4:57 am, Stefan Bachert <[email protected]> wrote: > > > > Hi, > > > > you can use "deferred binding" to compile different instances for your > > > webapp. "Help facility" behaves like an other browser or locale > > > More > > > onhttp://code.google.com/intl/de-DE/webtoolkit/doc/latest/DevGuideCodin... > > > > Stefan Bacherthttp://gwtworld.de > > > > On 21 Apr., 14:32, "[email protected]" <[email protected]> wrote: > > > > > Hi all, > > > > > After a little guidance on this topic - not quite sure what approach > > > > should/would work. In the GWT app I'm developing, I'd like both the > > > > server/client side to have a "demo mode" that enables certain help > > > > features and enforce certain beginner workflows. > > > > > I know I can get the parameters of the URL using GWT, but the user can > > > > simply remove the demo parameter to disable it (www.../index.html? > > > > demo=1), so I'm after some way to enforce this at the application > > > > level. At the same time, I don't want to be having a boolean flag in > > > > the code/HTML and recompiling/deploying it each time. > > > > > Whats the best way to implement something like this so that the enable/ > > > > disable switch can be easily configured without recompiling/deploying? > > > > (Can an argument be passed to the server side by the application > > > > server when it starts? Can there be a config file outside of the WAR > > > > file?) > > > > > thanks > > > > Sunny > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Google Web Toolkit" group. > > > > To post to this group, send email to > > > > [email protected]. > > > > To unsubscribe from this group, send email to > > > > [email protected]. > > > > For more options, visit this group > > > > athttp://groups.google.com/group/google-web-toolkit?hl=en. > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Google Web Toolkit" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]. > > > For more options, visit this group > > > athttp://groups.google.com/group/google-web-toolkit?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Web Toolkit" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/google-web-toolkit?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
