"Steve Bergman" <[EMAIL PROTECTED]> writes:
Thanks. Perhaps part of the problem is my tenuous grasp of Javascript
and MochiKit. (I'm working on it, but finding it to be... involved.)
:-) I'm learning JavaScript as well... And I'm really amazed about how
MochiKit makes life easier!
Still, it seems more straightforward to have ids and classes to grab
onto. Sometimes it seems to me that, compared to Rails, TG tends to
over-complicate some things.
Sometimes we have to sacrifice something due to being a project that aims to
be a framework targeted to general applications, not something specific.
My knowledge about Rails is minimum. I didn't like it. Specially due to a
lot of things that happened automatically and that made my life more
complicated if I want a variation of what the authors wanted.
On the other hand, I hate slow, heavy sites, so your criticisms are
well received. (I tend to do a lot of long table reports in my intranet
projects.)
That's my biggest concern. For extranet we usually paginate data and create
more filters, but there are times when it is necessary to have bigger
reports.
Maybe ids and classes should not be generated by default for some items
and their siblings, but could be turned on if desired?
Agreed. Even though this would make the rendering slower... How about a
derived widget? TableForm and TableIdForm?
TableForm(fields=fields(), ids=True)
or
TextField(ids=True)
You're proposing changing *all* widgets? Not just Grids and TableForm? I
don't see the need for changing all widgets since it is much easier to do what
you want when rendering individual widgets:
<span id="my_widget_span_id" py:replace="my_widget(value)" />
If you don't want the ID or keep the span then you just:
<span py:strip="1" py:replace="my_widget(value)" />
This could actually reduce overhead and bandwidth since these items
could be left off when not needed?
Sure! But I'd go with the TableForm approach... Either all or none.
Or maybe I'm just wrong. ;-)
At any rate, you've given me a direction for solving my current issue
of hiding a label field in a RemoteForm.
:-) It's not really hard, believe me. And having a function for that in a
common library makes it just a call:
<script type="text/javascript">
hideMyField('field_id');
</script>
Then, hideMyField could be something along the lines of:
var hideMyScript = function (element_id) {
element = $(element_id);
previous_sibling = element.previousSibling;
updateNodeAttributes(element, {'class':'invisible'});
updateNodeAttributes(previous_sibling, {'class':'invisible'});
}
:-) I haven't tested, but this might work...
Ah! In your CSS add ".invisible { display: none; }", for example. :-)
I dunno how hard it would be in Rails, but after writing those 4 lines of JS
once then it is just one line of code everywhere...
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
