# from Waldemar Biernacki
# on Monday 30 November 2009 08:23:
>My idea is to build specific very-high-level language in which all
> application logic is written. This language should be reading by GUI
> and WEB engines giving similar application. It is interesting that in
> web area we have many such templates (although their code programming
> level is too low in my opinion - including catalyst) but on a GUI
> side they are very few (it should be written in wxperl in your case).
That sort of touches on what I'm doing with FreeTUIT, though the
high-level language is all about widget layout and event connection.
Some backend logic doesn't contain any Wx code, but when you get into
responding to user events you need rather specific code interacting
with the view (e.g. wxWidgets vs javascript+cgi.)
Note that FreeTUIT is intended mostly as a desktop GUI framework, but
I've been asked about whether it could do web apps and have been
thinking about how that might be possible.
There's a big gap between the two paradigms though because in a GUI app
you're not designing around network latency. I'm having a hard time
thinking of how those differences could be abstracted without crippling
the API in both use cases.
There's also a very limited widget-set in web applications as compared
to desktops. For instance, webapps would frequently use a submit form
for appending/editing tabular data where a guiapp would trivially allow
inline edits in the table. Similarly, the webapp would page the data
where the guiapp would easily have a scrollable widget that's lazily
populated.
In "traditional" (i.e. without javascript) webapps, you're basically
working in an "everything is a wizard" paradigm of stepping through
prompts and a rather sequential interaction -- pretty simple concepts
to map between a desktop and webapp. With ajax involved, you get to
juggle the widgets right in front of the user, which makes for a more
mediated experience. The trouble with automagically handling this
widget-juggling code in both webapp/desktop paradigms is not only the
javascript/wx API difference, but also that the code seems to naturally
factor into differently shaped components in terms of dealing with
what's in front of the user and recalculating/rendering data from the
backend.
Amusingly, there's a thread about "Qt on rails" happening over on the
kde bindings list.
Also amusingly, if "MVC" was a valid abstraction, this problem would
have been trivially solved long ago. :-D
--Eric
--
"It works better if you plug it in!"
--Sattinger's Law
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
