Thanks for the info - I'll need to read up on the deferred binding page (a term I've always come across in GWT but never read about in detail!)
I guess I have to be a bit more specific about this "demo" mode. This is essentially a report generation system, and the final output are reports being emailed to certain pre-set addresses. In this demo/ sandbox mode when a user logs in, they are also asked for their email address in the login screen (the 'normal' flavour just asks for their username and password), then while logged in, any operations done with that user session sends emails to the supplied email address at login time rather than the pre-set ones - hence a "demonstration" mode (ie, as in, not crippleware, but sandbox mode) of the software. All the report generation/emailing is already implemented, and I'm looking for a way to wrap this demonstration mode around it. Having dynamic behaviour in the client/server is not a problem, but its the implementation of the actual switching mechanism that I'm not sure about. > accessible flag in your client code based on that, and check that flag > throughout your code to decide whether to display demo extras. The That was my thoughts exactly for the client side. However, given the actual scenario above, you can see that it would be bad for the user to be able to turn it off. But at the same time I would like the server side to be able to easily switch between (and tell the client likewise) normal/demo mode without recompilation/deployment. In normal Java trains of thought, I would be thinking in terms of the program's arguments (String argv[])...but in GWT.... thanks again Sunny On Apr 22, 12:08 am, kozura <[email protected]> wrote: > You might consider deferred binding, which would automatically compile > two separate flavors of your app, a demo and a regular. Basically > you'd have pieces of code that would do nothing in regular mode, but > in demo mode would add all those extras. Can then use various > mechanisms to pick which one is used. The main benefit of this is, > your regular users don't have to download all of the code needed for > the demo stuff. > > This is how internationalization and browser-dependent compile flavors > are generated, but it can be used for other purposes like this: > > http://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsDefe... > > Alternatively, you could have your client make an RPC call to the > server on startup to retrieve which mode you want, set a globally > accessible flag in your client code based on that, and check that flag > throughout your code to decide whether to display demo extras. The > benefit here is you can have a way for the user to turn off demo mode > at any time if you'd like. > > On Apr 21, 6:32 am, "[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 at http://groups.google.com/group/google-web-toolkit?hl=en.
