Friday, July 30, 2010

Re: GWT evaluation: How to realize this specific app scenario? (v.2)

Hi Alessandro,

GWT features a history mechanism which could solve the first question:
provide info on that: rather than using a file path, you'd use #....
(an identifier after a hash). Many AJAX apps work that way to prevent

GWT is quite powerful concerning internationalization using property
files (you delcare an interface and provide a property file and bind
it together using the GWT class)

Concerning in-place editing, there is surely a way; Google wave is
implemented in GWT and also features rich editing features.

Finally, there is a gears binding for GWT (
) which you can use for offline storage (modern
browser or plugin required).

Hope this helps...

On 30 Jul., 13:41, "A.Augustini" <>
> [**Republished to get rid of ugly line-break cluttering**]
> Dear GWT Community members:
> As GWT newbie I'm currently evaluating GWT for some potential future
> projects. After reading available introductory materials, I'm now
> wondering if GWT is the appropriate candidate for my specific app
> scenario.
> Obviously there are 2 basic GWT app dev styles:
> (1) "desktop-app setup":
>        one GWT module on one almost empty "carrier" HTML page.
> (2) "traditional-web setup":
>        several traditional HTML pages with some GWT widgets.
> Supposing this is correct: What would be the ideal GWT app
> architecture for the following, "more hybrid" scenerio?
> Say we've to build a kind of "Mini Online Site Builder" with some
> simple CMS functionality and basically consisting of 2 main
> requirements for 2 available enduser roles:
> (A) 'SiteAdmins' have secured access to an 'AdminConsole' where they
>     dynamically *compose/edit*, *preview* and publish 'WebSites'
>     -- AdminConsole thus supporting "2 work modes": Edit & Preview!
>      - 'WebSites' are all published under a common base URL plus
>         admin-specified relative site path.
>      - 'WebSites' consist of 'Pages', probably associated to a
>         default 'MasterPage' and default "Theme".
>      - 'Page' may have own 'MasterPage' and 'Theme'.
>      - 'MasterPage' is composed of typed 'PageRegions'
>         (e.g. Header-/FooterRegion, NavRegion, ContentRegion, ...)
>      - 'PageRegion' has list of 'Content' elements of some
>        'ContentType' that is permissible with that region's type.
>         ContentTypes could be: TextParagraph, HTMLParagraph,
>         ImagedTextParagraph, Image, Table, Form/Survey, etc.
>      - SiteAdmins would have some advanced widgets to define complex
>        domain content elements, e.g. spreadsheets, price tables, ..
>        (=> good candiate for GWT)
> (B) 'Users' visit the resulting web sites through site-specific URL
>      and
>      - navigate back and forth and may submit some public or authen-
>        tication-requiring ordering/posting forms.
>      - User experience should be the traditional (!) web site UX
>        (=>good candidate for JSF instead of GWT(?))
> Obviously, the AdminConsole impl is a good candidate for a pure GWT
> module (see (1) above) whereas I rather would choose pattern (2)
> for the web site renderings -- the above-mentioned "hybridity".
> Now, I need some experts' advice in the following topics:
> 1. Is GWT suitable for "mimicking" traditional web pages within a
>    GWT widget pane, i.e. where users can navigate through pages
>    via several seo-friendly URLs (or just one(?))?
>    I guess *client-side* logic would download the site/page
>    representation via GWT-RPC and dynamically render it on the
>    client, BUT ...
>   ...How can the *inter-page navigation* via bookmarkable URLs
>      be realized???
>      => Could I still have bookmarkable URLs like
>         "" working correctly in my
>         browser???
> 2. Where would I place the page interpretation/rendering logic, and
>    what would be its output format?
> 3. How would I realize the *preview* and *edit* modes in the
>    AdminConsole?
>    I suppose an "in-place edit strategy" would be optimal, where the
>    page preview is visible and only the active section panel gets
>    decorated with edit/save buttons -- thus avoiding separate
>    read-only and read-write views.
> 4. Is there a client-side storage mechanism to temporarily save
>    current WebSite definition entities?
>    If so, is there a size limitation for this storage?
> In my current situation, I would highly appreciate any realization
> hints. Thank you very much in advance.
> Best regards,
>    Alessandro

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

No comments:

Post a Comment