Is it fair to say GWT should be avoided completely for developing
content based web sites.
Thanks
-mic
i've changed GWT to enable content to be indexable. admittedly i have
to maintain a modified distribution of gwt but hopefully over the
course of time these mods will come back into the main. And to be
honest there are only a few more features to support.
the key features that i needed were:
- dynamic entry point page creation from server
- user definable base urls
- bootstrapped page properties (very similar to 1.1.0's Dictionary
feature)
therefore i would not write off gwt for such apps. personally, i have
embraced it for developing such a content driven application.
if for a second you are thinking, "thats much more than i bargined
for", then you need to investigate the other ajax alternatives more.
you'll be back - making GWT mods is significantly less pain than other
alternatives.
1. http://juls.googlecode.com/svn/trunk/
2. http://ashinw.googlepages.com/gems-lifecycle-architecture.png
good luck.
rgds ash
Thanks,
mic
- changed visibility of
RemoteServiceServlet::isImplementedRemoteServiceInterface()
method from private to protected
- added RemoteServiceServlet::getObjectToInvokeServiceIntfMethodOn()
method to enable
StrutsAction style pluggability
- changed RemoteServiceServlet::processCall() method to get target from
getObjectToInvokeServiceIntfMethodOn()
- added dblclick support to DOMImplIE6::init() to avoid double clicks
from getting lost
- changed visibility of HistoryImplIE6 from packaged to public to
support override of
history implementation
- added configurability of history resource location on HistoryImplIE6
by introducing
$wnd.__gwt_historyResourceLocation variable. change effected the
init() and newItem()
methods
- changed visibility of HistoryImplSafari from packaged to public to
support override of
history implementation
- added configurability of history resource location on
HistoryImplSafari by introducing
$wnd.__gwt_historyResourceLocation variable. change effected the
init() and newItem()
methods
- set widget = null; in SimplePanel::remove() method to avoid a
precondition that can never
be satisfied once the first widget is added (ie. side-effect)
- updated the document to reflect release
------------------------------------------------------------------------
based on the above output. the source mods are to:
M
/branches/gworks-1.0.21/src/com/google/gwt/user/client/impl/DOMImplIE6.java
M
/branches/gworks-1.0.21/src/com/google/gwt/user/client/impl/HistoryImplIE6.java
M
/branches/gworks-1.0.21/src/com/google/gwt/user/client/impl/HistoryImplSafari.java
M
/branches/gworks-1.0.21/src/com/google/gwt/user/client/ui/SimplePanel.java
M
/branches/gworks-1.0.21/src/com/google/gwt/user/server/rpc/RemoteServiceServlet.java
i would have given you my recent 1.1.0 port but i forgot to set my svn
autoprops setting on eol-style and every file has a property update
against it now. but its basically the same as a 1.0.21 list above.
note, the above mods include bugs that i encountered in the gwt-user
1.0.21 runtime. i think some are still there in 1.1.0.
> Does Google have any plans for including these features ?
i hope to raise some change proposals soon enough.
hey vivian, where should i raise change proposals?
rgds ash