{5} Assigned, Active Tickets by Owner (Full Description) (22 matches)

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")

Hello, Right now Turbogears biggest problem is no Documentation. We need a strategy from turbogears project to lead a way to better documentation.

What documentation? 1. First step is to setup epydoc and provide documentation that is available in python code. http://epydoc.sourceforge.net/using.html, you have an doc.ini file already http://groups.google.com/group/turbogears-trunk/browse_thread/thread/c6e4776957b75abc put the results in epydoc.turbogears.com 2. Provide one source or one template that has all the documentation pages. Perfect setup is: http://www.sqlalchemy.org/docs/04/index.html template that builds one page documentation. If this is too hard then merge all wiki pages into one rough1.0doc and let people start working on removing duplicate stuff. 3. Provide some limits/proper use on creating wiki pages. Example: Search on widget results in 16 results out of about 1264 pages. (0.79 seconds)

1. 1.0/CompoundWidgets
2. 1.0/DataGridWidget
3. 1.0/IntroductionToWidgets
4. 1.0/RemoteFormWidgetTutorial
5. 1.0/RoughDocs/DiveIntoWidgets
6. 1.0/RoughDocs/ModifyWidgetDefault
7. 1.0/RoughDocs/WidgetTips
8. 1.0/RoughDocs/WidgetsOverview
9. 1.0/SimpleWidgetForm

1. 1.0/StatelessWidgets
2. 1.0/WidgetBrowser
3. 1.0/WidgetList
4. 1.0/WidgetPackages
5. 1.0/Widgets
6. 1.0/WidgetsOverview
7. 1.0/WidgetsWithJSAndCSS

1.0/Widgets should be only one that holds all subsequent pages as part of the doc.

4. wiki software? Is this a moinmoin wiki? It seems to be really hard for me to edit it because of syntax. Can we switch to moinmoin wiki? python/debian websites are using it and the syntax is much easier. It allows docbook rendering as well as other options that can potentially be useful. Much more syntax options http://wiki.debian.org/ Out current wiki has a similar look but the benefit of more user friendly doc software will benefit us more.

5. Could these changes be implemented before next release? 1.0.x And setup some time frame of what is going to be done, or what can be done now vs next week vs month from now.

Thanks, Lucas

Some of the advanced features of the identity framework are currently poorly documented or not at all, e.g.

• Setting identity.failure_url to a callable
• Creating custom identity predicates
• Creating custom identity exceptions
• Handling identity error messages

We should document these in source code docstring in the turbogears.identity package and the Identity docs in the wiki.

Relevant mailing list thread:

No redirect when not enough credentials (Tiny URL: http://tinyurl.com/5p6zus)

When displaying the wiki with IE7 the TurboGears banner at the top hides the first lines of text. This is not the case when using IE6 or FireFox?.

Pursuing the goal to cut down the size and complexity of the TG core, I propose to remove the feed package from the main TG distribution in 1.1.

I have created a new extension package TurboFeeds from the feed package, which can act as a drop-in replacement.

I have written an example command.py that provides a "bootstrap" function for a console script "bootstrap-<yourpkg>", which creates all tables and optionally creates a user.

http://paste.turbogears.org/paste/10038

The example is SQLAlchemy, but I have also written a patch against current TG 1.1 HEAD that adds support for this in commands.py in the default quickstart template and which also works for SQLObject-based projects.

Would this be something that should be added to the default quickstart template or will this make the code in commands.py too complex?

Right now there's no way to discover what quickstart templates are available, except by reading the TurboGears source.

tg-admin should have a "templates" command that lists available quickstart templates.

at the moment the context is not provided (see TODO in source)

The code needed to the controllers in a TG2 project should be moved from the default template to the tg.testutil module, in order to make the default template simpler.

Backport use_wsgi_app() from 2.0. use_wsgi_app provides a nice shorthand for dispatching to a wsgi app in code, rather than configuration. Good ideas are meant to be stolen.

When paster quickstart is used and the user chooses to have user accounts, a websetup.py file is created that creates a couple of default user accounts. The line:

    u.password = u'password'

is used to set the password. This triggers a get property method in identify.py, which does the following:

        algorithm = config.get('authorize.hashmethod', None)
        self._password = self.__encrypt_password(algorithm, password)

However, even if authorize.hashmethod is set in the ini file specified when doing paster setup-app <ini file>, the call to config.get() returns None, which means that passwords will be stored in plain-text! config['authorize.hashmethod'] returns the value from the INI file. The cause of the problem can be found in the implementation of the PylonsConfigWrapper class found in tg/configuration.py (note that config is of type PylonsConfigWrapper). The PylonsConfigWrapper class is used to provide a thin wrapper around another dict object. However, it only wraps some of the standard dict methods. It provides a wrapper for the [] operator (via the __getitem__ method), but it doesn't wrap the get() method. According to http://docs.python.org/ref/sequence-types.html , it is recommended to implement more methods than the "__"-style methods, such as get(), values(), has_key(), etc.

It appears that the reason for this wrapper class in the first place is to provide attribute-style lookups (from the documentation for this class), ala

algorithm = config.authorize.hashmethod

However, even this doesn't work and results in an exception, although it does get into the __getattr__ method when this is done.

Perhaps UserDict would be a better choice. Or, maybe it would be best to simple do away with this wrapper object.