[TurboGears] Re: FastData coming along well.
Hmm...My experience was almost opposite. The formmaker is very rigid and hard to customize. In the end, I resorted to override generic column function for specific data items which is no more then a crude hack. Do you have any thoughts on what would be an easier interface for you? Here are a couple of thoughts 1) you can set a widget attribute on a column to specify how that column is generally displayed. (breaks MVC, but is terribly convenient). this should be a trivial change. Didn't know about that trick, thanks! 2) maybe we can make use of/extend the new WidgetDeclaration class to make it easy to customize the output. We could do something so that you don't have to declare *every* widget... just the ones you want to override. May be. Unfortunately I don't have any good thoughts about the 'better' interface right now but only can complain how rigit the current interface is wrt extention. ;-)
[TurboGears] Re: FastData coming along well.
On 2/2/06, Martina Oefelein [EMAIL PROTECTED] wrote:
One should keep in mind that this isn't quite MVC anymore, as the
model now decides over its representation (i.e. view). Of course, if
you consider FastData a tool to create a quickdirty CRUD interface,
and not the main user interface of your application that's probably OK.
The idea (and this is the difference between fastdata and CatWalk) is
that it starts off quickdirty but should be able to work up into a
usable interface. It's not there, yet, though.
What would be the proper MVC way? In TG, the (kid) templates play
the role of the view, so we would need a way for the app to specify a
template that renders the object as an xhtml fragment. There could
still be a default template, e.g. just span xmlns:py='...$
{object_instance}/span would be a good default that happens to
give the same result as the current implementation.
It's quite likely that you'd want different appearances for the same
object in different places. That was why I was saying that some third
party object is the more likely candidate to handle this. It could be
as simple as a template. Or it could be a widget, which would allow
for more customized behavior than a template might comfortably do.
Kevin
[TurboGears] Re: FastData coming along well.
On 2/3/06, Max Ischenko [EMAIL PROTECTED] wrote: I was using the fastdata.DataController to do some CRUD with User/Group/Permission data. I was pleasantly suprised by the configurability and the new join_widget and fk_widget. With a little more polish, DataController could be useful for the majority of CRUD applications. Hmm...My experience was almost opposite. The formmaker is very rigid and hard to customize. In the end, I resorted to override generic column function for specific data items which is no more then a crude hack. Do you have any thoughts on what would be an easier interface for you? Here are a couple of thoughts 1) you can set a widget attribute on a column to specify how that column is generally displayed. (breaks MVC, but is terribly convenient). this should be a trivial change. 2) maybe we can make use of/extend the new WidgetDeclaration class to make it easy to customize the output. We could do something so that you don't have to declare *every* widget... just the ones you want to override. Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: FastData coming along well.
Am 02.02.2006 um 21:12 schrieb Kevin Dangoor:
For the column_widget_fk_col and join_widget_related_join, the
data is
displayed using unicode(object_ instance), which is ugly. Maybe it's
just stepping stone, but I think there should be a way to specify a
column to use to display the object. Maybe something similar to
form_order or somthing defined in sqlmeta like
sqlmeta.display_field =
'name'. I'd like to hear opinions on if and how this would be done.
This was discussed either in a ticket or on the list... Here was the
thinking: just giving a column name isn't good enough. (Consider a
table with last name, first name and middle initial). Of course, you
can use a property instead. But, what I was figuring was that what
we're really angling for when you're displaying that is the
human-understandable form of that particular object. And that's what
__unicode__ or __str__ are all about, right?
One should keep in mind that this isn't quite MVC anymore, as the
model now decides over its representation (i.e. view). Of course, if
you consider FastData a tool to create a quickdirty CRUD interface,
and not the main user interface of your application that's probably OK.
What would be the proper MVC way? In TG, the (kid) templates play
the role of the view, so we would need a way for the app to specify a
template that renders the object as an xhtml fragment. There could
still be a default template, e.g. just span xmlns:py='...$
{object_instance}/span would be a good default that happens to
give the same result as the current implementation.
ciao
Martina
