Michele Cella wrote:
> >
> > widgets.TextField("name", template="myproject.templates.textfield")
>
> This is a feature I didn't notice, and I think that's a quite important
> feature, If i got it right you are directly referencing a Kid template,
> right?
> Now I will not say again "see below" but I will describe my ideal
> scenario:
>
> Since you can reference a widget template this way, I think that maybe
> you should not hardcode it in the source code like you're doing ATM.
> So, regarding quickstart, customization by designers and consistency...
>
> What about extending the quickstart command so that it creates a new
> widgets directory under the application template folder:
>
> apppackage.templates.widgets
> |__ form.kid
> |__ textfield.kid
> |__ colorpicker.kid
>
> by default this folder will just contain the TG implementation of
> widgets, so for instance form.kid will look like this:
>
One more though regarding this, since (from what you said and from my
understanding) widgets are bundle of python code, kid template and
maybe js and css.
IMHO they should just live on their own package under the application
structure. This way they would not interfere with the base application
structure and also third parties widget will be easily deployable as a
new package on the widget directory.
On this scenario quickstart should not only copy on the tg app widgets
template but also widget definition class, js and css:
apppackage
|_ controllers.py
|_ model.py
|_ templates/
|_ widgets/
|_ form/
|_ __init__.py
|_ template.kid
|_ style.css
|_ scripts.js
|_ textfield/
|_ __init__.py
|_ template.kid
|_ style.css
|_ scripts.js
...
and so on. This also avoids what I have described before that badly
mixes application's template with widget's template.
Installing a new widget should be as easy as adding a new subpackage to
the widgets directory.
Just food for thoughts.
Ciao
Michele
