iain duncan wrote:
> > 1) tg-admin quickstart -tgwidget mywidget
> >
> > This will get you the basic layout for a widget egg.
> >
> > 2) Place your static resources in the static directory and register
> > them with turbogears.widgets.register_static_directory
> >
> > 3) Write, test and debug the widget.
> >
> > If you "python setup.py develop" it, it will appear in the widget
> > browser at the toolbox
> >
> > 4) python setup.py register bdist_egg upload
> >
> > To register it at PyPI. The metadata tg-admin places at setup.py will
> > enable the cogbin to find it and list there along with the other
> > widgets.
> >
> > 5) Announce it here to let all of us know of it's existence :)
>
> Do you have these instructions on the TGWidget site? Looking forward to
> digging into that.
Not yet. Those instructions are targeted for the widget library already
bundled with TG. Instructions for TGWidgets would be slighly different
(no need to register static directories, for example) and are yet
half-implemented (no widget descriptions for the browser at the
toolbox).
Currently the best place to get information on this is reading
"setup.py" and "widgets.py" inside an egg-distributed widget. Normally
they're really short and simple, it's not like digging inside
RuleDispatch... ;) (no offense whatsoever meant here! I really like
that lib. and have learned a lot of python-foo from the 0.2% of the
code I managed to understand there :) )
BTW, TGWidgets docs still pretty much suck. They're still less than
half-baked and I'm continually tweaking them based on the feedback a
project I'm using them with is giving me. I wouldn't yet recommend
basing any serious stuff on them (thought I would love the feedback a
bored tinkerer could give me :) )
> BTW, how do I set the class and id for a stock widget? I'm sure it's in
> there somewhere but I'm not finding it.
The class can be set through the "field_css" parameter FormFields
receive. You can also add extra classes in the "css_classes" list
parameter.
The id cannot be directly set but it's calculated from the name of the
widget ("name" kw. arg. or, usually, first positional arg.) and it's
path (ie.: form_fieldset_name). There was a patch
(http://trac.turbogears.org/turbogears/ticket/902) to allow the
field_id to be overriden but It finally didn't make it in due to lack
of usefulness at the moment. FYI, this has been "fixed" in TGWidgets
and has been one of the main motives (beside decoupling them form TG)
of the little API change I made there... it was really annoying to me
because I didn't like to insert JS code in the widget's template which
is the only place you can put it if you need to know the "real" id that
a widget will have (for event handling, etc...).
Alberto
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
