Werner Thie wrote:
> Hi
> 
> Don't know if Ken with it's server side UI generation has a fancy 
> designer at hand (my LISP experience was before GUIs) but going further 
> than aggregating a few elements, UI writing and maintenance becomes a 
> pain real fast.

What we do in Lisp is use macros and other neat features of the language 
to make the code assembling a GUI so dense that it is faster to juggle 
the code than it would be to mess with a GUI builder:

(defun search-panel-kt (self)
   (hbox (:align-y 'middle :spacing 12)
     (:allow-grow-y :js-false
       :padding 4)
     (lbl "Search for:")
     (textfield :symbol-string ;; WARNING -- new and untested
       :add '(:flex 1)
       :allow-grow-x t
       :onchangevalue (lambda (self req)
                        (let ((sympart (req-val req "value")))
                          (setf (sym-seg (u^ qxl-session)) sympart))))
     (button "Search" (:enabled (c? (> (length (value (psib))) 1)))
       :onexec (b-when sympart (value (psib))
                 (print `(:sympart-onexec ,sympart))
                 (setf (sym-seg (u^ qxl-session)) sympart)))))

And because it is code (and because I am driving qooxdoo dynamically 
from the code) I can move things around in the code and hit refresh in 
the browser and see the result. Even against a "build" version, which I 
only need to regenerate if I start using a new qx class.

Note also the "enabled" rule*. In this case it is just looking at 
another widget, but it could also being looking at business data and 
making a decision based on business logic. Even better, instead of just 
deciding the enabled state of a widget, a rule for the children of a 
composite widget could decide to put up a whole new (or just slightly 
modified interface) based on business logic. This lets GUIs be leaner, 
smarter, and more helpful, showing users only what is appropriate for 
the state of their particular browsing experience as it unfolds.

kt

* Actually, I took that rule out of the demo. A bit of trouble detecting 
/as they type/ (that being the whole idea) whether the field is empty or 
not -- the (I think) "input" event happens before the text gets updated, 
so I ended up guessing (badly) based on the keystrokes whether the field 
was empty or not and punted on that.

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to