[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] GNUmed web interface - to framework or not to framew

From: Dave Cramer
Subject: Re: [Gnumed-devel] GNUmed web interface - to framework or not to framework
Date: Mon, 28 Jun 2010 06:15:49 -0400

On Mon, Jun 28, 2010 at 5:59 AM, Sebastian Hilbert
<address@hidden> wrote:
> Having read up quite a bit on the subject over the last few days a picture
> is forming. In short there is no such thing as the optimal solution.
> Frameworks are all the hype nowadays. They have helped to make Javascript
> usable for web application developers despite the fact that browser
> incompatibilities are a pain in the rear.
> Since browsers speak Javascript one needs to learn that language. Sure there
> is GWT which lets web developers develop in JAVA (it will compile JAVA into
> Javascript). When reading up on GWT I came across ZK which is yet another
> toolkit for JAVA developers.

Well, javascript on it's own isn't so bad, but it's each browsers
implementation that is the problem and part of what all of the
javascript libraries solve. You will loose more than a few days of
your life on some very small issues if you choose to implement this by
writing it in pure javascript.

> Then a tiny little bit of information came up that is overlooked and
> ingnored by media. There is a difference between client side frameworks and
> server side frameworks. Often one is tempted to look only at the graphical
> user interface of the frameworks. Beauty is all too often associated with
> quality.
> For all non web app wizzards the basics are like this. In a client side
> framework all the processing is done in the browser on the client. If the
> app wants data it has to talk to the server to get it. On other end there
> are the server centric frameworks that process all data and user interface
> on the
> server and send html to the browser. The server centric way is often
> associated with a desktop like developement. Both approaches have their
> share of pros and cons.
> Some of the conclusions I have drawn so far:
> framework is no well defined entity
> some include features to render a user interface, some talk to databases,
> some to all of this
> user interface frameworks
> there are many, most are client side, some are server side and some are both
> most are Javascript based, some are JAVA-based (GWT) or Python-based
> (pyjamas)
> a bug in the framework might break the application
> language considerations
> many if not most web app developers are using Javascript
> professionalism varies widely
> supposedly going through a language-to-Javascript compiler
> will fail badly in case of a bug
> framework intercommunication
> various techniques including Json and RPC exist but there is no consensus
> or benchmarks

I'm not sure the two mentioned above are different. JSON is simply a
way of rendering data, much like XML but less verbose. RPC can be
implemented using JSON, or XML or .... pick your data representation.
> designer applications
> the widely used frameworks such as extJS and ZK have designer applications
> available which would allow non-coders to produce pseudo code or mock ups.
My experience is that designer applications are only useful for
mockups and to learn how to code. They fail very quickly after the
first 30 minutes when I try to do something just a little outside of
the box they were designed in.

> Going back to the drawing board (with a little more info on frameworks) here
> is what I am looking
> for.
> code or a framework that lets me develop the user interface without it
> messing with the database itself (for now). This is the work of gmPG2 and
> friends.
> a nice looking set of widgets that makes up a nice looking interface
> a set of widgets that can be accessed through python (e.g. ToscaWidgets)
> a framework that will be there for a few years and not being given up for
> the next best thing
> solution that lets me seperate design (html, css, JS) and content through
> e.g templates
> So far I have found nothing that fits the bill. In case of Pyjamas I am
> unsure about its future and its set of widgets. I like that one could
> develop in python. It would mean that Javascript coders are left out. GWT
> would mean learning JAVA. License is Apache License v2.0. extJS or qooxdoo
> would mean learning Javascript and would leave the python coders out. I like
> the idea that extJS and ZK have designers available.
> As always feedback is highly appreciated.

grails which is groovy/java provides a complete solution with the
backend done using grails and the front end can be coded in GWT. I
understand this is not a solution you would choose. I only bring it up
because there may be python frameworks like grails that have similar
GWT modules .


reply via email to

[Prev in Thread] Current Thread [Next in Thread]