Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Stepping back from tw2

53 views
Skip to first unread message

Ralph Bean

unread,
Feb 14, 2014, 9:42:37 AM2/14/14
to toscawidge...@googlegroups.com
Hello all,

I already brought this up in irc, but I think I need to step back from
tw2 for the time being. We're using tw2 less at work and I'm being
pulled in other directions (family! :p). In practice, I haven't
really been participating as fully over the past year, so this email
doesn't really signal any further change, just a formalization of what
has already been underway.

I'm writing, though, to make sure that I'm not holding any keys or
blocking anyone from pushing tw2 through its next steps forwards. If
it is discovered later that I have access to something that no one
else does, I should be reachable by email so we can unlock it. I've
checked, and all of my PyPI entries have multiple owners at the moment
(a good thing).

I will also still maintain http://tw2-demos.threebean.org/. (I have
nagios pointed at it so I'll know if it falls over). If anyone is
interested in setting it up elsewhere, I'd be glad to put a redirect
in place.

Anyways, I'll still be around and on the list. Hope to see some of
you at PyCon 2014 in Montréal!

Cheers-
-Ralph

Moritz Schlarb

unread,
Feb 14, 2014, 4:39:58 PM2/14/14
to toscawidge...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ralph,

that's pretty sad, but understandable...

About tw2-demos, couldn't we try to make use of the Travis CI
deployment functionality so that all Github organization members could
update it, in case the need arises.
We would then need a Heroku or OpenShift instance for that, or a
self-hosted PaaS solution somewhere on the toscawidgets.org machine?

What do you others think?

Cheers,
Moritz
- --
Moritz Schlarb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS/o0uAAoJEEXT29373YiIV4QH/1Px7Wi9mlSiK3R48sXdWgz1
huqd5RbqYQtIiSASUma90vMhMekwJUsLZkL3vAQmD2lH9XAahjYzvA9A+KhoeVQK
P8Aiu4PwVS5K6SOda9AdX+PYVZGVwfZUdiNJ2Vo97+1HleeIFTK8z3rUZsbamVTo
wjAuQjK/2+e1fSRka2toIFgv4/kfg7DcMiswIesLTa8hWYMDLGDDLTucxzQnRVJp
+VhOWEyaIChOsRyfvnP/SHLvnIc+W6Y4NHMjdjZddah5LxJxRtMuoTNgqT2XU2Y/
lNzEO2U2sQbt+ZnspLy1fpXIcYbqrWh4ISRNYqmkkjNL8nS9o+TxbRB55KauDVA=
=jMFo
-----END PGP SIGNATURE-----

Paul Johnston

unread,
Mar 2, 2014, 5:58:12 PM3/2/14
to toscawidge...@googlegroups.com
Hi,

Ralph, I'm sorry to see you go! Thanks for all your contributions, they have kept the torch burning.

ToscaWidgets has been an interesting ride for me and I've learned a lot. It has become less of a priority for me in recent years. There are two main problems: ToscaWidgets is no longer innovative (back in 2007 it was quite cutting-edge), and we have failed to build a critical mass of community around the project.

There are now a number of widget libraries with a broadly similar design to ToscaWidgets, including Django forms. But worse than that, ToscaWidgets has not kept pace with the massive innovations in client-side frameworks (AngularJS and the like). tw2 doesn't even support client-side validation, which makes it feel pre-historic.

Looking back, I think we did three main things wrong:

1) Focus on technical work, not project management. There was a lot of work from Ralph, Percious and me, but it wasn't always co-ordinated. And we didn't really mobilise a broader pool contributors, who may have contributed documentation, bug fixes, and minor fixes - if they had been encouraged more.

2) Kept the alpha status far too long. What we've got now I should have said was release quality back in 2010 (maybe even earlier). I'd kept the alpha badge because I know some parts of the API need a compatibility-breaking refactor. But that would have done for a 2.2 release.

3) Tried to support too many use cases. Trying to support multiple template engines, JavaScript libraries, ORMs, etc. We just spread our effort too thinly. We should have just said: Chameleon, jQuery, SqlAlchemy - that's the ToscaWidgets stack. TurboGears has a similar problem here, but it actually affects ToscaWidgets much worse.

Something else I'm conscious of is the whole idea of a "form builder library" is dubious. Ian Bicking said this years ago and I'm coming round to his point of view. You end up adding an extra layer of abstraction, and this limits your flexibility. I also think I've had a bit of an obsession with DRY (don't repeat yourself) which maybe isn't so important. It doesn't seem to kill development to type a few things twice, and doing so often gives you more flexibility.

So where to go now? For me, SPA (single page app) seems clearly the way to go. I realise SPA isn't for everyone, but for the kind of apps ToscaWidgets works well for, most of these will work well as an SPA. Gmail had been released as an SPA some years before I started hacking on ToscaWidgets; I should have seen the future then. There are a few frameworks in this space; I am going with AngularJS. A major consideration is the large and active community. I intend to be a framework user, not a framework developer.

As a stop-gap measure I am adding some JSON support to my experimental tw2 branch (https://github.com/paj28/). This looks at the Accept: header and returns JSON as appropriate. The JSON is generated based on the widget definition. This lets the widgets function as the back-end for an SPA, letting me migrate my applications gradually. I will also be adding support for JSON data in POST requests. However, this is just a temporary measure. In the medium term I will be migrating the back-ends to some kind of REST framework. I intend to have a good look at what's available, and pick something that is actively developed (suggestions welcome).

I still think SQLAlchemy and a relational database (usually Postgres) are an excellent data store. But I am keeping my eye on the NoSQL space. It does seem redundant to have both the application and the data store know the schema of your data, so maybe there will be big changes here too.

I'll still be on the list and will keep toscawidgets.org registered for the foreseeable future.

Paul



--
You received this message because you are subscribed to the Google Groups "ToscaWidgets-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to toscawidgets-dis...@googlegroups.com.
To post to this group, send email to toscawidge...@googlegroups.com.
Visit this group at http://groups.google.com/group/toscawidgets-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

Craig Small

unread,
Mar 3, 2014, 6:28:05 AM3/3/14
to toscawidge...@googlegroups.com
How difficult is it to update the underlying includes to the latest
versions? I use the jqgrid and the jqplot plugins but they both use
pretty old versions of their relevant libraries.

Is it usually a matter of importing the library, repoint the api to
the new location and then try to find what breaks?

> Anyways, I'll still be around and on the list. Hope to see some of
> you at PyCon 2014 in Montréal!
I was in that city almost 20 years ago, its a bit far to travel to now.

- Craig

--
Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/ csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5

Paul Johnston

unread,
Mar 3, 2014, 6:37:01 AM3/3/14
to toscawidge...@googlegroups.com
Hi Craig,

Normally it's just what you say - so easy if the new version if compatible. In addition, percious created a way that users could update the version of the library, without having to wait for the widget maintainer to update it. I can't remember the details right now.

Paul



Alessandro Molina

unread,
Mar 3, 2014, 11:38:01 AM3/3/14
to toscawidge...@googlegroups.com
On Sun, Mar 2, 2014 at 11:58 PM, Paul Johnston <p...@pajhome.org.uk> wrote:
There are now a number of widget libraries with a broadly similar design to ToscaWidgets, including Django forms. But worse than that, ToscaWidgets has not kept pace with the massive innovations in client-side frameworks (AngularJS and the like). tw2 doesn't even support client-side validation, which makes it feel pre-historic.


I tend to agree in part with this, one of the worse parts of TW2 for me is currently the "resources injection".
With highly javascript based pages most of the required resources can only be known by the client itself. Supporting module loaders (and AMD) is a huge missing feature in TW2 that would greatly improve the way it would be possible to create highly dynamic widgets that cope with modern javascript frameworks.

I ended up rolling my own solution in https://bitbucket.org/axant/axf/src/89c55c86c29336babbf3c2e74bbf8abe51e87083/axf/axel.py which is an huge hack but permits to create widgets that load stylesheets and scripts at runtime through the AXEL loader instead of injecting them into the webpage. This joined with the Ractive.JS widgets support ( https://bitbucket.org/axant/axf/src/89c55c86c29336babbf3c2e74bbf8abe51e87083/axf/ractive.py ) made possible for me to solve most of my client side needs.

The same approach would work quite well with AngularJS or similar frameworks, maybe with a different solution and better implementation, but I think that is totally the way to go for the future of TW2.
 

3) Tried to support too many use cases. Trying to support multiple template engines, JavaScript libraries, ORMs, etc. We just spread our effort too thinly. We should have just said: Chameleon, jQuery, SqlAlchemy - that's the ToscaWidgets stack. TurboGears has a similar problem here, but it actually affects ToscaWidgets much worse.


Totally agree with this. If the stack is pluginable enough, support for more frameworks and libraries should be forwarded to third party extensions. Having an official toolkit only makes easier to write documentation and provide a bug free solution while people can still roll their own plugins when something else is needed. 
 
Something else I'm conscious of is the whole idea of a "form builder library" is dubious. Ian Bicking said this years ago and I'm coming round to his point of view. You end up adding an extra layer of abstraction, and this limits your flexibility. I also think I've had a bit of an obsession with DRY (don't repeat yourself) which maybe isn't so important. It doesn't seem to kill development to type a few things twice, and doing so often gives you more flexibility.


Partially disagree with this. While "form builder library" is often a too complex solution for a simple thing (this is the reason why recently my TW2 forms, instead of using Layouts and nesting children, often look like: https://gist.github.com/amol-/d2a08027d34a8c4dfa69 ) the concept of reusable widgets is a powerful one and will only get more important in single page web applications where a proper separation and reuse of Widgets is even more important as you can't rely on separate pages anymore.

Craig Small

unread,
Mar 5, 2014, 6:48:53 AM3/5/14
to toscawidge...@googlegroups.com
On Mon, Mar 03, 2014 at 11:37:01AM +0000, Paul Johnston wrote:
> Normally it's just what you say - so easy if the new version if
> compatible. In addition, percious created a way that users could update
> the version of the library, without having to wait for the widget
> maintainer to update it. I can't remember the details right now.
I suspect it has to do with fiddling with what is in defaults.py or the
things that import that. I tried updating jqgrid and while the stuff
imported fine the grid didn't show.

I suspect that is due to the older jquery.ui, ill adjust that later
and see.
Reply all
Reply to author
Forward
0 new messages