Some feedback

[Wouter Vanden Hove]

Hi Alan,

I've tested the apps generated by the scaffolds today,
and send a pull-request with my fixes.

Some gripes after creating some custom content-types:

1) using a dynamic-vocabulary in a content-type seems cumbersome.
the accepted vocabulary-method is a method, outside the class in which
you are defining the vocabulary,
which also means you don't have access to the request.

It would be nice to be able the define the vocabulary-method inside the
class where you define the schema.
e.g.:

list_services = sqla.Column(sqla.Unicode,
info = {'field_type': 'choice', 'vocabulary':
vocabulary_list_services(),})

-->
list_services = sqla.Column(sqla.Unicode,
info = {'field_type': 'choice', 'vocabulary':
self.vocabulary_list_services(),})

2) still with the vocabulary, I'm having trouble using
vocabulary.SimpleVocabulary.from_items / from_values / ...
it doesn't accept regular iterables like list or tuples:

this works:
return vocabulary.SimpleVocabulary.from_items(
('foo1', 'foo1', 'Foo1'),
('foo2', 'foo2', 'Foo2'))

but this doesn't:

items = [('foo1', 'foo1', 'Foo1'),
('foo2', 'foo2', 'Foo2')]
return vocabulary.SimpleVocabulary.from_items(items)

3) pview has disappeared from public API, but what's the alternative now?

I liked very much the ability of having a class with 50 methods/properties
and just use them directly in templates, just like BrowserViews in Plone,
e.g. ${view.property1}

now I have explicitly add them again to a giant return-dictionary,
which feels like a pointless repetition of all the variables.
That feels like a step back.

4) What decision was made regarding fanstatic?
Issue #48 was closed without comment.

Greets
WouterVH

[Nikolay Kim]

> 1) using a dynamic-vocabulary in a content-type seems cumbersome.
> the accepted vocabulary-method is a method, outside the class in which
> you are defining the vocabulary,
> which also means you don't have access to the request.
>
> It would be nice to be able the define the vocabulary-method inside the
> class where you define the schema.
> e.g.:
>
> list_services = sqla.Column(sqla.Unicode,
> info = {'field_type': 'choice', 'vocabulary':
> vocabulary_list_services(),})
>
> -->
> list_services = sqla.Column(sqla.Unicode,
> info = {'field_type': 'choice', 'vocabulary':
> self.vocabulary_list_services(),})

you can create your own field and pass field instance, something like:

class MyChoice(form.Choice):
....

list_services = sqla.Column(
sqla.Unicode,
info = {'field': MyChoice()})

or

class MyChoice(form.Choice):
form.field('mychoice')

list_services = sqla.Column(
sqla.Unicode,
info = {'field_type': 'mychoice'})

> 2) still with the vocabulary, I'm having trouble using
> vocabulary.SimpleVocabulary.from_items / from_values / ...
> it doesn't accept regular iterables like list or tuples:
>
> this works:
> return vocabulary.SimpleVocabulary.from_items(
> ('foo1', 'foo1', 'Foo1'),
> ('foo2', 'foo2', 'Foo2'))
>
>
> but this doesn't:
>
> items = [('foo1', 'foo1', 'Foo1'),
> ('foo2', 'foo2', 'Foo2')]
> return vocabulary.SimpleVocabulary.from_items(items)

you can use '*'

return vocabulary.SimpleVocabulary.from_items(*items)

> 3) pview has disappeared from public API, but what's the alternative now?
>
> I liked very much the ability of having a class with 50 methods/properties
> and just use them directly in templates, just like BrowserViews in Plone,
> e.g. ${view.property1}
>
> now I have explicitly add them again to a giant return-dictionary,
> which feels like a pointless repetition of all the variables.
> That feels like a step back.

we won't remove pview api, you can use it. we just dont want show api
that duplicates pyramid api. at least during current stage of
development.