Ticket #858 (assigned enhancement)

Opened 2 years ago

Last modified 1 year ago

so_to_dict function to support joins

Reported by: jiri.popek@gmail.com Assigned to: alberto (accepted)
Priority: normal Milestone: __unclassified__
Component: TurboGears Version: 0.9a5
Severity: normal Keywords: so_to_dict, joins
Cc:

Description

TextField? automatically fills itself when form is to be displayed. The data to fill the form is given by dictionary created from SQLObject class using function so_to_dict(). When we need to automatically select items within MultipleSelectField? according data from join, we need to patch function so_to_dict() to return dictionary containing also joins (not columns only).

Example:

MODEL:
class Genre(SQLObject):
    titles = RelatedJoin('Title')
class Title(SQLObject):
    genres = RelatedJoin('Genre')

FORM:
def get_all_genres():
        return [(int(a.id), "%s" % a.name) for a in Genre.select()]

class TitleFields(WidgetsList):
    genres = MultipleSelectField(name='genres', 
                options=get_all_genres, validator=Int())
class TitleForm(TableForm):
    fields = TitleFields()

TEMPLATE:
${form.display(obj, action=action)}

HANDLER:
class TitleCont(BaseDataController):
    form_widget = TitleForm()
    @expose(template="plend.templates.form")
    def edit(self, obj):
        value = so_to_dict(obj)
        return dict(form=self.form_widget, obj=value, action="save")

Attachments

database.py.diff (0.5 kB) - added by jiri.popek@gmail.com on 05/10/06 12:48:53.

Change History

05/10/06 12:48:53 changed by jiri.popek@gmail.com

  • attachment database.py.diff added.

06/14/06 15:56:38 changed by alberto

I'm not sure if it would be a good idea to unfold all joins by default for any SO because a join can have potentially *many* related rows.

I can think of two possible solutions:

  • Implement so_to_dict as a generic function, with the current implementation as a default for SQLObjects with room for further specialization for app specific objects.
  • Remove so_to_dict completely and use jsonify instead, which basically does "the right thing" on SOs (needs further speciallization for InheritableSQLObjects, I have a patch for that).

Alberto

06/15/06 07:52:58 changed by kevin

  • summary changed from [PATCH] so_to_dict function to support joins to so_to_dict function to support joins.

Alberto's right... there are quite a few use cases where picking up all related objects would be way too expensive. Using a generic function makes sense.

I also wonder why you're using so_to_dict rather than just passing the sqlobject itself as the value for the form?

I'm removing the [PATCH] designator, but I'm leaving the ticket open for further thought along these lines.

09/23/06 19:43:26 changed by jorge.vargas

  • milestone set to 1.1.

01/11/07 15:10:16 changed by alberto

  • owner changed from anonymous to alberto.
  • status changed from new to assigned.

I think the best solution would be to make so_to_dict a generic function with the current implementation as a default and add support on the way for InheritableSQLObjects and, why not, leave the door open to SA mapped classes will need to change the name to something more meaningful if we want to support SA, suggestions?

jsonify could delegate to this function to handle SQLObjects in order to avoid code duplication.

Opinions?

03/28/07 12:42:12 changed by alberto

  • milestone changed from 1.1 to __unclassified__.

Batch moved into unclassified from 1.1 to properly track progress on the later