I am new to GWT and am going through the docs, examples, demos etc.
All the examples seem to have just one module which is loaded by a single html page contained in the sample.
What if the web app has multiple web pages/features. Can multiple web pages providing different functionality utilize the same gwt module by building the UI differently based on request params?
Or is it normal to create one module per html page (feature) in the app?
You can have a look at these two questions:
Multiple pages tutorial in Google Web Toolkit (GWT)
GWT with multiple host pages in a legacy application
...or at this site which guides you through the process, if you are new I strongly suggest to subscribe to the 5 days email course.
Usually a GWT module contains multiple 'screens', or 'views'.
In short: Yes you can have multiple different pages in a GWT app.
Full: You can do his in several ways, the easiest is to use the XML file where you can list the various URL points (the same you use to specify the RPC call back URL) to list multiple URL's and the corresponding classes (each class will need to inherit the correct classes to ensure it is a front end)
You can also simply generate different screens based on different variables in the same class, however this will complicate the code and lead to messy designs.
I think that using less number of the pages that needs full page reload to interact is better in GWT.
In generally, you can to divide logic to many tabs, screens, windows and other layouts, that can interact without page reloading.
See on the google mail )
Related
I was wondering if/how I can reuse a fragment definition created in application 1 within application 2?
Background: I have 4 application (due to technical reasons there need to be 4 standalone fiori applications) displaying similar data.
My approach would have been to create fragments and reuse them across all 4 applications.
But how can I load fragments from another application?
Most stuff I've found either is limited to relative paths or JavaScript modules....
After digging a little further, I noticed that I can register the desired module path using
jQuery.sap.registerModulePath("name.space", "/sap/bc/ui5_ui5/sap/bsp_name");
Afterwards name.space is available in XML view and can be used to
load the fragments.
i18n is not loaded though but this I can handle.
in standard "page-based" webapps, it´s quite easy to implemet direct links to several pages, f.e, an url abc.com/app/customer/4711 which directs the user directly to the page diplaying customer 4711.
Is there a way to reproduce a similar behaviour in an GWT-App?
Tnk Mica
You can use Activities and Places design pattern. It provides easy access to any "place" within the app:
https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces
Every once in a while this question is being asked in one form or another and I think misconception exists about what GWT is best suited for.
GWT is an amazing set of tools for creating web applications: JavaScript multi-screen user interfaces which run in modern web browsers, load as a single web page and generally don't need full page reloads or page switching for their operation.
Navigation between screens happens in response to triggered events (for example, a user pressing a button, a timer firing or server-side state changing). The data needed to be presented is acquired asynchronously via XHRs (again without web page reloading).
GWT provides an elaborate framework for all of the above - Activities & Places for navigation, as Andrei mentioned, GWT-RPC and RequestFactory for data acquisition and exchange, and much much more to make advanced and highly-structured web apps which leverage the processing power of modern machines and capabilities of modern browsers.
I am working on a GWT app that needs to serve a different layout to mobile device users. I can easily determine if a user is using a mobile browser; however, I'm not sure about the best pattern for handling them.
I am currently using the MVP pattern - would it be best to simply pass a browser-specific view to the Presenter or is there a more appropriate method?
You could set up GWT to detect the web browser used, as described in this question. Then, via Deferred Binding, let the compiler "slip" the correct view into place for the, say, mobilesafari user agent. That way, you won't have to litter your Java code with browser detection, etc.
The way I've done it is to have different GWT modules (with their own entrypoint, Gin modules, even different CssResources) and then on the myapp.html page you just have to check out what browser is requesting the content and based on it (javascript checks) the appropriate module
<script src="myapp/myapp.nocache.js"/>
or
<script src="mymobileapp/mymobileapp.nocache.js"/>
is loaded.
If you are working with GIN and an MVP framework (gwt-platform is my platform of choice) you can then reuse the code that was already written for the presenters and only implement different views.
I've been thinking about this recently and I don't know a really nice and tidy way of creating a mobile version of an existing or new MVC2 website/app.
I think the easiest way would be to just use a different stylesheet depending on whether a mobile was detected but sometime you need to change the view content too if you have massive inline images everywhere or for other reasons.
What is a good approach for this? Is there a way of theming fairly easily in MVC2?
Well MVC is just your server-side technology, what you should ask to yourself is "what is the best practice to create a mobile web site, regardless of the server side tech".
In my opinion, creating a well-formed and semantic (x)html is the first step. As you say, the most logical thing to do is create different style sheets for different media types, and you're right.
As for the problems you mention, like inline images, consider this: are those images content or presentation?
In the first case, they should be present even in the mobile version.
In the latter, they are defined in the style sheet, so you can simply avoid them in the mobile css.
The only exception I can think of is when you want to provide different functionality on mobile, or if you're forced to, i.e. on pages that rely heavily on JS and those scripts wouldn't run on mobile browsers. In this case, you might want to create different versions of those pages and serve the appropriate version based on the user agent.
Check the source code for NerdDrinner. They've implementated a MobileCapableWebFormViewEngine class which inherits from base WebFormViewEngine class. The MobileCapableWebFormViewEngine uses the HTTPContext to decide which View to render in the client. This'll make more sense when you see the source code
Anyone know of any tutorials implemented across multiple web application frameworks?
For example, I'm starting to implement GWT's Stock Watcher tutorial in Turbo Gears 2 to see how difficult it will be to do in Turbo Gears 2.
Likewise, I'll be looking for a Turbo Gears 2 tutorial to implement in GWT.
But I hate to re-create the wheel - so I was wondering if anyone was familiar with such projects and/or would be interested in helping me work on such a project.
Thanks,
--Spencer
While it is possible to combine the two frameworks, I hope to convince you not to do so.
Most web-frameworks, including Turbogears, have server-side page flow management. A page is served to the user by generating html, user interacts by clicking on links or by posting a form, the browser sends a fresh request to the server, and finally server responds with new html altogether. You AJAX'ify the page by using a js library, or the framework has some support. But, in general, transition from one view to another is done on the server side.
GWT is totally different. There is only a single HTML page in the system. Once this page is downloaded, everything happens on the browser through javascript. When the user clicks on a link, its essentially just a javascript function call. History management is done through fragment urls (the portion after the #).
These two philosophies are poles apart. So apart that I daresay GWT doesn't work well with any server-side web technology. See this discussion on GWT vis-a-vis JBPM/Struts/Spring Webflow. And see this discussion on GWT v/s JQuery.