Plain old stable components vs. "future" components.
Leandro Lucarella
I'm starting a new project in TG. I've followed very closely this list in
the past, even submitting some patches, but I never ended up using TG for
anything serious (just played with it), so I have (or had =) a pretty well
idea of how TG works, but no real-world background on it.
I've started to follow the list a little more closely about a week ago,
and saw the IRC log about 1.0, and I'm wondering what is the state of the
"future" TG components. Right now I don't really know what to use: SA or
SO? Kid or Genshi? SA and Genshi are the future, as they say, so I really
prefer going with this two (I don't want to "port" my app in the future or
reach to a moment when I realize SO or Kid are not powerfull enought). On
the other hand, if I use this 2 components, I have less documentation (at
least about TG integration), I have less comunity support (I guess there
is more people using SO and Kid), and I have less "features" (I still
depend on Kid for existing widgets, I have no Catwalk, and I don't know
what other cool features are not implemented using Genshi/SA, what about
FastData for example?) which can be pretty important to me because I will
probably need a very quick working prototype, at least for the CRUD part
of the application.
I don't even know if TG now uses ToscaWidgets or it keeps its own Widgets
implementation, and in the last case, I have the same problem with widgets
(I guess ToscaWidgets will be the future if they are not used in 1.0, and
I think this is the case because there is no Debian package
python-toscawidgets yet ;).
Well, my question then is: what do I do? :)
What I'm missing using any of the "future" components? How much unpleasant
my life will be if I stick to the "future" components? How much limited
are the actual "standard" components and how hard/easy will be to "port"
and old app to the new components when they become the new "standard"
ones?
I hope this is not too much to ask =)
Resources on how to use TG with this "future" components are welcome too.
TIA!
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
.------------------------------------------------------------------------,
\ GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05 /
'--------------------------------------------------------------------'
No existe nada más intenso que un reloj, ni nada más flaco que una
bicicleta. No intenso como el café, ni flaco como escopeta.
-- Ricardo Vaporeso
Karl Guertin
> <snip discussion>
You've basically got the idea. TurboGears 1.0 is Kid and SQLObject. If
those don't fit your needs, you can swap them out with something else.
During the push to 2.0 (which is only in the planning stages at the
moment), the cool things will move from happening on Kid/SO to
Genshi/SA.
> I have less "features" (I still
> depend on Kid for existing widgets, I have no Catwalk, and I don't know
> what other cool features are not implemented using Genshi/SA, what about
> FastData for example?
FastData is SO/Kid only as well but it's more an experiment and AFAIK
not really recommended for production. That's the list of features
that do not work in substituted components.
> I don't even know if TG now uses ToscaWidgets or it keeps its own Widgets
TurboGears will not move to ToscaWidgets till 2.0. ToscaWidgets is the
TurboGears widgets spun off into their own package. There are a few
API changes in order to allow widget definitions in template langauges
other than Kid.
> Well, my question then is: what do I do? :)
Kid/SO is the official recommendation for 1.0. If you have a good
reason to use SA or Genshi, go ahead. You will have to make a number
of changes to go from TG 1.0 to TG 2.0 regardless of which you use.
The migration from Kid to Genshi is pretty painless. The SO to SA
migration depends on how you're using SO and the size of your project.
The more queries you have scattered around, the more difficult it'll
be.
There's a lot of discussion about different components, and there
probably always will be. The future components are, IMO, clearly
better than the ones they're replacing but not everything works
correctly when you're using them. If you don't mind digging into the
TG source, that's not a problem. If it is a problem, I'd recommend
sticking with the defaults.
gasolin
sprint,
and produce some solid guide about the discussion result.
It's time to do something for this situation.
Christopher Arndt
Well, this is a bit of a scrape we're in here:
- on one hand people are complaining that some of the existing features of TG
1.0 are not properly documented yet and request that we concentrate our efforts
on smoothing out what we have now.
- on the other hand people are complaining that they can't use all the new and
shiny features yet, because they are not properly documented.
I think we should listen only to the the first bunch for the moment.
Chris
Jorge Godoy
> "future" TG components. Right now I don't really know what to use: SA or
> SO? Kid or Genshi? SA and Genshi are the future, as they say, so I really
> prefer going with this two (I don't want to "port" my app in the future or
> reach to a moment when I realize SO or Kid are not powerfull enought). On
So you have to give us more information. If you know how to use SA and
Genshi, then go with them. You'd have some extra steps to get things working
(e.g. using "${ET(my_widget())}" instead of "${my_widget()}" to display
widgets on your templates) but things work. You'd miss CatWalk with SA. If
you don't use it, then there's no problem (I don't use it even with SO, so
this wouldn't matter to me...).
> the other hand, if I use this 2 components, I have less documentation (at
> least about TG integration), I have less comunity support (I guess there
> is more people using SO and Kid), and I have less "features" (I still
> depend on Kid for existing widgets, I have no Catwalk, and I don't know
> what other cool features are not implemented using Genshi/SA, what about
> FastData for example?) which can be pretty important to me because I will
FastData is experimental even for SO + Kid. You'd have to work on them
anyway.
> probably need a very quick working prototype, at least for the CRUD part
> of the application.
It isn't all that hard to get this to your application. It is a bit harder to
get a good implementation for something generic as FastData aims to be. ;-)
> I don't even know if TG now uses ToscaWidgets or it keeps its own Widgets
> implementation, and in the last case, I have the same problem with widgets
> (I guess ToscaWidgets will be the future if they are not used in 1.0, and
> I think this is the case because there is no Debian package
> python-toscawidgets yet ;).
They will be future. They are not 1.0.
> Well, my question then is: what do I do? :)
Either decide on your own or roll your specs here so that we can advise you.
Just guessing or giving random answers might cause you more harm than good.
> What I'm missing using any of the "future" components? How much unpleasant
> my life will be if I stick to the "future" components? How much limited
> are the actual "standard" components and how hard/easy will be to "port"
> and old app to the new components when they become the new "standard"
> ones?
We'll try to maintain as much backwards compatibility as possible. You'll be
able to use Kid when Genshi becomes default. And you'll be able to use SO
when SA becomes default.
Moving from Kid to Genshi is documented at its website. There are plenty of
resources for SA on its website as well and using it with TG isn't all that
hard (just go with plain SA instead of ActiveMapper...).
> I hope this is not too much to ask =)
It is too little to advise a project decision. It is not too much just for
chatting.
--
Jorge Godoy <jgo...@gmail.com>
Mark Ramm
the "current turbogears" than I have the "future". But I think the
future is the future, and the present belongs to SQLObject and Kid.
SO and Kid are good enough for most web applications most of the time.
Not only that, if you stay with the defaults, you'll find better
documentation, better tested projects, and you'll get a defined
upgrade path when the future comes.
On the other hand, I love SQLAlchemy, and if you have complex, legacy
databases, you will too.
Genshi is very nice but the cases where you _need_ it over Kid are
much fewer and farther between.
So, in spite of the prevailing wisdom on the list, I'd say go with the
defaults unless you have a reason not to.
--Mark Ramm
jose
>
> On 1/8/07, Leandro Lucarella <lu...@llucax.com.ar> wrote:
>
>> <snip discussion>
>
>
>
> The migration from Kid to Genshi is pretty painless. The SO to SA
> migration depends on how you're using SO and the size of your project.
> The more queries you have scattered around, the more difficult it'll
> be.
>
... and what about migration from actual widgets to ToscaWidgets?
jo
jose
>Leandro Lucarella <lu...@llucax.com.ar> writes:
>
>
>
> So you have to give us more information. If you know how to use SA and
>
>Genshi, then go with them. You'd have some extra steps to get things working
>(e.g. using "${ET(my_widget())}" instead of "${my_widget()}" to display
>widgets on your templates) but things work. You'd miss CatWalk with SA.
>
can we expect an integration with CatWalk and SO in the version 2?
jo
Jorge Godoy
> can we expect an integration with CatWalk and SO in the version 2?
From what I remember of the logs of the IRC talk CatWalk would be replaced
with FastData. Am I correct? Anyway, as I said, I don't use CatWalk, so I
don't pay much attention to it.
--
Jorge Godoy <jgo...@gmail.com>
Christopher Arndt
> can we expect an integration with CatWalk and SO in the version 2?
From recently looking at the source code of CatWalk it seems that it is very
closely coupled to SO if not in principle but in practice. One example is the
JavaScript that generates form fields from data objects, that examines the SO
column types. Another is that there is no clean separation between controller
code and data layer access.
Conclusion: SA CatWalk would need an almost complete re-implementation but the
design principles could be kept. But it would probably be better to design an
admin tool so that support for different ORMs can be easily added by some kind
of plug-in.
I guess, if we wanted an admin tool that works with several ORMs we'd have to
define yet another data access layer/api that defines a subset of the features
(i.e column types, query methods, getters/setters) in all supported ORMs.
On top of that, one could put a generic CRUD controller, which would detect the
attributes of a given data object and dynamically build data grids, form
widgets and validators for it (possibly allowing customization by overriding
some class variables).
I have actually considered starting such a thing (inspired by the django admin)
and experimented a bit, but have not gotten very far yet.
Chris
Leandro Lucarella
Jorge Godoy, el 9 de enero a las 09:03 me escribiste:
> > the other hand, if I use this 2 components, I have less documentation (at
> > least about TG integration), I have less comunity support (I guess there
> > is more people using SO and Kid), and I have less "features" (I still
> > depend on Kid for existing widgets, I have no Catwalk, and I don't know
> > what other cool features are not implemented using Genshi/SA, what about
> > FastData for example?) which can be pretty important to me because I will
>
> FastData is experimental even for SO + Kid. You'd have to work on them
> anyway.
How experimental is it? I remember long ago using FastData (just for quick
prototyping or very simple CRUD, of course). Even so, most of my patches
were for FastData (to make it more configurable mostly), when FastData was
part of TG (now it's a separate package, right?).
> > I hope this is not too much to ask =)
>
> It is too little to advise a project decision. It is not too much just for
> chatting.
Of course, it's just chatting, I'm just collecting opinions, I will not sue
anybody if I follow the advices and something goes wrong ;)
I think SO and Kid would be enough for my project (even so, it's a
partially rewrite of a former project that uses SO), but my deepest fear
is to soy in the middle of the project "damn! this would be so much easy
with <insert your "future" component here>". And well, since I'm allready
rewriting, I thought maybe it could be a good time to make the leap from
SO to SA, so I don't have to do it in the future.
I'm still not convinced on what path to take. So, resuming what I'm missing
using the new components:
1) Forget about FastData
2) Forget about Catwalk
3) Still need Kid for widgets
4) Live with less documentation/support/examples
I'm missing something?
--
LUCA - Leandro Lucarella - Usando Debian GNU/Linux Sid - GNU Generation
------------------------------------------------------------------------
E-Mail / JID: lu...@lugmen.org.ar
GPG Fingerprint: D9E1 4545 0F4B 7928 E82C 375D 4B02 0FE0 B08B 4FB2
GPG Key: gpg --keyserver pks.lugmen.org.ar --recv-keys B08B4FB2
------------------------------------------------------------------------
... los cuales son susceptibles a una creciente variedad de ataques previsibles,
tales como desbordamiento del tampón, falsificación de parámetros, ...
-- Stealth - ISS LLC - Seguridad de IT
Jorge Godoy
> How experimental is it? I remember long ago using FastData (just for quick
> prototyping or very simple CRUD, of course). Even so, most of my patches
> were for FastData (to make it more configurable mostly), when FastData was
> part of TG (now it's a separate package, right?).
I don't use it as well, so I can't answer. Let me just say that it was
removed from TG's core because there was too little there and no maintenance.
> Of course, it's just chatting, I'm just collecting opinions, I will not sue
> anybody if I follow the advices and something goes wrong ;)
;-) It would be hard depending on someone's country... :-)
> I think SO and Kid would be enough for my project (even so, it's a partially
> rewrite of a former project that uses SO), but my deepest fear is to soy in
> the middle of the project "damn! this would be so much easy with <insert
> your "future" component here>". And well, since I'm allready rewriting, I
> thought maybe it could be a good time to make the leap from SO to SA, so I
> don't have to do it in the future.
It is one thing that might be worth. SA is more powerful and does some things
better. It is different from SO, though. You have to be more verbose (what I
like about it...). It requires you more SQL knowledge.
> I'm still not convinced on what path to take. So, resuming what I'm missing
> using the new components:
>
> 1) Forget about FastData
> 2) Forget about Catwalk
> 3) Still need Kid for widgets
> 4) Live with less documentation/support/examples
>
> I'm missing something?
LOL... I think you got the main points. I haven't stopped to think too much
about it (even though I consider switching things for some projects my time
constraints are too tight for that *now*).
--
Jorge Godoy <jgo...@gmail.com>
Alberto Valverde
On Jan 9, 2007, at 2:49 PM, Christopher Arndt wrote:
>
> jose schrieb:
>> can we expect an integration with CatWalk and SO in the version 2?
>
> From recently looking at the source code of CatWalk it seems that
> it is very
> closely coupled to SO if not in principle but in practice. One
> example is the
> JavaScript that generates form fields from data objects, that
> examines the SO
> column types. Another is that there is no clean separation between
> controller
> code and data layer access.
>
> Conclusion: SA CatWalk would need an almost complete re-
> implementation but the
> design principles could be kept. But it would probably be better to
> design an
> admin tool so that support for different ORMs can be easily added
> by some kind
> of plug-in.
That's the idea for FastData. As you've said, CatWalk is so tightly
coupled with SO that a *extensible* replacement is needed.
>
> I guess, if we wanted an admin tool that works with several ORMs
> we'd have to
> define yet another data access layer/api that defines a subset of
> the features
> (i.e column types, query methods, getters/setters) in all supported
> ORMs.
I've been playing with a skeleton of this using generic functions,
both to create widgets for complete objects or it's attributes
(mapped columns, joins, etc). The idea is that the if the widget
creating generic function doesn't know how to handle a given object,
it will try to automatically create a widget based on it's
attributes. This should allow for easy extensibility of the "admin"
interface. If you're interested email me off-list and i can give you
a svn url.
>
> On top of that, one could put a generic CRUD controller, which
> would detect the
> attributes of a given data object and dynamically build data grids,
> form
> widgets and validators for it (possibly allowing customization by
> overriding
> some class variables).
>
> I have actually considered starting such a thing (inspired by the
> django admin)
> and experimented a bit, but have not gotten very far yet.
That's very cool! :) Maybe you'd like to contribute or be a father to
FastData v2? If so then the trunk ML is probably the best place to
discuss it.
Alberto
Alberto Valverde
On Jan 9, 2007, at 3:29 PM, Leandro Lucarella wrote:
>
> I'm still not convinced on what path to take. So, resuming what I'm
> missing
> using the new components:
>
> 1) Forget about FastData
> 2) Forget about Catwalk
Or help out bring out a new version... ;)
> 3) Still need Kid for widgets
Not for ToscaWidgets
> 4) Live with less documentation/support/examples
I'm afraid so... but many users/tg-devs are already using the new
components so you'll get plenty of help here on n the trunk ML.
Alberto
Leandro Lucarella
>
>
> On Jan 9, 2007, at 3:29 PM, Leandro Lucarella wrote:
> >
> > I'm still not convinced on what path to take. So, resuming what I'm
> > missing
> > using the new components:
> >
> > 1) Forget about FastData
> > 2) Forget about Catwalk
>
> Or help out bring out a new version... ;)
I have no time for now, but I don't discard it in the future, as I said,
from the few patches I contributed to TG, most were for FastData =)
> > 3) Still need Kid for widgets
>
> Not for ToscaWidgets
So it's possible to use ToscaWidgets with TG now? If so, I guess I should
add:
5) Forget about widget browser
right? ;)
> > 4) Live with less documentation/support/examples
>
> I'm afraid so... but many users/tg-devs are already using the new
> components so you'll get plenty of help here on n the trunk ML.
Ok, great. If things didn't change so much here, TG community it's a great
support (and I'm used to live without much documentation) so this is not a
big issue.
--
LUCA - Leandro Lucarella - Usando Debian GNU/Linux Sid - GNU Generation
------------------------------------------------------------------------
E-Mail / JID: lu...@lugmen.org.ar
GPG Fingerprint: D9E1 4545 0F4B 7928 E82C 375D 4B02 0FE0 B08B 4FB2
GPG Key: gpg --keyserver pks.lugmen.org.ar --recv-keys B08B4FB2
------------------------------------------------------------------------
Corrí muchas carreras, tratando de alcanzarte a vos.
Pero corría sólo y siempre salí último.
Alberto Valverde
On Jan 9, 2007, at 4:40 PM, Leandro Lucarella wrote:
>
> Alberto Valverde, el 9 de enero a las 15:50 me escribiste:
>>
>>
>> On Jan 9, 2007, at 3:29 PM, Leandro Lucarella wrote:
>>>
>>> I'm still not convinced on what path to take. So, resuming what I'm
>>> missing
>>> using the new components:
>>>
>>> 1) Forget about FastData
>>> 2) Forget about Catwalk
>>
>> Or help out bring out a new version... ;)
>
> I have no time for now, but I don't discard it in the future, as I
> said,
> from the few patches I contributed to TG, most were for FastData =)
>
>>> 3) Still need Kid for widgets
>>
>> Not for ToscaWidgets
>
> So it's possible to use ToscaWidgets with TG now? If so, I guess I
> should
> add:
Yep, there's an example in the ToscaWidgets tarball at examples/
tgsample both using kid and genshi as page templates.
>
> 5) Forget about widget browser
>
> right? ;)
If using TW, yes. However, a widget browser for TW is a planned feature.
>
>>> 4) Live with less documentation/support/examples
>>
>> I'm afraid so... but many users/tg-devs are already using the new
>> components so you'll get plenty of help here on n the trunk ML.
>
> Ok, great. If things didn't change so much here, TG community it's
> a great
> support (and I'm used to live without much documentation) so this
> is not a
> big issue.
Alberto
Alberto Valverde
Shouldn't be too difficult either. Most of the API is compatible and
has the same method/attribute names, you can also still use Kid if
you don't want to port the templates to Genshi yet (and should allow
using those widgets in genshi templates)... However, the way
compound widgets are built is different in TW (easier IMO) so
compound widget's will need to be tweaked. IMO, the API is easier and
more flexible in TW.
All widgets under turbogears.widgets.forms have been ported as well
as both calendars (though i18n is broken as it was dependent on TG
and TW where designed not to require TG). You can take a look there
and see how it differs from tg widgets to get an idea. I'm planning
on providing some rich widgets (using jQuery) in the twForms so I
won't be porting myself TG's Ajax widgets.
The class hierarchy for form widgets has been greatly simplified but
has changed, so widget's inheriting from form fields should be
adapted. It took me about 2 hours to port all widgets under forms to
TW so I'll say it's quite easy (well, I wrote the code so take that
with a grain of salt... ;)
Alberto
BTW, I'm guilty too for not following it but... ToscaWidgets are
targeted for 2.0 (though they can be used in 1.0) so it's best to
discuss them at the trunk ML in order to not confuse 1.0 users.
iain duncan
+1 from me on that. ( As I have already indicated in my rantings, ha
ha )
We need to get a usable solid system that can be *relied* on to behave
exactly as it is documented and work all the time in production
scenarios. Feature creep is a great way to prevent this from happening.
Iain