just my two cents:
what if one would like to write a full inline editing (no dialogs, just
edit on the page) module in Magnolia5? Will a Vaadin implementation
support that? I know extjs is not that hip and new but I really still
think it would be the better option since it is a more general fit to
the web world than the frameworks that fully take over the page...
The decision table clearly shows that the magnolia staff does not have
any extjs motivation and knowledge and I am kind of wondering if that is
the driving factor.
Maybe the decision table should also be assigned an importance
multiplier for each technology - As Joerg suggested, the responsiveness
of the UI should be a bit higher rated than maybe the motivation of the
team? Also on the responsiveness, comparing GWT apps to ExtJS apps the
GWT apps perform mostly slower (have you tried to run for example google
wave on a netbook? It brings it to a crawl while similar extjs apps
still perform ok).
Ruben
On 8/9/2010 6:34 AM, Jörg von Frantzius wrote:
Hi,
that's an interesting decision. When looking at the Vaadin
online-demos, they subjectively appear to be much slower in response
than Ext-GWT or pure GWT online demos. My first thought would be that
with Vaadin, all event handling is done on the server, while with GWT
most of it is done in the browser (except for raw data retrieval, of
course).
For example, with Vaadin *any custom click-listener has to be executed
on the server*, right?
That likely means a lot more requests will be sent during typical
interaction, and so performance depends highly on the network
connection. Even given a good network connection, there always is a
latency of a couple of milliseconds, which will always prevent a
Vaadin UI from reaching the subjective "snappiness" of a GWT UI.
Personally I find this a disappointing outlook, after having worked a
fair bit with GWT in Magnolia 4.3, and with absolutely great results.
Yes I have seen
http://wiki.magnolia-cms.com/display/MAGNOLIA5/Architecture+-+Decision+Table,
and yes there is a lot more factors than performance. But think for a
second how compelling /from a user's perspective/ the performance of a
GWT interface is, when comparing it to competitors' UIs. IMHO, GWT
would give Magnolia an absolutely great competitive edge.
With Google having bought Instantiations' GWTDesigner (as somebody on
this list already noted), IDE support is likely to become just great
for free as well.
Regards,
Jörg
On 09.08.2010 12:55, Philipp Bärfuss wrote:
Thanks for participating in our survey. You find a summery of the
results on the survey wiki page
->
http://wiki.magnolia-cms.com/display/MAGNOLIA5/Architecture+Survey#ArchitectureSurvey-Results
We have also filled in a decision table
->
http://wiki.magnolia-cms.com/display/MAGNOLIA5/Architecture+-+Decision+Table
After some controversial discussion the team has finally decided to
go with Vaadin. More details will follow - no later than at the
conference ;-)
Exited and looking forward ;-)
- Philipp
------------------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
--
Dipl. inf. Jörg von Frantzius, System Architect
Email mailto:[email protected]
Phone +49 30 283921-318
Fax +49 30 283921-29
Aperto AG - In der Pianofabrik
Chausseestraße 5, D-10115 Berlin-Mitte
Web http://www.aperto.de
HRB 77049, AG Berlin Charlottenburg
Vorstand: Dirk Buddensiek
------------------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
