fork the 1.1 branch (and the wish list)?
gas...@gmail.com
merge some enhancement from trunk, such as:
1. internal toolbox code re-structure
this refactor had already appeared in trunk, and it make adding a new
tool more tangible.
2. add genshi-default quickstart generator(template).
It already exist in trunk, but need some trick up to become an extra
tgtemplate.
3. add Template browser in toolbox ..
It already exist in trunk for months.
It's nice to browse kid/genshi template within the toolbox.
4. add crud generator(template)
The default crud generator combines form widgets, subdirectory
importing, and optional paginate, error_handler, identity with
class...it could be a good demonstration and super time saver command
that make explicit and fully customizable CRUD usage.
.....
wishes from other people...
....
So, is it ok for me to branch a project(another code name or 1.1) in
svn to experiment these features?
Kevin Dangoor
Jorge Godoy
> 2. add genshi-default quickstart generator(template).
> It already exist in trunk, but need some trick up to become an extra
> tgtemplate.
Doesn't the "--future" (or something like that) switch do that?
> 4. add crud generator(template)
This is too much of a change and would require much more testing. If we add a
feature it has to work, otherwise there's no reason to include it in a stable
branch.
> So, is it ok for me to branch a project(another code name or 1.1) in
> svn to experiment these features?
There was the need for a 1.1 or 1.0.1... I believe that having a new 1.1
would be better since there are lots of changes here and they are complexier
than what *I* would put into a 1.0.1 or something like that. Of course, I'm
just expressing my opinion and I won't oppose having a 1.0.x with these if
people find it better. :-)
--
Jorge Godoy <jgo...@gmail.com>
Jorge Godoy
> It's definitely a good idea to define where 1.1 development will happen.
>
> If there isn't already 2.0 code on the trunk, I'd recommend using the
> trunk for 1.1 and then create a branch for the more experimental 2.0.
>
> Kevin
I agree... But the trunk has more disruptive and aggressive changes than what
was proposed... Maybe it is better to fork a 2.0 from trunk and a 1.1 from
1.0, merging the things from the trunk / 2.0 branch into 1.1 (aka
backport)...
My main concern is with the stability of what we called stable code :-) And
the introduction of toscawidgets, genshi by default, sqlalchemy, etc. are not
a minor change IMVHO.
--
Jorge Godoy <jgo...@gmail.com>
gas...@gmail.com
We could post those features in separate versions, such as 1.1 for
toolbox re-explore,.1.2 for fastdata or crud... 1.5 for intro the road
to future (genshi, toscawidgets) etc...
1.internal toolbox code re-structure
3. add Template browser in toolbox ..
They are exist code so it needs minimum effort to release a 1.1 alpha
version, new features will attract eyes, and we'd have good chance to
gather more feedbacks.
It could be released in weeks, and I prefer branching from 1.0 for 1.1
version.
Then, someday we need reveal some version to bridge the road toward
"toscawidgets, genshi by default", so I add
"2. add genshi-default quickstart generator(template). "
What I mean is: we keep kid template as default "tg-admin quickstart"
template, and add another genshi-based one for "tg-admin quickstart -t
[genshi]" or something to generate the genshi-default template.
It's a debatable feature, since it needs more doc to comprehend the
template, so do '4. crud generator'
--
Fred
Alberto Valverde
I was planning to write something soon to share what my thoughts have
been recently regarding TG's future but been very busy with paid work
(and will be until late february). Anyway, here is an update to bring
up some discussion and maybe clear some uncertainties.
After thinking about it, meditating the past thread regarding this
same issue, reading some blogs/wikis and experimenting, I think TG
1.1 (yep, 1.1) could start migrating to CherryPy 3 and a PasteDeploy
style configuration file for deployment.
Some of my confusion regarding CP3 was to the fact that I wanted it
to do something it was not designed to do: that is, make CP
applications (those composed of a RootController which mount other
controllers as attributes, etc) being able to dispatch to another
WSGI app. Although it is possible, there is a problem if the
downstream app turns out to be a CP3 wsgi-wrapped app because it will
smash cp's globals being set by the upstream app and might cause
unintended consequences. So yes, this means TG controllers will not
be WSGI callables per-se like I announced in the IRC chat on Jan 3rd :(
However, CP3 provides other mechanisms for this kind of dispatch
(cp.Tree) and there are other tools that can be used to do it
(paste's URLMapper, for example). There's no need for TG/CP apps
(without the WSGI wrapper) to act as mixed WSGI application/
middleware creating havoc inside CP , if this kind of behavior is
needed then proper middleware should be written using your library of
choice to sweeten WSGI.
Attached is a little diagram of how I' envisioning a TG > 1.0.x app
As you can see, my plan is to wrap a CP app in a WSGI app which will
be built by a function conforming to the paste.app_factory interface.
Although the CP app is a leaf node in the dispatching tree, another
WSGI app (being a CP wrapped one or any other one) can be mounted by
the *developer* with a cp.Tree or a paste URLMapper inside the app
factory so those apps can be encapsulated as a single app to the eyes
of a deployer/user.
That whole "bunch" could be then deployed side by side other apps
easily by an *user*.
The difference I'm trying to emphasize here between developer and
user might be better explained by a use-case:
Developer Jane has built a Forum application using TG > 1.0.x and
decided to use CatRun3000 (which is a WSGI app built in who-cares-
what framework) as the admin interface for her app so she has mounted
it at /admin (relative to the forum app). This mounting takes place
inside her apps' app_factory (yeah, Pylons' way... ;)
Now she distributes this composite app as an Egg and user Joe decides
he want's to integrate it in his site. Joe isn't a programmer but he
likes blogging his butterfly-hunting sessions and has congregated a
passionate bunch of people who share his interests so Jane's Forum
software has appeared like god-sent and it'll be perfect for his site.
Fortunately for him, both the blog software he uses and the forum he
has just downloaded share the same system for deployment, so he
easy_installs Forum and edits 4 lines in his site configuration file
(paste deploy style), mounts the forum at /forum, restarts and voilá.
This user/developer distinction is very important IMO... part of the
success of PHP, for example, is that it allows any computer-savvy
user to download WordPress, decompress in his shared-host account,
and install. Doesn't even need to know how to program to do that.
So here is my proposed plan for action in chronological order:
0) Backport the 1.0 widgets back into the trunk. The widgets in the
trunk are *broken* by my early genshi integration experiments. We
have two choices: introducing ToscaWidgets into 1.1 (will break most
1.0 apps) or porting the 1.0 widgets which are working fine ATM
(albeit its design limitations).
This means widgets could only use Kid for their templates and
genshi's ET should be used to display widgets in Genshi templates.
Maybe the "ET" step can be automated but I'm not very sure as it must
only occur when displaying on a page template and 1.0 widget's don't
know whether they are being displayed in a page template or inside
another widget.
All current TG unittests should pass before moving on to 1) User apps
should not notice this change.
1) Migrate the trunk to use CP3 with as little change as possible to
current architecture. I don't think it should be very difficult...
the only things needed to be adapted is the configuration system as I
believe CP3 and CP2 slightly differ in it's structure, port our CP2
filters to CP3 tools and some "sed"ing to use the new names for
thiings in CP3. This means no change to current error-handling,
decorators, etc... I believe someone who knows well CP3 and is
willing to take a look at how TG's trunk is incompatible could be of
*great* help in this area (hint, hint... ;)
All current TG unittests should pass before moving on to 2) Maybe
some tweaking or adaptation is needed, I don't know.... User apps
that use filters should be adapted to use tools instead.
Documentation for this must be written.
2) Add to the resulting quickstart template a module with an
app_factory that builds a WSGI app out of the CP Root controller
loading it's TG style configuration file and merging it with a
*possible* paste.deploy config. This factory will sort-of replace
start-myapp.py
What I mean by "possible" is that a single TG app doesn't really need
a paste.deploy config file and the CP configfile, built by the
developer, we're used to is enough. A paste.deploy config is needed
when a TG app distributed as an egg wants to be mounted side by side
in a bigger site. A a smart "tg-admin serve" command should be able
to load a single app inside an EGG and mount it at / without needing
an explicit deployment config. However, internally, "tg-admin serve"
would delegate to "paster serve" to load that EGG's app_factory entry
point.
Some TODOs needed for 2:
a) Some helper functions should be integrated in Turbogears to merge
the config file. Note that all server.* directives will not be needed
(and should make no effect if present) because the app will have no
knowledge of which server will be serving it. I have some
experimental code for this.
b) The "tg-admin serve" command must be implemented. This means
"start-myapp.py" will be deprecated, an alias could be implemented
for backwards compatibility by making that script delegate to "tg-
admin serve".
c) TG's startup-hooks and extension loading should be slightly
refactored so this step can be done by calling a function from the
user's app_factory.
d) Application devs' start-myapp.py will need to be adapted for this
change, it's not hard at all, just move that logic to the app_factory.
At this point we should have achieved:
1) A migration to CP3. This means, apart from other goodies, that
it'll be easy to integrate, as a developer, other WSGI apps into our
app.
2) Making TG apps encapsulable as opaque WSGI apps that can be
integrated into any bigger site. This means, user Joe could use our
app easily in his site.
3) 1.1 apps that will look very similar to 1.0 apps to an application
developer.
So what's left for 2.0?
Well, once we migrate TG's trunk to CP3 and make TG app's more WSGI
friendly and composable it's time to start building TG's development
tools using TG itself as a base. From my point of view, TG should
concentrate on building development tools which allow for a Rapid
Development Experience (wow, new buzzword ;) This is, CRUD generator,
admin interface, model designer, etc...This means (not in
chronological order):
- CatWalk could be migrated/reimplemented into a TG 1.1 app,
hopefully adding support for SA and being reusable in other
frameworks/apps (as it would be a standalone WSGI app with a nice
paste.app_factory entry point) and removed from TG's core.
- ToscaWidgets can be introduced as TG would support it's preferred
way of interfacing the framework, that is with a HostFramework object
being initialized on every request by a piece of middleware. (If you
ask, TW integrates into 1.0 without it's middleware...)
- Identity could be replaced by two layers of middleware which
handled authentication (AuthKit sounds like a nice candidate), and
authorization (a refactored TurboPeakSecurity that is being gestated
which will emulate Identity's authorization API but being generic
functions in under the hood allowing any sort of crazy authorization
policies)
- Decorators can be simplified and made less magical/complex... I
already have some ideas experiments for this...
- We can start investigating/stealing useful tools from other
projects.... (I18NToolbox, Pylons version of EvalException,
HTTPEncode, etc, etc...)
- .....
So, does this sound reasonable? Am I missing something? Opinions?
Suggestions? Questions? Free beer?
Alberto
Alberto Valverde
thing about regarding TG's future in general terms... Addressing
these particular issues:
On Jan 25, 2007, at 11:33 AM, gas...@gmail.com wrote:
>
> We know 1.0 is a feature fixed version, but I think tg 1.x worth to
> merge some enhancement from trunk, such as:
>
> 1. internal toolbox code re-structure
> this refactor had already appeared in trunk, and it make adding a new
> tool more tangible.
+1. But stay on guard to avoid extra coupling with other parts of TG
because the ToolBox will likely be refactored out of TG's core (but
bundled with TG), try to make this step as easy as possible for the
future refactorer.
>
> 2. add genshi-default quickstart generator(template).
> It already exist in trunk, but need some trick up to become an extra
> tgtemplate.
+1 However, keep in mind current widgets are incompatible without the
ET function to wrap their output when displayed on a Genshi template.
Something must be done to keep the API nice (writting ET everywhere
is not my idea of being nice... ;)
>
> 3. add Template browser in toolbox ..
> It already exist in trunk for months.
> It's nice to browse kid/genshi template within the toolbox.
+1. Same guidelines as for 1 apply.
>
> 4. add crud generator(template)
> The default crud generator combines form widgets, subdirectory
> importing, and optional paginate, error_handler, identity with
> class...it could be a good demonstration and super time saver command
> that make explicit and fully customizable CRUD usage.
This should be better implemented as a stand-alone project IMO.
2.0's philosophy is to break TG into pieces, not integrating more
pieces to the puzzle. You're free however to use the /projects
repository, TG's Trac and Mailing lists and a section at the docs to
support your project. This is exactly what 2.0 wants to encourage.
> .....
> wishes from other people...
> ....
>
> So, is it ok for me to branch a project(another code name or 1.1) in
> svn to experiment these features?
Hmmm, I rather keep this at the trunk to get the most users and
testers. Now that 1.0 is out and the 1.0 branch is the "untouchable"
one the trunk is there to break it as much as you like ;)
Alberto
gas...@gmail.com
>+1. But stay on guard to avoid extra coupling with other parts of TG
> because the ToolBox will likely be refactored out of TG's core (but
> bundled with TG), try to make this step as easy as possible for the
> future refactorer.
>
Yeah, that's the intention for the toolbox refactor appeared in trunk.
Introduce a new feature to public is the quickest way to get response,
if it is cool, we could took it off to be an extension for future
version.(as those template extensions)
Since to ship an extension will cost some extra effort.(especially
there's none existed reference about standalone toolbox extension).
BTW, It's the toolbox because it's battery included, right?
> > So, is it ok for me to branch a project(another code name or 1.1) in
> > svn to experiment these features?Hmmm, I rather keep this at the trunk to get the most users and
> testers. Now that 1.0 is out and the 1.0 branch is the "untouchable"
> one the trunk is there to break it as much as you like ;)
>
I understand your consideration, but I hope we could quickly get tg
1.1, even 1.2, the 'feature-freeze' statement keeps too long.
"practicality beats purity"
It's time to do something more aggressive like we did in 0.8->0.9 (many
new features were introduced, but not make them separate as extensions
yet).
Users could get some new features(enhancements) that won't break any
1.0 behavior. People would try the feature and have some words in their
blog, it will attract more people to TurboGears, that's positive.
I don't like mochikit's release way, I'm feel tired to tell people to
look some useful features in mochikit svn, if it is useful and stable,
why not release a new version?
Release a new version does matter to the host company and end users.
Since the host company never deploy the svn version to the user and
they need sometime to test if the version is stable. The end user (who
don't touch svn) won't feel tg has any enhancements these days and
quickly turned to other frameworks.
Alberto Valverde
On Jan 25, 2007, at 5:39 PM, gas...@gmail.com wrote:
>
>>> this refactor had already appeared in trunk, and it make adding a
>>> new tool more tangible.
>> +1. But stay on guard to avoid extra coupling with other parts of TG
>> because the ToolBox will likely be refactored out of TG's core (but
>> bundled with TG), try to make this step as easy as possible for the
>> future refactorer.
>>
>
> Yeah, that's the intention for the toolbox refactor appeared in trunk.
>
> Introduce a new feature to public is the quickest way to get response,
> if it is cool, we could took it off to be an extension for future
> version.(as those template extensions)
Yep, that's my point. I wasn't asking for decoupling right now, just
avoid *more* coupling if possible... :)
> Since to ship an extension will cost some extra effort.(especially
> there's none existed reference about standalone toolbox extension).
> BTW, It's the toolbox because it's battery included, right?
Well, extra effort for the packager, not the user... the user has
"easy_install" Keep in mind that separate-packages is just an
organizational convention ("organizational" in the sense we'll have
package owners to bug when we want something ;) which has the side
effect of defining clear interfaces with the rest of the world (this
is good). Batteries included means a "requires" line in setup.py. so
TG can still be batteries included although it's batteries are well
encapsulated batteries.
>
>
>>> So, is it ok for me to branch a project(another code name or 1.1) in
>>> svn to experiment these features?Hmmm, I rather keep this at the
>>> trunk to get the most users and
>> testers. Now that 1.0 is out and the 1.0 branch is the "untouchable"
>> one the trunk is there to break it as much as you like ;)
>>
>
> I understand your consideration, but I hope we could quickly get tg
> 1.1, even 1.2, the 'feature-freeze' statement keeps too long.
>
> "practicality beats purity"
Agree. That's why 1.0 lives in a separate branch where *only*
bugfixes or implementing basic, easy and non-risky missing features
which are just not there but expected, the inclusion of a test.cfg is
a good example (and it fixed some bugs by accident ;), fixing broken
paginate another... Experimentation and new features in trunk is
encouraged, but 1.1 should take extra care to make a migration from
1.0 as painless as possible so thinking of how it will affect
existing code is a must. Every breaking change should be avoided or
provide very good documentation, deprecation warnings, so it's easy
to upgrade. This is why I don't want to include TW in 1.1 as a
default yet, for example.
>
> It's time to do something more aggressive like we did in 0.8->0.9
> (many
> new features were introduced, but not make them separate as extensions
> yet).
Making new, complex feautures as separate extensions does require
some effort but it pays off in the long run. I find contradictory to
introduce new components in TG's core when we're aiming for exactly
the opposite in 2.0. I'm not saying 1.1 should start decoupling now,
just not introduce *more* coupling :). Re-using the TW example: I
could have coded TW inside TG's trunk but decided that if I wanted to
be usable outside TG, rebuilding widgets outside TG sounded like a
better idea. It took some effort but now TW is usable outside TG and
*inside* TG (even in 1.0)
>
> Users could get some new features(enhancements) that won't break any
> 1.0 behavior. People would try the feature and have some words in
> their
> blog, it will attract more people to TurboGears, that's positive.
If the feature is useful but distributed separately they'll use it
anyway, it's just an "easy_install" away... I don't see why bundling
it inside TG will make things better... In fact, If the feature is
useful and is not tied to TG, it'll get even more attention from
people who want it but don't want the whole TG cow.
>
> I don't like mochikit's release way, I'm feel tired to tell people to
> look some useful features in mochikit svn, if it is useful and
> stable,
> why not release a new version?
This much proves my point :) If MochiKit was not included in TG's
core it would be much easier to upgrade it without risking breaking
user's code. If someone doesn't want latest 1.4, they can write
"TGMochiKit < 1.4" in their app's setup.py and use the older release.
>
> Release a new version does matter to the host company and end users.
> Since the host company never deploy the svn version to the user and
> they need sometime to test if the version is stable. The end user
> (who
> don't touch svn) won't feel tg has any enhancements these days and
> quickly turned to other frameworks.
I agree and I hope we'll have a 1.1 ASAP so we can start building on
it. I've stated my plans in a post a couple of hours ago for open
discussion. Other features/projects can be developed in parallel with
the priorities I see now which is to migrate to CP3 and implement
paste.deploy's interfaces. However, new projects should not be
included in the core IMO, new features for existing components: yes
(with care not to obstruct a future refactor). The trunk is open for
any experimentation you wish. That's all. :)
Alberto
fumanchu
> Attached is a little diagram of how I' envisioning a TG > 1.0.x app
That looks good. Can you explain in a little more detail what the
difference is between a RootController and a Controller? Why the
distinction?
> As you can see, my plan is to wrap a CP app in a WSGI app which will
> be built by a function conforming to the paste.app_factory interface.
> Although the CP app is a leaf node in the dispatching tree, another
> WSGI app (being a CP wrapped one or any other one) can be mounted by
> the *developer* with a cp.Tree or a paste URLMapper inside the app
> factory so those apps can be encapsulated as a single app to the eyes
> of a deployer/user.
>
> That whole "bunch" could be then deployed side by side other apps
> easily by an *user*.
Sounds like a perfect direction. But please, stick with the term
"deployer". Users are always on the far side of a User-Agent. ;)
> Fortunately for him, both the blog software he uses and the forum he
> has just downloaded share the same system for deployment...
By "the same system" you mean...WSGI? Paste Deploy? TG? In other words,
at which point in the architecture would you start to say,
"_un_fortunately for him, they don't share the same system."?
> 1) Migrate the trunk to use CP3 with as little change as possible to
> current architecture. I don't think it should be very difficult...
> the only things needed to be adapted is the configuration system as I
> believe CP3 and CP2 slightly differ in it's structure, port our CP2
> filters to CP3 tools and some "sed"ing to use the new names for
> thiings in CP3. This means no change to current error-handling,
> decorators, etc... I believe someone who knows well CP3 and is
> willing to take a look at how TG's trunk is incompatible could be of
> *great* help in this area (hint, hint... ;)
There are a few such people. :) Happy to help.
> All current TG unittests should pass before moving on to 2) Maybe
> some tweaking or adaptation is needed, I don't know.... User apps
> that use filters should be adapted to use tools instead.
> Documentation for this must be written.
I'll trade you better Tool docs for better TW docs. ;) I'm a bit lost
on how the various components actually work: who calls whom when.
> 2) Add to the resulting quickstart template a module with an
> app_factory that builds a WSGI app out of the CP Root controller
> loading it's TG style configuration file and merging it with a
> *possible* paste.deploy config. This factory will sort-of replace
> start-myapp.py
>
> What I mean by "possible" is that a single TG app doesn't really need
> a paste.deploy config file and the CP configfile, built by the
> developer, we're used to is enough. A paste.deploy config is needed
> when a TG app distributed as an egg wants to be mounted side by side
> in a bigger site. A a smart "tg-admin serve" command should be able
> to load a single app inside an EGG and mount it at / without needing
> an explicit deployment config. However, internally, "tg-admin serve"
> would delegate to "paster serve" to load that EGG's app_factory entry
> point.
That sounds like an excellent direction.
I would be quite interested in folding any such app_factory interface
back into CherryPy itself. I think this is an area where we can
co-develop quite well. For example, could this be solved by having the
CherryPy Application class grow a new app_factory (class)method?
> Some TODOs needed for 2:
>
> a) Some helper functions should be integrated in Turbogears to merge
> the config file. Note that all server.* directives will not be needed
> (and should make no effect if present) because the app will have no
> knowledge of which server will be serving it. I have some
> experimental code for this.
If you're not using cherrypy.server to start and manage HTTP servers,
then the various server.* config entries will be largely ignored (those
config entries just set attributes, they don't invoke any code on their
own); however, they should be set properly so that cherrypy.url() works
when you're not in a request.
Thanks for putting so much effort into this!
Robert Brewer
System Architect
Amor Ministries
fuma...@amor.org
Karl Guertin
> I'll trade you better Tool docs for better TW docs. ;) I'm a bit lost
> on how the various components actually work: who calls whom when.
Watch out or I'll take you up on that. I'm itching to do some TG
hacking (instead of docs for a change) and I plan on doing it based on
TW. If doing TW docs and backporting to TG gets me free CherryPy docs,
then that's how it'll happen.
Alberto Valverde
On Jan 25, 2007, at 7:37 PM, fumanchu wrote:
>
> On Jan 25, 6:50 am, Alberto Valverde <albe...@toscat.net> wrote:
>> Attached is a little diagram of how I' envisioning a TG > 1.0.x app
>
> That looks good. Can you explain in a little more detail what the
> difference is between a RootController and a Controller? Why the
> distinction?
Well, actually that distinction is present in 1.0 but I'm not sure if
a migration to 3.0 will remove it completely. AFAICT it's only
purpose in 1.0 is implementing some loggers and setting is_app_root
(though a grep on tg's source hasn't revealed where else that
attribute is looked up.. :-/, does CP do something with it?)
>
>> As you can see, my plan is to wrap a CP app in a WSGI app which will
>> be built by a function conforming to the paste.app_factory interface.
>> Although the CP app is a leaf node in the dispatching tree, another
>> WSGI app (being a CP wrapped one or any other one) can be mounted by
>> the *developer* with a cp.Tree or a paste URLMapper inside the app
>> factory so those apps can be encapsulated as a single app to the eyes
>> of a deployer/user.
>>
>> That whole "bunch" could be then deployed side by side other apps
>> easily by an *user*.
>
> Sounds like a perfect direction. But please, stick with the term
> "deployer". Users are always on the far side of a User-Agent. ;)
Ok.
>
>> Fortunately for him, both the blog software he uses and the forum he
>> has just downloaded share the same system for deployment...
>
> By "the same system" you mean...WSGI? Paste Deploy? TG? In other
> words,
> at which point in the architecture would you start to say,
> "_un_fortunately for him, they don't share the same system."?
I meant Paste Deploy & WSGI. WSGI for the protocol and Paste Deploy
for the (app|filter|server)-building interfaces needed by paster.
I like Paste Deploy interface because I see them as only a very basic
way of saying what an app factory should expect and return, easy to
implement and powerful enough. You don't even need Paste to mount an
app that implements an app factory! Just call it with a dict as first
parameter and some keyword args and it will return a wsgi app which
you can further manipulate. Besides that, it already implements
utilities for loading apps directly from and egg, etc... which are
quite handy.
It's config file syntax might not be the prettiest to some eyes but
I'm pretty sure it can be worked out if needed, what I'm looking at
is it's interface for building (WSGI) apps and connecting them to a
server.
>
>> 1) Migrate the trunk to use CP3 with as little change as possible to
>> current architecture. I don't think it should be very difficult...
>> the only things needed to be adapted is the configuration system as I
>> believe CP3 and CP2 slightly differ in it's structure, port our CP2
>> filters to CP3 tools and some "sed"ing to use the new names for
>> things in CP3. This means no change to current error-handling,
>> decorators, etc... I believe someone who knows well CP3 and is
>> willing to take a look at how TG's trunk is incompatible could be of
>> *great* help in this area (hint, hint... ;)
>
> There are a few such people. :) Happy to help.
Which is very nice! :)
>
>> All current TG unittests should pass before moving on to 2) Maybe
>> some tweaking or adaptation is needed, I don't know.... User apps
>> that use filters should be adapted to use tools instead.
>> Documentation for this must be written.
>
> I'll trade you better Tool docs for better TW docs. ;) I'm a bit lost
> on how the various components actually work: who calls whom when.
Are you meaning TG or TW?, if the later (toscawidgets) I think
discussing it's docs deserves another thread... ;)
If the former then I must say I need to do some homework and dive
into TG to refresh my memory.... grep says TG only uses 4 filters:
$ grep -r "^class.*Filter" turbogears/ | egrep -v "(MochiKit|\.svn|
\.pyc)"
turbogears/database.py:class EndTransactionsFilter(BaseFilter):
turbogears/startup.py:class VirtualPathFilter(object):
turbogears/startup.py:class NestedVariablesFilter(object):
turbogears/visit/api.py:class VisitFilter(BaseFilter):
I can't remember any other filter we use... these filters are
initialized and stacked in startup.py IIRC. I think they can be
easily rewritten as Tools.
I believe that adjusting our config system to what CP3 uses now will
be the "hardest" part in a CP3 migration
>
>> 2) Add to the resulting quickstart template a module with an
>> app_factory that builds a WSGI app out of the CP Root controller
>> loading it's TG style configuration file and merging it with a
>> *possible* paste.deploy config. This factory will sort-of replace
>> start-myapp.py
>>
>> What I mean by "possible" is that a single TG app doesn't really need
>> a paste.deploy config file and the CP configfile, built by the
>> developer, we're used to is enough. A paste.deploy config is needed
>> when a TG app distributed as an egg wants to be mounted side by side
>> in a bigger site. A a smart "tg-admin serve" command should be able
>> to load a single app inside an EGG and mount it at / without needing
>> an explicit deployment config. However, internally, "tg-admin serve"
>> would delegate to "paster serve" to load that EGG's app_factory entry
>> point.
>
> That sounds like an excellent direction.
>
> I would be quite interested in folding any such app_factory interface
> back into CherryPy itself. I think this is an area where we can
> co-develop quite well. For example, could this be solved by having the
> CherryPy Application class grow a new app_factory (class)method?
Hmm, only if entry_points can be made to point to a classmethod which
I believe they can't...
However, I think CP3 quite well supports being wrapped in an app
factory as it stands right now. I would rather have the app factory
under the application developer's control (editable in his own app's
source) because it's a (another) great place to "manually" stack
middleware, dispatchers... and do any sort of stuff that should occur
only once in the app's lifetime. This is what Pylons is doing for
example,
>
>> Some TODOs needed for 2:
>>
>> a) Some helper functions should be integrated in Turbogears to merge
>> the config file. Note that all server.* directives will not be needed
>> (and should make no effect if present) because the app will have no
>> knowledge of which server will be serving it. I have some
>> experimental code for this.
>
> If you're not using cherrypy.server to start and manage HTTP servers,
> then the various server.* config entries will be largely ignored
> (those
> config entries just set attributes, they don't invoke any code on
> their
> own); however, they should be set properly so that cherrypy.url()
> works
> when you're not in a request.
Thanks for the info (I'll be probably be needing many little snippets
like this in the future... ;)
> Thanks for putting so much effort into this!
You're welcome! It seems (by CP's Trac timeline) that it's
reciprocal... :)
Alberto
iain duncan
> "gas...@gmail.com" <gas...@gmail.com> writes:
>
> > 2. add genshi-default quickstart generator(template).
> > It already exist in trunk, but need some trick up to become an extra
> > tgtemplate.
>
> Doesn't the "--future" (or something like that) switch do that?
>
> > 4. add crud generator(template)
>
> This is too much of a change and would require much more testing. If we add a
> feature it has to work, otherwise there's no reason to include it in a stable
> branch.
+1! Keep the release branch rock stable please! More branches = more
overhead but is vastly better than risking destabilizing the production
branch at all. When we just keep adding "testing" features to the main
branch with a higher number, it confuses new users about what to
install. It is not immediately obvious that 1.1 would be less tested
than 1.0 unless we explicitly say so, 1.1-testing or something. I think
this point is *crucial* for adoption of tg in critical business apps.
And to our clients, all their apps are critical ....
Iain
fumanchu
> I'll trade you better Tool docs for better TW docs. ;) I'm a bit lost
> on how the various components actually work: who calls whom when.
and Alberto replied:
> Are you meaning TG or TW?, if the later (toscawidgets) I think
> discussing it's docs deserves another thread... ;)
Yes, I meant toscawidgets. Another thread is fine.
Later, I wrote:
> I would be quite interested in folding any such app_factory interface
> back into CherryPy itself. I think this is an area where we can
> co-develop quite well. For example, could this be solved by having the
> CherryPy Application class grow a new app_factory (class)method?
...and Alberto replied:
> Hmm, only if entry_points can be made to point to a classmethod
> which I believe they can't...
That's OK. An instancemethod could be equally helpful:
class Application(object):
...
def factory(self, global_conf, **local_conf):
self.merge(local_conf)
return self
----
Then, in your TG app code:
app = cherrypy.tree.mount(root, "/", conf)
----
And in the paste config file:
paste.app_factory = mymodule.app.factory
> However, I think CP3 quite well supports being wrapped in an app
> factory as it stands right now. I would rather have the app factory
> under the application developer's control (editable in his own app's
> source) because it's a (another) great place to "manually" stack
> middleware, dispatchers... and do any sort of stuff that should occur
> only once in the app's lifetime.
Fair enough. But it would be nice to have it work by default.
Alberto Valverde
On Jan 25, 2007, at 9:07 PM, fumanchu wrote:
>
> I wrote:
>> I'll trade you better Tool docs for better TW docs. ;) I'm a bit lost
>> on how the various components actually work: who calls whom when.
>
> and Alberto replied:
>> Are you meaning TG or TW?, if the later (toscawidgets) I think
>> discussing it's docs deserves another thread... ;)
>
> Yes, I meant toscawidgets. Another thread is fine.
Ok, open it when you want... It's true that Tosca and TG widgets docs
are pretty scarce so improving them will be good. Any specific
question? I must admit I'm in a very bad position for documenting
right now because I have no idea what people expect from TW widgets
or how they see them... It's been so much time since I struggled
about a year ago to grasp Kevin's and Michele's idea of them that I
see myself too much inmersed in them...
They really don't do something very fancy expect moving and massaging
variables from the display into a template. Most of the code is meta-
programming to reduce boiler-plate (binding variables sent to the
constructor into the instance, making them available at the dict that
will feed the template passing it thorugh update_params so it can be
modified for every request, moving variables from parent widgets to
child widgets, etc...).
So widgets only "do something" on three moments:
1) When a widget subclass is built.
By a metaclass. Nothing fancy, the __init__ method is wrapped
with pre and post hooks and a serial number is assigned so widget
lists can be possible.
2) when a widget is initialized. Also a set of valid parameters are
picked from all bases.
- pre init hooks are called which attach child widgets to the
widget instance. Some magic goes in here due the fact that widgets
cannot be modified once initialized so already initialized children
must be cloned to assign them a new parent (the widget being
initialized)
- the init methods are called cooperatively. where widget
subclasses must fix their initial state from the parameters given to
the constructor... they are free to attach new children, create
javascript code that shall initialize the widget, etc...
- post init hooks are called. some things can only be done at
this time, like generating schema validators for compound widgets as
it0's the only time when we can know exactky how many children a
widget has
3) when the widgets are being displayed:
- "params" (which shall better be called "template_vars" but they
keep their old name) are copied from the instance into a dict that
gets filtered thorugh
update_params to feed the template, then the widget calls the
engine manager to select a template plugin that shall display the
widget.
>
> Later, I wrote:
>> I would be quite interested in folding any such app_factory interface
>> back into CherryPy itself. I think this is an area where we can
>> co-develop quite well. For example, could this be solved by having
>> the
>> CherryPy Application class grow a new app_factory (class)method?
>
> ...and Alberto replied:
>> Hmm, only if entry_points can be made to point to a classmethod
>> which I believe they can't...
>
> That's OK. An instancemethod could be equally helpful:
>
> class Application(object):
> ...
> def factory(self, global_conf, **local_conf):
> self.merge(local_conf)
> return self
>
> ----
> Then, in your TG app code:
>
> app = cherrypy.tree.mount(root, "/", conf)
> ----
> And in the paste config file:
>
> paste.app_factory = mymodule.app.factory
I've just tried it out and both class/instancemethods can be loaded
by an entry_point.
Well, gotta go now.... please ask some specific questions reagrding
TW and I'll try my best to answer them... hopefully the conversation
will enable me to write better docs. :)
Alberto
Alberto
Kevin Dangoor
> My main concern is with the stability of what we called stable
> code :-) And
> the introduction of toscawidgets, genshi by default, sqlalchemy,
> etc. are not
> a minor change IMVHO.
The move to Genshi is actually pretty easy, typically. (It may even
be somewhat automatable, thanks to XML).
Genshi's error handling, speed, text templates, extra tags, etc. make
it a win that's worth pushing to sooner than later. SQLAlchemy's a
big win as well, but it's a much more involved transition.
Kevin
iain duncan
Actually I don't think this is quite that cut and dry. For me, the
ability to use arbitrary python within kid is *extremely useful*. I
don't always use my templates within a full TG app, and for prototyping
or splitting up labour and testing in a small operation, it's a real
time saver.
I realize Genshi plans to implement that feature, but they aren't there
yet.
Iain
gas...@gmail.com
exist APIs, and it is cool :-D
Template browser(3) is helpful if people organize their templates into
separate folders. Now it is simple, but I think people may like to make
this idea go further.(to an online editor or something)
Thanks for your advice, I'll try 2,4 separately from tgcore :-)
Karl Guertin
> The move to Genshi is actually pretty easy, typically. (It may even
> be somewhat automatable, thanks to XML).
-1 on moving to Genshi pre-2.0. Genshi is still under development and
you cannot fully automate the transition due to the presence of
meaningful python code within the XML.
Karl Guertin
> I just commit the 1. and 3. to 1.0 branch, since they won't effect any
> exist APIs, and it is cool :-D
But they do affect the documentation effort. Please do not add
features to stable branches. While it's trivial to add a page to
describe this feature, it's not simple to explain what features do and
do not exist in various 1.0.x releases. Please branch to 1.1 before
adding features.
Jeff Kowalczyk
> > The move to Genshi is actually pretty easy, typically. (It may even
> > be somewhat automatable, thanks to XML).
>
> -1 on moving to Genshi pre-2.0. Genshi is still under development and
> you cannot fully automate the transition due to the presence of
> meaningful python code within the XML.
It would be a useful improvement for 1.1 to simply support genshi and
kid templates in widgets. I'd like to make any per-project widgets with
genshi instead of kid, starting as soon as possible. I'm looking
forward to ToscaWidgets, of course.
Once genshi widget support is available, 1.1 could optionally manually
migrate as many of the stock widgets as possible to genshi templates.
Several widgets in the cogbin might follow suit in their subsequent
releases.
Couldn't both kid and genshi stock widget sets be supported over a
deprecation period of 1.x?
Karl Guertin
> Couldn't both kid and genshi stock widget sets be supported over a
> deprecation period of 1.x?
You're free to migrate to TW as soon as you decide it's stable enough.
In fact, I recommend it because Alberto has put a number of breaking
improvements into TW. I'll be learning TW for my own projects, so I
plan on putting my documentation efforts into TW and then backporting
to TG 1.0 widgets docs.
iain duncan
Yes, exactly! And it *is* frustrating to new users and sends out a bad
message. Sure, *we* know you are being careful. Those who are first
being exposed to the project however come away with an impression of
chaos and lack of structure. Then when they do hit a bug, they are all
the more likely to throw up their hands and quit.
I still do not see why, given the above, we should not use more
branches. Something needs to be done because the present system is not
working to produce a stable documented api that behaves in a predictable
( and thus debuggable ) manner for new users.
Iain
gas...@gmail.com
> > features to stable branches. While it's trivial to add a page to
> > describe this feature, it's not simple to explain what features do and
> > do not exist in various 1.0.x releases. Please branch to 1.1 before
> > adding features.
Ok.... I branch a new 1.1 and store back the 1.0.x branch :-)
Alberto Valverde
Actually we already have a branch for 1.1.... it's called "trunk" ;)
Is there any reason you think we need yet another branch? I think
it's better to keep new development in trunk like we've been doing so
far, another very similar branch will just be need more merging to be
done and provide no benefit.
Alberto
Alberto Valverde
On Jan 26, 2007, at 6:35 AM, Jeff Kowalczyk wrote:
>
> "Karl Guertin" wrote:
>>> The move to Genshi is actually pretty easy, typically. (It may even
>>> be somewhat automatable, thanks to XML).
>>
>> -1 on moving to Genshi pre-2.0. Genshi is still under development and
>> you cannot fully automate the transition due to the presence of
>> meaningful python code within the XML.
>
> It would be a useful improvement for 1.1 to simply support genshi and
> kid templates in widgets. I'd like to make any per-project widgets
> with
> genshi instead of kid, starting as soon as possible. I'm looking
> forward to ToscaWidgets, of course.
I've tried adding support for Genshi in widgets in the trunk but it's
broken (in fact, I'm going to revert the trunk's widgets to 1.0's).
The problem lies mainly in the fact that widgets need to convert thir
output based on the template language they're being displayed on,
however, TG widgets have no knowledge of who their parent is. Things
work ok when you insert a Kid widget into a Kid compund widget, but
when you start mixing them (displaying kid on genshi or viceversa)
then you have to manually convert output in your compound's template,
which is impractical for templates like the forms which iterate over
their children and have no knowledge of he output they will produce.
This is one of the reasons ToscaWIdgets exists. In order to fully
support any template language some re-design had to be done so I
decided to kill as many birds as possible with one shot and decoupled
them from TG, ironed some wrinkles, etc... on the way.
To sum up, If you really need genshi in widgets I'd recommend
switching to TW now. It's genshi support has been tested and it'll be
less work to migrate widgets using the old API to the new one than to
add (working) support for genshi in TG's widgets IMO. Besides that,
TW provides other useful things and API improvements that TG widgets
do not.
Alberto
Max Ischenko
Ok, open it when you want... It's true that Tosca and TG widgets docs
are pretty scarce so improving them will be good.
...
Where *are* they, for a start? ;) toscawidgets.org only shows integration examples and not even a hint where to find actual docs.
Max.
gas...@gmail.com
> it's better to keep new development in trunk like we've been doing so
> far, another very similar branch will just be need more merging to be
> done and provide no benefit.
>
Sorry for a quick branch, but I think there's many differences between
1.0 and trunk, it takes time to merge all features/API changes between
them. And I'm not sure those differences are stable enough to be
introduced into 1.1 :-)
Alberto Valverde
I'm afraid we're not understanding each other very well... trunk *is*
1.1 and trunk is *not* stable yet. The stable branch ATM is 1.0 and
that is the branch we shall make an effort to keep stable by only
introducing bugfixes.
I agree with Kevin when he said in an previous email in this thread:
"If there isn't already 2.0 code on the trunk, I'd recommend using
the trunk for 1.1 and then create a branch for the more experimental
2.0."
So I said in a later email in the same thread:
"Hmmm, I rather keep this at the trunk to get the most users and
testers. Now that 1.0 is out and the 1.0 branch is the "untouchable"
one the trunk is there to break it as much as you like "
I think you should have more clearly expressed the reasons why you
don't agree with that for discussion before making a new branch so we
can define what should go where and have better coordination. The
more parallel branches we have for the longer the time just makes it
harder to keep bug fixes in sync IMO.
Now that there's a 1.1 branch, coming from 1.0, where should we start
the migration to CP3 which I proposed (again, in another email in
this same thread) for 1.1? What should we implement in trunk? What
shall we do with the experienatl fetaures we have been developing in
the trunk? do we need the trunk??
We could also take a "Twisted" approach to branching where all new
features/bug-fixes are implemented in a separate branch and then,
after review, they are merged back into the trunk to keep the trunk
stable. These branches try to have a short life-span in order to make
merging easier.
However, iI think we should discuss that before so developers are
aware of the procedures... If you want a separate branch for
experiemental features then it's fine with me if you create one, but
label it something like "1.1-toolbox-exp" or something and branch the
*trunk* (as the trunk *is* 1.1). However, it seems to me that the new
branch should be labeled "1.0-toolbox-exp" as you branched from
1.0... What is the intention? Those new features cannot be merged
back into 1.0 for all the reason we have outlined in this thread
(docs, testing, feature freeze), Im confused.
Maybe I'm missing something... please explain.
Thanks,
Alberto
gas...@gmail.com
"If you want a separate branch for experiemental features then it's
fine with me if you create one, but
label it something like "1.1-toolbox-exp"
That's my intend for, It's ok to use some code name for the branch, and
"1.1-toolbox-exp" is a good candidate :-)
I just have some time and want to do some healthy but not that small
changes upon the 1.0 branch, and those changes should be no harm with
current API usage.
Sorry I miss the important 1.1 milestone plan >_<
--
Fred
Alberto Valverde
On Jan 26, 2007, at 7:03 PM, gas...@gmail.com wrote:
>
>> Maybe I'm missing something... please explain.
>
> "If you want a separate branch for experiemental features then it's
> fine with me if you create one, but
> label it something like "1.1-toolbox-exp"
>
> That's my intend for, It's ok to use some code name for the branch,
> and
> "1.1-toolbox-exp" is a good candidate :-)
Ok, but make sure that "1.1-toolbox-exp" branches 1.1, which is going
to be derived from *trunk*. This means that a "1.1-foo-exp" should
branch from trunk due to the transitive property of the previous
statement.
If it branches 1.0, then it shall be called "1.0-toolbox-exp" in
order to keep naming conventions sane. However, 1.0 is in feature
freeze so I don't see any point in experimenting new features with
the 1.0 branch...
I'd also advise to take the time to keep a 1.1 branch in sync with
1.1 (trunk)
Alberto
Kevin Dangoor
True. Keep in mind that I wasn't talking about eliminating Kid
support in TG 1.1. I was talking about making Genshi the preferred
template choice... those who need to stick with Kid could indeed do so.
By the way, for app composition to work really nicely, Genshi's
variable includes and more powerful matching are a big win.
Kevin
Jorge Vargas
> Hi all,
>
> I was planning to write something soon to share what my thoughts have
> been recently regarding TG's future but been very busy with paid work
> (and will be until late february). Anyway, here is an update to bring
> up some discussion and maybe clear some uncertainties.
>
> After thinking about it, meditating the past thread regarding this
> same issue, reading some blogs/wikis and experimenting, I think TG
> 1.1 (yep, 1.1) could start migrating to CherryPy 3 and a PasteDeploy
> style configuration file for deployment.
that will be good CP will bring a lot of speed, as for paste it's
great since the current deploy system is very complex, specially went
people forget to move their *.cfg files. can we explore the
possibility of having only one config file? most of dev/prod is just
duplicated from one to the other. I was thinking of having a common
section which will be the ones being [foo] and then have subsections
like [foo.dev] and [foo.prod].
also does this means ConfigObj is out of the package?
>
> Some of my confusion regarding CP3 was to the fact that I wanted it
> to do something it was not designed to do: that is, make CP
> applications (those composed of a RootController which mount other
> controllers as attributes, etc) being able to dispatch to another
> WSGI app. Although it is possible, there is a problem if the
> downstream app turns out to be a CP3 wsgi-wrapped app because it will
> smash cp's globals being set by the upstream app and might cause
> unintended consequences. So yes, this means TG controllers will not
> be WSGI callables per-se like I announced in the IRC chat on Jan 3rd :(
>
honestly I never liked this a lot, what use is a single controller?
and since you can mount "two CP apps" together in case you need that
each controller is an app in itself you just need to package them as
if and you'll get the same result.
> Attached is a little diagram of how I' envisioning a TG > 1.0.x app
>
I think that is the best, we can mix CP with plain WSGI app in the
same site but it won't let all kinds of weird setups with apps inside
apps inside apps that will create a nice set of easy to track bugs.
> the *developer* with a cp.Tree or a paste URLMapper inside the app
> factory so those apps can be encapsulated as a single app to the eyes
> of a deployer/user.
>
umm so that means TG core will handle both cp.Tree and URLMapper? in
this case will tree be the default? what are exactly the differences
between them?
> That whole "bunch" could be then deployed side by side other apps
> easily by an *user*.
>
> So here is my proposed plan for action in chronological order:
>
> 0) Backport the 1.0 widgets back into the trunk. The widgets in the
> trunk are *broken* by my early genshi integration experiments. We
> have two choices: introducing ToscaWidgets into 1.1 (will break most
> 1.0 apps)
this will be great for many reasons, #1 no need to "waste" time making
the current widgets work, #2 will finally eliminate kid from TG which
is our biggest bottleneck (speed wise) #3 we'll need to write
documentation for both widgets with the biggest disadvantage that most
people don't understand their internals enough to make it. #4 will
give ToscaWidgets a bigger exposure which will bring bug reports and
(I hope) fixes making the package more mature #5 it's the right step
in splitting everything up.
this will be bad because #1 it makes genshi the default, as you said
breaking a lot of stuff, #2 TW may not be ready for massive usage and
we (read: you) may get inundated with bugs, #3 that's too many changes
for a minor release.
> or porting the 1.0 widgets which are working fine ATM
> (albeit its design limitations).
>
for this of course some of the above apply, but it has a couple more
cons, #1 docs for widgets will need to be written "twice". #2 people
won't want to work on them (bugs and docs) because "they are going
away", although bugs will be fixed by those that are affected by them.
#3 it will give yet another point where TG community is divided (in a
good way), and every issue on the mailing list or IRC will be replied
with "TW or TGW"?
> This means widgets could only use Kid for their templates and
> genshi's ET should be used to display widgets in Genshi templates.
> Maybe the "ET" step can be automated but I'm not very sure as it must
> only occur when displaying on a page template and 1.0 widget's don't
> know whether they are being displayed in a page template or inside
> another widget.
>
again we should try to get out of kid, specially because this is the
simplest port (just change 2 functions) with the biggest gain (huge
performance boost) the only real problem here is the <? python ?>
which many people like (I hate it) but that seems to be under good way
http://genshi.edgewall.org/ticket/84, just for looking at that it
seems that patch "3" and on are "almost ready" after this is applied
maybe we could depend on the svn genshi until 0.4 is released.
> All current TG unittests should pass before moving on to 1) User apps
> should not notice this change.
I assume your still talking about the second option. if not this
doesn't seems possible.
they will because of the <?python?> also master.kid will have to
change and of course all the templates be renamed.
>I believe someone who knows well CP3 and is
> willing to take a look at how TG's trunk is incompatible could be of
> *great* help in this area (hint, hint... ;)
just leaving this so someone will read it again :)
> User apps
> that use filters should be adapted to use tools instead.
> Documentation for this must be written.
I believe this is good enough, specially since code that only calls
them just needs to do find and replace
http://www.cherrypy.org/wiki/UpgradeTo30#HooksreplaceFilters
>
> 2) Add to the resulting quickstart template a module with an
> app_factory that builds a WSGI app out of the CP Root controller
> loading it's TG style configuration file and merging it with a
> *possible* paste.deploy config. This factory will sort-of replace
> start-myapp.py
I like this.
>
> What I mean by "possible" is that a single TG app doesn't really need
> a paste.deploy config file and the CP configfile, built by the
> developer, we're used to is enough. A paste.deploy config is needed
> when a TG app distributed as an egg wants to be mounted side by side
> in a bigger site.
that sounds like too many config files, I believe we need to think
this better, they are all dict based files. I see 3 possible solutions
a) handle then totally separated backed by docs, howto write a
paste.deploy config file, howto .... b) Do some python-foo to build
the config files automagically, c) have one BIG config file with all
the options and do less python-foo to build the separated ones.
> A a smart "tg-admin serve" command should be able
> to load a single app inside an EGG and mount it at / without needing
> an explicit deployment config. However, internally, "tg-admin serve"
> would delegate to "paster serve" to load that EGG's app_factory entry
> point.
just like all the other tg-admin tools a simplier way to call the internal one.
>
> Some TODOs needed for 2:
>
> a) Some helper functions should be integrated in Turbogears to merge
> the config file. Note that all server.* directives will not be needed
> (and should make no effect if present) because the app will have no
> knowledge of which server will be serving it. I have some
> experimental code for this.
not sure if this is the best way.
>
> b) The "tg-admin serve" command must be implemented. This means
> "start-myapp.py" will be deprecated, an alias could be implemented
> for backwards compatibility by making that script delegate to "tg-
> admin serve".
>
good idea, although this will need to make the upgrade project funtion
a little smarterm I believe that today it will break the code for
this, although we could just ask people to delete the old one and
replace it with the new one.
> c) TG's startup-hooks and extension loading should be slightly
> refactored so this step can be done by calling a function from the
> user's app_factory.
currently there are many extension on cheeseshop this needs to be
handle with care.
>
> d) Application devs' start-myapp.py will need to be adapted for this
> change, it's not hard at all, just move that logic to the app_factory.
>
needs to be documented.
> At this point we should have achieved:
>
> 1) A migration to CP3. This means, apart from other goodies, that
> it'll be easy to integrate, as a developer, other WSGI apps into our
> app.
> 2) Making TG apps encapsulable as opaque WSGI apps that can be
> integrated into any bigger site. This means, user Joe could use our
> app easily in his site.
> 3) 1.1 apps that will look very similar to 1.0 apps to an application
> developer.
>
I like it.
> So what's left for 2.0?
>
> Well, once we migrate TG's trunk to CP3 and make TG app's more WSGI
> friendly and composable it's time to start building TG's development
> tools using TG itself as a base.
and splitting stuff.
> From my point of view, TG should
> concentrate on building development tools which allow for a Rapid
> Development Experience (wow, new buzzword ;) This is, CRUD generator,
> admin interface, model designer, etc...This means (not in
> chronological order):
>
> - CatWalk could be migrated/reimplemented into a TG 1.1 app,
> hopefully adding support for SA and being reusable in other
> frameworks/apps (as it would be a standalone WSGI app with a nice
> paste.app_factory entry point) and removed from TG's core.
>
I'm affaid to say CatWalk is very hard to migrated this will be almost
a write from scratch, it is way to couple with SO idioms.
what about FastData? will this die?
> - ToscaWidgets can be introduced as TG would support it's preferred
> way of interfacing the framework, that is with a HostFramework object
> being initialized on every request by a piece of middleware. (If you
> ask, TW integrates into 1.0 without it's middleware...)
>
ok I need to read on that.
> - Identity could be replaced by two layers of middleware which
> handled authentication (AuthKit sounds like a nice candidate), and
> authorization (a refactored TurboPeakSecurity that is being gestated
> which will emulate Identity's authorization API but being generic
> functions in under the hood allowing any sort of crazy authorization
> policies)
>
my only problem with this is the generic package itself, it's a great
concept but we are depending on Phillip's limited time.
http://www.eby-sarna.com/pipermail/peak/2007-January/002660.html
> - Decorators can be simplified and made less magical/complex... I
> already have some ideas experiments for this...
>
> - We can start investigating/stealing useful tools from other
> projects.... (I18NToolbox, Pylons version of EvalException,
> HTTPEncode, etc, etc...)
comments on this two for later.
> Free beer?
where do I send it?
Jorge Vargas
http://genshi.edgewall.org/attachment/ticket/84/ I think TG should not
move until that is committed, we could even move based on the svn
version, but not before that is in the trunk.
Jorge Vargas
> > > The move to Genshi is actually pretty easy, typically. (It may even
> > > be somewhat automatable, thanks to XML).
> >
> > -1 on moving to Genshi pre-2.0. Genshi is still under development and
> > you cannot fully automate the transition due to the presence of
> > meaningful python code within the XML.
>
> migrate as many of the stock widgets as possible to genshi templates.
> Several widgets in the cogbin might follow suit in their subsequent
> releases.
same container this is good for compatibility but bad for performance,
with this TG will load up 3 templating engines into memory, although
cheetah is not keep for too long. Memory footprint of those apps will
be big just because someone doesn't wants to port "that widget" your
using.
>
> Couldn't both kid and genshi stock widget sets be supported over a
> deprecation period of 1.x?
I think that will just bring confusion and frustration. when we make
the switch it was to be final.
and of course lots of almost duplicated documentation in some parts
and radically changes in others about the widgets.
Jorge Vargas
>
> >
> >> Maybe I'm missing something... please explain.
> >
> > "If you want a separate branch for experiemental features then it's
> > fine with me if you create one, but
> > label it something like "1.1-toolbox-exp"
> >
> > That's my intend for, It's ok to use some code name for the branch,
> > and
> > "1.1-toolbox-exp" is a good candidate :-)
>
> Ok, but make sure that "1.1-toolbox-exp" branches 1.1, which is going
> to be derived from *trunk*. This means that a "1.1-foo-exp" should
> branch from trunk due to the transitive property of the previous
> statement.
>
be more difficult to create/apply, think of bug fixes.
> If it branches 1.0, then it shall be called "1.0-toolbox-exp" in
> order to keep naming conventions sane. However, 1.0 is in feature
> freeze so I don't see any point in experimenting new features with
> the 1.0 branch...
>
I have no idea what you guys did, first there was a 1.1 branch which
was deleted now there is a 1.1_package_sep_exp?
why not just branch 1.1 of 1.0 and backport stuff from trunk?
what I don't want right now is what happen with 0.9 and trunk that
each and every commit had to be done to both because the branch was
there for way too long. if 1.1 is going to have this much features
(sa,genshi,tw,refactoring,etc) then just release 1.1 out of the trunk.
and then build 2.0.
is there anything left on trunk that doesn't belongs to 1.1? are those
feature worth the wasted time doing two commits?
> I'd also advise to take the time to keep a 1.1 branch in sync with
> 1.1 (trunk)
huh? you mean 2.0 trunk? or you mean branch 1.1 of trunk and not 1.0
>
> Alberto
>
> >
>
iain duncan
>
> True. Keep in mind that I wasn't talking about eliminating Kid
> support in TG 1.1. I was talking about making Genshi the preferred
> template choice... those who need to stick with Kid could indeed do so.
>
> By the way, for app composition to work really nicely, Genshi's
> variable includes and more powerful matching are a big win.
Yeah, it looks really nice. I think the switch is a good plan in the
long term. I'm just going to wait for that feature though. I think I use
it more than I would more powerful match templates. 'Course that may
change as I my own TG system evolves, so many options! =)
Iain
Alberto Valverde
>
> On 1/26/07, Alberto Valverde <alb...@toscat.net> wrote:
>> Ok, but make sure that "1.1-toolbox-exp" branches 1.1, which is going
>> to be derived from *trunk*. This means that a "1.1-foo-exp" should
>> branch from trunk due to the transitive property of the previous
>> statement.
>>
> no please don't do that all those branches will just mean patches will
> be more difficult to create/apply, think of bug fixes.
This is the main reason I'd prefer to have less branches, specially
if there is no significant difference regarding API's and internal
organization. Trunk is very similar to 1.0 except in the widgets
(which I'm going to restore in trunk from 1.0) and some enhancements
to the toolbox
>> If it branches 1.0, then it shall be called "1.0-toolbox-exp" in
>> order to keep naming conventions sane. However, 1.0 is in feature
>> freeze so I don't see any point in experimenting new features with
>> the 1.0 branch...
>>
> I have no idea what you guys did, first there was a 1.1 branch which
> was deleted now there is a 1.1_package_sep_exp?
>
> why not just branch 1.1 of 1.0 and backport stuff from trunk?
Trunk is 1.1. We've been forward merging changes to 1.0 into trunk
for months.
> what I don't want right now is what happen with 0.9 and trunk that
> each and every commit had to be done to both because the branch was
> there for way too long. if 1.1 is going to have this much features
> (sa,genshi,tw,refactoring,etc) then just release 1.1 out of the trunk.
> and then build 2.0.
Plans for 1.1 are in the "TG 2.0 update" thread. The subject is
rather misleading because I'm touching 1.1 issues most of the time.
What I tried to get through is that:
* CP3 and paste.deploy are targeted for 1.1
* 1.1 development can start now
* 1.1 will come out of the trunk
* 1.1 should be be 95% compatible with 1.0 and that 5% should be very
well documented :)
2.0 involves a more serious shakeup of TG's foundations in order to
reduce the core by moving TG's services into separate projects. 1.1
will enable this because 1.1 apps will be abe to integrate WSGI
components more easiliy and be used as WSGI components of a larger
site (thanks to CP3 and paste.deploy)
I'll try to be more explicit now in order to avoid confusion. The
three points I'd like to stress out are:
* The trunk is 1.1 and 1.1 is the trunk
* 1.0 is featured-freezed and should only incorporate bugfixes
* Experiments with 2.0 can start in a separate branch, however, I
think 1.1 must get some shape before this can happen... at least 1.1
must be ported to use CP3
> is there anything left on trunk that doesn't belongs to 1.1? are those
> feature worth the wasted time doing two commits?
The only thing in trunk that doesn't belong in 1.1 are the widgets,
which should be copied from 1.0 (*not* TW, TW is for 2.0) because the
widgets in the trunk are broken (I know... I broke them ;).
>> I'd also advise to take the time to keep a 1.1 branch in sync with
>> 1.1 (trunk)
> huh? you mean 2.0 trunk? or you mean branch 1.1 of trunk and not 1.0
Exactlly, I mean "branch 1.1 from trunk" when we decide to start
stabilizing it for a release (like we did with 1.0). I wouldn't do
this now because there's work pending for the 1.1 milestone and
making a branch now will force us to keep trunk and 1.1 in sync *and*
merge bugfixes from 1.0 into both (phew, I'd have to write yet
another script to do this, 3 separate workingenvs and 3 times the
trouble....) I'd prefer to branch 1.1 for stabilization once we've
moved to CP3 and we implement paste.deploy's interface to build WSGI
apps.
Alberto
Ian Bicking
> On 1/25/07, Alberto Valverde <alb...@toscat.net> wrote:
>> Hi all,
>>
>> I was planning to write something soon to share what my thoughts have
>> been recently regarding TG's future but been very busy with paid work
>> (and will be until late february). Anyway, here is an update to bring
>> up some discussion and maybe clear some uncertainties.
>>
>> After thinking about it, meditating the past thread regarding this
>> same issue, reading some blogs/wikis and experimenting, I think TG
>> 1.1 (yep, 1.1) could start migrating to CherryPy 3 and a PasteDeploy
>> style configuration file for deployment.
> that will be good CP will bring a lot of speed, as for paste it's
> great since the current deploy system is very complex, specially went
> people forget to move their *.cfg files. can we explore the
> possibility of having only one config file? most of dev/prod is just
> duplicated from one to the other. I was thinking of having a common
> section which will be the ones being [foo] and then have subsections
> like [foo.dev] and [foo.prod].
Well, in Paste generally I just have two config files. But you can do
something like:
[app:generic]
use = egg:MyApp
setting1 = foo
setting2 = bar
[app:dev]
use = generic
setting1 = foo-dev
debug = true
[app:main]
use = generic
debug = false
Then you can serve up from the main or dev section (main being the
default). Or you can have them pick up values from other files (e.g.,
use = config:generic.ini), or whatever. I abhor boiler plate in config
files, and once the boiler plate is gone having two config files isn't
so bad.
>> What I mean by "possible" is that a single TG app doesn't really need
>> a paste.deploy config file and the CP configfile, built by the
>> developer, we're used to is enough. A paste.deploy config is needed
>> when a TG app distributed as an egg wants to be mounted side by side
>> in a bigger site.
> that sounds like too many config files, I believe we need to think
> this better, they are all dict based files. I see 3 possible solutions
> a) handle then totally separated backed by docs, howto write a
> paste.deploy config file, howto .... b) Do some python-foo to build
> the config files automagically, c) have one BIG config file with all
> the options and do less python-foo to build the separated ones.
If you want to build up the config in Python or some custom way, you'd
just want to conform to the paste.* entry points (app_factory,
filter_factory, etc).
You could also just use the Paste way of accessing things from
everywhere. Paste doesn't allow a single application to have
subsections, but the keys can look like whatever you want, so if you
really want "/foo session_timeout = 60" or something, you could parse
that into {'/': {'session_timeout': '60'}}. I dunno... generally I find
this kind of control unnecessary once you've split things into formal
apps -- overriding things by path inside an application is error prone.
Also I think there's a config file inside TG projects, right? While you
can do that, I prefer just putting that into Python code. So that means
any stuff that isn't optional or shouldn't be configured on deployment
goes into Python code. I haven't kept up with TG on this, but I seem to
remember it was putting some of that stuff into config files inside the
package.
>> - We can start investigating/stealing useful tools from other
>> projects.... (I18NToolbox, Pylons version of EvalException,
>> HTTPEncode, etc, etc...)
BTW, I've thought about splitting off the Paste exception stuff into a
separate project, and doing some potentially backward-incompatible
changes to support better templating and customization, leaving the
Paste stuff stable (which is why the Pylons changes haven't made it back
into Paste) and only deprecating the Paste stuff when the new project is
stabilized.
(HTTPEncode, OTOH, shouldn't be used outside of experiments yet because
I'm still heavily refactoring it.)
--
Ian Bicking | ia...@colorstudy.com | http://blog.ianbicking.org
Jorge Vargas
I'll try to be more explicit now in order to avoid confusion. The
three points I'd like to stress out are:
* The trunk is 1.1 and 1.1 is the trunk
* 1.0 is featured-freezed and should only incorporate bugfixes
shall we add a post commit hook?
* Experiments with 2.0 can start in a separate branch, however, I
think 1.1 must get some shape before this can happen... at least 1.1
must be ported to use CP3
agree 2.0 shouldn't be branched in a long time from now,
> is there anything left on trunk that doesn't belongs to 1.1? are those
> feature worth the wasted time doing two commits?
The only thing in trunk that doesn't belong in 1.1 are the widgets,
which should be copied from 1.0 (*not* TW, TW is for 2.0) because the
widgets in the trunk are broken (I know... I broke them ;).
um I got confused I though you said TW could be in 1.1 if we get genshi.
>> I'd also advise to take the time to keep a 1.1 branch in sync with
>> 1.1 (trunk)
> huh? you mean 2.0 trunk? or you mean branch 1.1 of trunk and not 1.0
Exactlly, I mean "branch 1.1 from trunk" when we decide to start
stabilizing it for a release (like we did with 1.0). I wouldn't do
this now because there's work pending for the 1.1 milestone and
making a branch now will force us to keep trunk and 1.1 in sync *and*
merge bugfixes from 1.0 into both (phew, I'd have to write yet
another script to do this, 3 separate workingenvs and 3 times the
trouble....) I'd prefer to branch 1.1 for stabilization once we've
moved to CP3 and we implement paste.deploy's interface to build WSGI
apps.
yup I'll get some time next week to categorize tickets again.
Alberto
Alberto Valverde
On 1/27/07, Alberto Valverde <alb...@toscat.net> wrote:
I'll try to be more explicit now in order to avoid confusion. The
three points I'd like to stress out are:
* The trunk is 1.1 and 1.1 is the trunk
* 1.0 is featured-freezed and should only incorporate bugfixeshttp://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook
shall we add a post commit hook?
* Experiments with 2.0 can start in a separate branch, however, I
think 1.1 must get some shape before this can happen... at least 1.1
must be ported to use CP3
agree 2.0 shouldn't be branched in a long time from now,> is there anything left on trunk that doesn't belongs to 1.1? are those
> feature worth the wasted time doing two commits?
The only thing in trunk that doesn't belong in 1.1 are the widgets,
which should be copied from 1.0 (*not* TW, TW is for 2.0) because the
widgets in the trunk are broken (I know... I broke them ;).
um I got confused I though you said TW could be in 1.1 if we get genshi.
>> I'd also advise to take the time to keep a 1.1 branch in sync with
>> 1.1 (trunk)
> huh? you mean 2.0 trunk? or you mean branch 1.1 of trunk and not 1.0
Exactlly, I mean "branch 1.1 from trunk" when we decide to start
stabilizing it for a release (like we did with 1.0). I wouldn't do
this now because there's work pending for the 1.1 milestone and
making a branch now will force us to keep trunk and 1.1 in sync *and*
merge bugfixes from 1.0 into both (phew, I'd have to write yet
another script to do this, 3 separate workingenvs and 3 times the
trouble....) I'd prefer to branch 1.1 for stabilization once we've
moved to CP3 and we implement paste.deploy's interface to build WSGI
apps.
yup I'll get some time next week to categorize tickets again.
Alberto Valverde
On Jan 27, 2007, at 10:38 PM, Ian Bicking wrote:
(...)
Yep. TG loads configuration files from the "config" package inside TG
apps. Those config files are loaded with ConfigObj to allow python
values. We also have a home-made syntax to define loggers which live
at config/log.cfg. That configuration system shall remain in 1.1 for
backwards compatibility but can easily be merged with a deployment
config in plain ini format. One thing I'd like to stress is that
deployment configuration would be optional. "tg-admin serve" would be
able to generate one on the fly for simple TG apps wich would just
mount the "main" app_factory entrypoint from the app's egg at "/".
However, given that TG apps would have paste deploy's entry points, a
deployer could write a custom deployment config to build a stack with
TG (and non-TG "paste enabled") components.
>
>>> - We can start investigating/stealing useful tools from other
>>> projects.... (I18NToolbox, Pylons version of EvalException,
>>> HTTPEncode, etc, etc...)
>
> BTW, I've thought about splitting off the Paste exception stuff into a
> separate project, and doing some potentially backward-incompatible
> changes to support better templating and customization, leaving the
> Paste stuff stable (which is why the Pylons changes haven't made it
> back
> into Paste) and only deprecating the Paste stuff when the new
> project is
> stabilized.
Thats good to know :) I must admit I really like Pylons'
EvalException so having something similar as a stand alone package
for use in TG would be great.
>
> (HTTPEncode, OTOH, shouldn't be used outside of experiments yet
> because
> I'm still heavily refactoring it.)
Ok, I just mentioned it as an example to illustrate the fact that we
could investigate any WSGI component for use in TG, not that we need
HTTPEncode at the moment... :)
Alberto
Jorge Vargas
On Jan 28, 2007, at 1:16 AM, Jorge Vargas wrote:On 1/27/07, Alberto Valverde < alb...@toscat.net> wrote:
I'll try to be more explicit now in order to avoid confusion. The
three points I'd like to stress out are:
* The trunk is 1.1 and 1.1 is the trunkThat branch is exactly the reason I want to make clear what the roadmap is. :)* 1.0 is featured-freezed and should only incorporate bugfixeshttp://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook
shall we add a post commit hook?Nah, I don't think we need this extra mechanization for the moment.... Sometimes I like to write nice messages when closing tickets myself ;)* Experiments with 2.0 can start in a separate branch, however, I
think 1.1 must get some shape before this can happen... at least 1.1
must be ported to use CP3
agree 2.0 shouldn't be branched in a long time from now,> is there anything left on trunk that doesn't belongs to 1.1? are those
> feature worth the wasted time doing two commits?
The only thing in trunk that doesn't belong in 1.1 are the widgets,
which should be copied from 1.0 (*not* TW, TW is for 2.0) because the
widgets in the trunk are broken (I know... I broke them ;).
um I got confused I though you said TW could be in 1.1 if we get genshi.1.1 should be compatible with 1.0 as much as possible.... TW introduces some API changes in the widgets and would break existing apps if they replace TG widgets now. However, anyone who wants to use genshi with widgets or take advantage of what TW provides can still use them as a "non-official-yet" component (just as some of us are using SA/Genshi with 1.0)
ok that makes sense although TW is a nice addition, but so is SA ...
>> I'd also advise to take the time to keep a 1.1 branch in sync with
>> 1.1 (trunk)
> huh? you mean 2.0 trunk? or you mean branch 1.1 of trunk and not 1.0
Exactlly, I mean "branch 1.1 from trunk" when we decide to start
stabilizing it for a release (like we did with 1.0). I wouldn't do
this now because there's work pending for the 1.1 milestone and
making a branch now will force us to keep trunk and 1.1 in sync *and*
merge bugfixes from 1.0 into both (phew, I'd have to write yet
another script to do this, 3 separate workingenvs and 3 times the
trouble....) I'd prefer to branch 1.1 for stabilization once we've
moved to CP3 and we implement paste.deploy's interface to build WSGI
apps.
yup I'll get some time next week to categorize tickets again.Great :) I'm thinking that maybe we need a new category called "uncategorized" (sic) which should gather those that I batch-moved to 1.1 from the 1.0bX milestones...
Many of those tickets are completely rusty or invalid and are there because no one has yet taken a moment to close them.... valid tickets from there could then begin to move to their apropiate milestone.
well yes it's just that I don't want to close stuff just based on my opinion practically all those tickets have a question at the end by me asking for a second opinion. now if everyone is ok with me closing tickets based on my view I'll reduce that by a lot.
I'm saying this because it's hard to keep track of the status of a milestone when it has 120 tickets, where X% of them are just making up bulk.
Alberto
Kevin Horn
> well yes it's just that I don't want to close stuff just based on my opinion
> practically all those tickets have a question at the end by me asking for a
> second opinion. now if everyone is ok with me closing tickets based on my
> view I'll reduce that by a lot.
>
I would suggest setting a time limit...if noone has responded to a
request for a second opinion in X weeks, say, then close it. Of
course, I have no idea what X should be.
Keep in mind that tickets can always be reopened if need be.
Just my opinion...
Kevin Horn
Jorge Godoy
> no please don't do that all those branches will just mean patches will
> be more difficult to create/apply, think of bug fixes.
If somebody is implementing a new feature in a branch, then it is his
reponsability to merge the patch from the 1.0/1.1/2.0/trunk "official"
branches.
--
Jorge Godoy <jgo...@gmail.com>
Jorge Godoy
> The move to Genshi is actually pretty easy, typically. (It may even
> be somewhat automatable, thanks to XML).
>
> Genshi's error handling, speed, text templates, extra tags, etc. make
> it a win that's worth pushing to sooner than later. SQLAlchemy's a
> big win as well, but it's a much more involved transition.
If we have a standard and easy way to push objects into the template then this
would be easily doable since Genshi lacks the <?python?> block. It would also
be great because it would be easier to remove code from Kid as well.
Imagine the following inside the master template:
<?python
import datetime
from turbogears.i18n.format import format_date
?>
<html ...>
<head>
...
</head>
<body>
<div class="header">
User ${tg.identity.display_name} -- ${format_date(datetime.now(), format=long)}
</div>
</body>
</html>
If one wants to remove the imports and the call to datetime.now() those should
be made available for each and every template by default. Adding them to the
globally available variables isn't trivial / documented. It is doable (see
sample code below) but...
from turbogears.i18n.format import format_date
def var_updater(d):
d['today'] = format_date(datetime.now(), format='long')
turbogears.view.variable_providers.append(var_updater)
And then the template would be ...
<html ...>
<head>
...
</head>
<body>
<div class="header">
User ${tg.identity.display_name} -- ${today}
</div>
</body>
</html>
If we had a "view_globals.py" file that had its content inserted into the view
namespace "by default", then all functions and python code that one inserts
into templates could go there and be made available to any template engine
automatically.
Is it doable? Is it bad practice? Am I reinventing the wheel / doing things
the harder way?
Anyway, with that we wouldn't need the template engine to implement a python
wrapper to have it to use Python code (even if we have to disguise it). ;-)
Be seeing you,
--
Jorge Godoy <jgo...@gmail.com>
Mark Ramm
http://docs.turbogears.org/1.1/DevPlans
Later on we can cut and paste some of this information into our 1.1 Docs. And this gets us started documenting the things we do as we go in 1.1, which I think would help us tremendously to have great 1.1 docs with less last min. effort than we had for 1.0.
--Mark Ramm
Hi all,
I was planning to write something soon to share what my thoughts have
been recently regarding TG's future but been very busy with paid work
(and will be until late february). Anyway, here is an update to bring
up some discussion and maybe clear some uncertainties.
After thinking about it, meditating the past thread regarding this
same issue, reading some blogs/wikis and experimenting, I think TG
1.1 (yep, 1.1) could start migrating to CherryPy 3 and a PasteDeploy
style configuration file for deployment.
Some of my confusion regarding CP3 was to the fact that I wanted it
to do something it was not designed to do: that is, make CP
applications (those composed of a RootController which mount other
controllers as attributes, etc) being able to dispatch to another
WSGI app. Although it is possible, there is a problem if the
downstream app turns out to be a CP3 wsgi-wrapped app because it will
smash cp's globals being set by the upstream app and might cause
unintended consequences. So yes, this means TG controllers will not
be WSGI callables per-se like I announced in the IRC chat on Jan 3rd :(
However, CP3 provides other mechanisms for this kind of dispatch
(cp.Tree) and there are other tools that can be used to do it
(paste's URLMapper, for example). There's no need for TG/CP apps
(without the WSGI wrapper) to act as mixed WSGI application/
middleware creating havoc inside CP , if this kind of behavior is
needed then proper middleware should be written using your library of
choice to sweeten WSGI.
Attached is a little diagram of how I' envisioning a TG > 1.0.x app
As you can see, my plan is to wrap a CP app in a WSGI app which will
be built by a function conforming to the paste.app_factory interface.
Although the CP app is a leaf node in the dispatching tree, another
WSGI app (being a CP wrapped one or any other one) can be mounted by
the *developer* with a cp.Tree or a paste URLMapper inside the app
factory so those apps can be encapsulated as a single app to the eyes
of a deployer/user.
That whole "bunch" could be then deployed side by side other apps
easily by an *user*.
The difference I'm trying to emphasize here between developer and
user might be better explained by a use-case:
Developer Jane has built a Forum application using TG > 1.0.x and
decided to use CatRun3000 (which is a WSGI app built in who-cares-
what framework) as the admin interface for her app so she has mounted
it at /admin (relative to the forum app). This mounting takes place
inside her apps' app_factory (yeah, Pylons' way... ;)
Now she distributes this composite app as an Egg and user Joe decides
he want's to integrate it in his site. Joe isn't a programmer but he
likes blogging his butterfly-hunting sessions and has congregated a
passionate bunch of people who share his interests so Jane's Forum
software has appeared like god-sent and it'll be perfect for his site.
Fortunately for him, both the blog software he uses and the forum he
has just downloaded share the same system for deployment, so he
easy_installs Forum and edits 4 lines in his site configuration file
(paste deploy style), mounts the forum at /forum, restarts and voilá.
This user/developer distinction is very important IMO... part of the
success of PHP, for example, is that it allows any computer-savvy
user to download WordPress, decompress in his shared-host account,
and install. Doesn't even need to know how to program to do that.
So here is my proposed plan for action in chronological order:
0) Backport the 1.0 widgets back into the trunk. The widgets in the
trunk are *broken* by my early genshi integration experiments. We
have two choices: introducing ToscaWidgets into 1.1 (will break most
1.0 apps) or porting the 1.0 widgets which are working fine ATM
(albeit its design limitations).
This means widgets could only use Kid for their templates and
genshi's ET should be used to display widgets in Genshi templates.
Maybe the "ET" step can be automated but I'm not very sure as it must
only occur when displaying on a page template and 1.0 widget's don't
know whether they are being displayed in a page template or inside
another widget.
All current TG unittests should pass before moving on to 1) User apps
should not notice this change.
1) Migrate the trunk to use CP3 with as little change as possible to
current architecture. I don't think it should be very difficult...
the only things needed to be adapted is the configuration system as I
believe CP3 and CP2 slightly differ in it's structure, port our CP2
filters to CP3 tools and some "sed"ing to use the new names for
thiings in CP3. This means no change to current error-handling,
decorators, etc... I believe someone who knows well CP3 and is
willing to take a look at how TG's trunk is incompatible could be of
*great* help in this area (hint, hint... ;)
All current TG unittests should pass before moving on to 2) Maybe
some tweaking or adaptation is needed, I don't know.... User apps
that use filters should be adapted to use tools instead.
Documentation for this must be written.
2) Add to the resulting quickstart template a module with an
app_factory that builds a WSGI app out of the CP Root controller
loading it's TG style configuration file and merging it with a
*possible* paste.deploy config. This factory will sort-of replace
start-myapp.py
What I mean by "possible" is that a single TG app doesn't really need
a paste.deploy config file and the CP configfile, built by the
developer, we're used to is enough. A paste.deploy config is needed
when a TG app distributed as an egg wants to be mounted side by side
in a bigger site. A a smart "tg-admin serve" command should be able
to load a single app inside an EGG and mount it at / without needing
an explicit deployment config. However, internally, "tg-admin serve"
would delegate to "paster serve" to load that EGG's app_factory entry
point.
Some TODOs needed for 2:
a) Some helper functions should be integrated in Turbogears to merge
the config file. Note that all server.* directives will not be needed
(and should make no effect if present) because the app will have no
knowledge of which server will be serving it. I have some
experimental code for this.
b) The "tg-admin serve" command must be implemented. This means
"start-myapp.py" will be deprecated, an alias could be implemented
for backwards compatibility by making that script delegate to "tg-
admin serve".
c) TG's startup-hooks and extension loading should be slightly
refactored so this step can be done by calling a function from the
user's app_factory.
d) Application devs' start-myapp.py will need to be adapted for this
change, it's not hard at all, just move that logic to the app_factory.
At this point we should have achieved:
1) A migration to CP3. This means, apart from other goodies, that
it'll be easy to integrate, as a developer, other WSGI apps into our
app.
2) Making TG apps encapsulable as opaque WSGI apps that can be
integrated into any bigger site. This means, user Joe could use our
app easily in his site.
3) 1.1 apps that will look very similar to 1.0 apps to an application
developer.
So what's left for 2.0?
Well, once we migrate TG's trunk to CP3 and make TG app's more WSGI
friendly and composable it's time to start building TG's development
tools using TG itself as a base. From my point of view, TG should
concentrate on building development tools which allow for a Rapid
Development Experience (wow, new buzzword ;) This is, CRUD generator,
admin interface, model designer, etc...This means (not in
chronological order):
- CatWalk could be migrated/reimplemented into a TG 1.1 app,
hopefully adding support for SA and being reusable in other
frameworks/apps (as it would be a standalone WSGI app with a nice
paste.app_factory entry point) and removed from TG's core.
- ToscaWidgets can be introduced as TG would support it's preferred
way of interfacing the framework, that is with a HostFramework object
being initialized on every request by a piece of middleware. (If you
ask, TW integrates into 1.0 without it's middleware...)
- Identity could be replaced by two layers of middleware which
handled authentication (AuthKit sounds like a nice candidate), and
authorization (a refactored TurboPeakSecurity that is being gestated
which will emulate Identity's authorization API but being generic
functions in under the hood allowing any sort of crazy authorization
policies)
- Decorators can be simplified and made less magical/complex... I
already have some ideas experiments for this...
- We can start investigating/stealing useful tools from other
projects.... (I18NToolbox, Pylons version of EvalException,
HTTPEncode, etc, etc...)
- .....
So, does this sound reasonable? Am I missing something? Opinions?
Suggestions? Questions? Free beer?
Alberto
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
Alberto Valverde
I'm definitely enjoying this peak into the future of TurboGears. I took a few min. To wikify this message slightly and post it up on the wiki for future reference/editing.
http://docs.turbogears.org/1.1/DevPlans
Robin Bryce
> > Also I think there's a config file inside TG projects, right?
> > While you
> > can do that, I prefer just putting that into Python code. So that
> > means
> > any stuff that isn't optional or shouldn't be configured on deployment
> > goes into Python code. I haven't kept up with TG on this, but I
> > seem to
> > remember it was putting some of that stuff into config files inside
> > the
> > package.
> Yep. TG loads configuration files from the "config" package inside TG
> apps. Those config files are loaded with ConfigObj to allow python
> values.
(Apologies if this is well understood and has been discussed before)
When combined with the current (TG1.0) widget system having to do:
`from turbogears import config` to access / modify configuration
values creates a boot strapping issue. As soon as the top level
import fires the widgets get instantiated.
This is particularly irritating when you want to use custom
TemplateLoader instance with genshi templates in order to handle
x-include paths - you can not load the paths using the turbogears
config system because the widgets tend to load templates on
instantiation.
Is it possible to at least tweak the __init__ imports in TG to prevent
`from turbogears import config` from instantiating widgets ?
(I personally cant stand this trend for placing configuration files in
python packages but understand I'm in the minority)
Robin