what to do about toscawidgets?
iain duncan
TW. It seems like a real wildcard right now in the TG2 future. I
personally think that if we are to pick TW, we need more people on it
than just Alberto because it's complicated, and he's busy. ( For which I
can 100% sympathize.)
Problem is, when TW works, it's wicked cool. When it doesn't, or you
can't figure it out, it's like the TG version of mod_rewrite, confusing
voodoo that scares away small children and kills your app dead just when
you thought everything was going to work. Right now, it is ( I think )
being perceived as languishing, it got too much attention before being
ready for prime time I guess, and Alberto's life got in the way. So it's
being dismissed by Pyloners and others and that is too bad because it
allows some really nice patterns with SA, the way you can add properties
in objects that map automatically to the widget fields and so forth.
I'm hoping to work on DBSprocket/Mechanic and TW and their docs in the
not-too-distant future ( March on I think, current albatross is getting
closer to dead ) but if I'm going to invest a lot of time in digging in
to that code I would want to be sure that it's not just going to be
abandoned, and it pains me to see discussion on other lists where people
are saying that what TW does is not worth the pain of the docs and rough
edges.
Problems I see:
- needs to work with new formencode and whatever data we chuck at it
- needs to be easier to get up and running with minimal pain
- needs better api ref and examples and tutorials
- changing/controlling templating options needs to be better
- some weird monkey patching issues need to be either smoothed out, or
eradicated ( ie, the voodoo of adding FilteringSchema if on TG, huh? )
So, um, what am I asking? Uh, who's interested? Thoughts? Can we change
how this aspect of TG is being run? Alberto, should we try to change
this into a more team effort? Give Chris P more reigns as he seems to be
on a crazy ass work spree?
We need mystery step two here before profit! I feel like widgets is the
giant TG secret weapon in the barn that most people are afraid to use
because it killed those pigs last summer and the manual got all covered
in corn mash and only old Joe from up the hill what's really going in
there and so the others wonder why we keep hanging around that scary
looking barn anyway ...
Thanks for listening to my drivel,
Iain
Kevin Horn
The "fooball tutorial" (which has since become this page: http://docs.turbogears.org/1.0/IntroductionToWidgets) is what really turned the lights on for me.
As for TW, I really don't understand all of the many things that it can do, and how all the pieces fit together. What does the middleware do? What are the HostFramework pieces for? How do I set them up?
I think good docs, and especially tutorials or other simple explanations on how to actually use TW would be extremely valuable. Right now, my impression (correct or otherwise) is that I'd need to dig into the TW source in order to get anything going with them. Alberto's "beta site" (http://beta.toscawidgets.org/) is a step in the right direction, but I think more needs to be done. Even a few good blog posts or docs pages would be extremely helpful.
Some topics that should be covered:
- how to set up ToscaWidgets with TG1, TG2, Pylons, etc.
- how to use existing widgets (ones from TW and twForms - an equivalent to the old widget browser might be useful...I know one was in the works at one point)
- how to create your own widgets (both display and form widgets)
- how to get data back from widgets when a form is submitted
- parent/child widgets (which is supposedly the biggest advantage of TW over TGWidgets, but I'm vary hazy on how it all works
- using params (and update_params) with widgets (lot's of people still have trouble with this in TGWidgets)
- validation with widgets (IMPORTANT)
Finally I have to say I agree totally that widgets are the "killer feature" of TG for me. When I first started using TG (before TGWidgets existed), it was mostly just to be able to use Python in the webapp space. Once widgets came along and once I "got" them, they've become just about my favorite feature. I curse audibly whenever I have to use a language or framework that doesn't have them. I really think they are key to TG's success, and we need to do whatever is necessary to keep them alive.
Kevin Horn
BTW, loved the "secret weapon in the barn" bit.
iain duncan
> I haven't dealt with TW too much yet, for several of the above
> reasons, but I will say this. TG1 Widgets really didn't click for me
> until I ran through a few tutorials. I just really didn't see the
> value until I could actually SEE the value, if you see what I mean.
> Finally I have to say I agree totally that widgets are the "killer
> feature" of TG for me. When I first started using TG (before
> TGWidgets existed), it was mostly just to be able to use Python in the
> webapp space. Once widgets came along and once I "got" them, they've
> become just about my favorite feature. I curse audibly whenever I
> have to use a language or framework that doesn't have them. I really
> think they are key to TG's success, and we need to do whatever is
> necessary to keep them alive.
This is sooo true! When people ask me why I like TG so much, I'm all
like "ah widgets + formencode + SA rock, but uh, maybe come back and
read about widgets in a month or two? crap! :/"
> BTW, loved the "secret weapon in the barn" bit.
Thanks!
Iain
Mark Ramm
There was some talk about ripping newforms out of Django and using
that, but I think we're pretty committed to ToscaWidgets.
We do need to add another couple core TW committers before I'll feel
really happy about the dependency. I'm personally a bit wary of
having TG2 dependencies with a truck number < 3 (The truck number is
the number of team-members that could be hit by a truck without the
whole thing falling apart irrevocably. (See also:
http://www.jaredrichardson.net/blog/2005/08/02/)
In the case of ToscaWidgets it looks like Alberto has everything in
his head, but I know a couple of people (florent, and chris) who seem
to be able to navigate their way around pretty well. I know both of
them are running other major projects (TG1 and DBSprockets), but I'm
at least not as worried as I was before. But I would like to see
another core developer on TW, and I'd like to see somebody step up and
work on TW docs.
Fundamentally, at this point I think my only reservation about TW has
to do with the Docs. If there were more docs, there would be more
users, if there were more users bugs and corner cases would be found
and eliminated, and TW would be in good shape. So, if you are
willing to work on docs, I think we should consider committing
ourselves 100% to TW ;)
--Mark Ramm
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
iain duncan
> Thanks for bringing all this up.
>
> There was some talk about ripping newforms out of Django and using
> that, but I think we're pretty committed to ToscaWidgets.
I am +1 on trying hard to get TW polished before the above. We already
have great tutorials now from Chris A and Lee and others that work in
95% similar manner. No way should we waste that. And Alberto knows
pylons and is serious about making it work on both, also important.
>
> We do need to add another couple core TW committers before I'll feel
> really happy about the dependency. I'm personally a bit wary of
> having TG2 dependencies with a truck number < 3 (The truck number is
> the number of team-members that could be hit by a truck without the
> whole thing falling apart irrevocably. (See also:
> http://www.jaredrichardson.net/blog/2005/08/02/)
>
> In the case of ToscaWidgets it looks like Alberto has everything in
> his head, but I know a couple of people (florent, and chris) who seem
> to be able to navigate their way around pretty well. I know both of
> them are running other major projects (TG1 and DBSprockets), but I'm
> at least not as worried as I was before. But I would like to see
> another core developer on TW, and I'd like to see somebody step up and
> work on TW docs.
>
> Fundamentally, at this point I think my only reservation about TW has
> to do with the Docs. If there were more docs, there would be more
> users, if there were more users bugs and corner cases would be found
> and eliminated, and TW would be in good shape. So, if you are
> willing to work on docs, I think we should consider committing
> ourselves 100% to TW ;)
I am willing to commit to work on docs IFF:
- It can wait till March, my sig other is at school and my margins are
financially suicidal right now. Must finish killing albatross this month
- I can get questions answered pretty quick, the code is definitely a
stretch past my level of just groking from the source, Alberto?
- Chris P is commited to ToscaWidgets for DBSprockets. It seems like
this is the case, Chris can you weigh in on this? Chris's dedication and
approach to DBSM ( ha ha! new nickname! oh I kill me ... ) is very
impressive and if he is committed to TW then I am more comfortable
committing to it hoping it won't be a collapsed barn
- we get more developers with full access to tw repository so that if we
find issues people like Chris and Florent can just fix 'em as they see
fit ( maybe this is already the case? I dunno, same issue as Mark's )
Lee also expressed an interest in TW recently. I really believe if we
can get TW on a better path it can be awesome. But we really really need
to fix that barn before TG2.
( Insert plug for Karl Vogels "Producing Open Source Software",
fantastic read.)
iain
percious
> that, but I think we're pretty committed to ToscaWidgets.
DBSprockets. Django is on my proverbial chopping block.
> We do need to add another couple core TW committers before I'll feel
> really happy about the dependency. I'm personally a bit wary of
> having TG2 dependencies with a truck number < 3 (The truck number is
> the number of team-members that could be hit by a truck without the
> whole thing falling apart irrevocably. (See also:http://www.jaredrichardson.net/blog/2005/08/02/)
givey. I already have one change to make TW Grok/Zope compatible. I
agree, Alberto is busy.
>
> In the case of ToscaWidgets it looks like Alberto has everything in
> his head, but I know a couple of people (florent, and chris) who seem
> to be able to navigate their way around pretty well. I know both of
> them are running other major projects (TG1 and DBSprockets), but I'm
> at least not as worried as I was before. But I would like to see
> another core developer on TW, and I'd like to see somebody step up and
> work on TW docs.
used similar design patterns in DBSprox. I can help explain how
things work as much as possible, I just can't write docs for someone
else's project and produce 4000+ lines of code in 2 months. I have
someone helping me with the DBSprox dox, maybe I can get him to help
with TW once he comes up to speed.
>
> Fundamentally, at this point I think my only reservation about TW has
> to do with the Docs. If there were more docs, there would be more
> users, if there were more users bugs and corner cases would be found
> and eliminated, and TW would be in good shape. So, if you are
> willing to work on docs, I think we should consider committing
> ourselves 100% to TW ;)
>
> --Mark Ramm
>
DBSprockets.Primitives more. There *will* be good documentation for
that. I promise.
percious
documentation for DBSprockets when the messages popped up!
http://code.google.com/p/dbsprockets/wiki/DevelopmentEnvironment
Anyway.
> - Chris P is commited to ToscaWidgets for DBSprockets. It seems like
> this is the case, Chris can you weigh in on this? Chris's dedication and
> approach to DBSM ( ha ha! new nickname! oh I kill me ... ) is very
> impressive and if he is committed to TW then I am more comfortable
> committing to it hoping it won't be a collapsed barn
DBSprockets. DBSprockets doesn't care which engine to use. (I
separated ValidatorSelector and WidgeSelector for a reason) I think
Toscawidgets, and the magic it contains is THE BEST solution
available.
And I have NO problem with people writing dox for me. Come and join
my team Ian.
> - we get more developers with full access to tw repository so that if we
> find issues people like Chris and Florent can just fix 'em as they see
> fit ( maybe this is already the case? I dunno, same issue as Mark's )
- some weird monkey patching issues need to be either smoothed out,
or
eradicated ( ie, the voodoo of adding FilteringSchema if on TG, huh? )
my code for TG1 DBmechanic. It was a good thing I knew about it from
back when I was writing TW all the time. The good news is that that
particular voodoo is not needed in TG2/Pylons because TW is wsgi
complient.
percious
own thoughts on the subject.
First off, we are concentrating on what is WRONG with TW, not what is
right, or what has been done BETTER than the competitors. If we
seriously jam on what the features of TW are we will end up with some
pretty damn good documentation.
Ok. The reason people are blown away (or down) by TW is the
complexity. This is why DBMechanic Primitives came to be. I am going
to purposefully freeze the specs on the makeForm and makeTable
functions. WHY?
I want people to use toscawidgets to extend Primitive forms. I left a
gaping wide hole for someone to add their own use-specific widgets,
and if people start using the Primitives they will see the limitations
and start using Toscawidgets to get the solutions they want. This is
very much a Foot in Door approach. (As apposed to the Door in Face
approach to DBSprockets.api, but that my friend is another story)
Right now, besides docs, TW needs to look pretty. That's right, we
need Ajax.
Currently twAjaxTools is a crazy bit of code written by Claudio that
works awesome in TG1. It will not work in TG2. It's also very hard
to understand what is happening in the actual code, but what it
basically does is modify the TG controller to add methods for use in
the sending and receiving of JSon data. Sound Familiar? Right,
Middleware. This code needs a re-write desperately for Toscawidgets,
and probably DBSprockets to survive. Who will join me in this fight?
cheers.
-chirs.