I'm inclined to agree with Jacob. On the note of "magic", it never
ceases to amaze me how people complain that there's too much of it, but
also complain when they have to keep passing the same objects around (a
common sign of no/little magic).
CherryPy has its share of magic as well, including th
For those concerned about the fact that these helpers use ProtoType and
Scriptaculous, it should be noted that Mochikit 1.3 will include
equivalent functionality. This should make it seamless to use Mochikit
instead with no or minimal changes to the helper functions.
There's several people now wo
I'd think the most reasonable approach would be to have the frameworks
reference the module.
Myghty doesn't require an API, as the names are just imported and
attached to a template global helper object, ie, <%
h.observe_field(.) %>. TurboGears may likely require a bunch of
API's for the vari
Eugene Lazutkin wrote:
> My only problem with RoR's approach in general regardless of underlying
> library is it is very low level. Essentially it is a way to propagate
> some events to the server. I am not sure I like the idea of callbacks
> for every sneeze. David (of RoR) really dislikes progra
Eugene Lazutkin wrote:
> A lot of people who use list boxes, radio buttons, and other widgets
> don't know X11/Win32 graphics APIs and event systems. My point is there
> are many ways to minimize exposure to js.
Agreed, I have yet to see anyone come up with clear cases for widgets
within web prog
Louis that made the Django adaptation stuff, I just ported it from
Ruby. :)
The RJS style stuff is going to take some thinking about the best style
of usage within Django, any volunteers? I'll be happy to go over the
details.
- Ben
6 matches
Mail list logo