[tg-trunk] Re: ToscaWidgets 0.9.8 Release Party

[Michael Brickenstein]

Hi!
Congratulations!
Thank you for all your work on TW!
> tw.dojo
> ---
> dojo 1.3.2 added
> added versioning system

This version also fixes several bugs, which can cost lot of time.
Please upgrade!

Cheers,
Michael
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to 
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets js_callback fail.

[Andrew Basson]

Hi Luke,

See this discussion

http://groups.google.com/group/toscawidgets-discuss/browse_thread/thread/d1add406ad1dbc6d

and solution by srlindemann  here:

http://toscawidgets.org/trac/tw/ticket/30

Cheers, Andrew.


2009/3/30 Luke Macken :
>
> Hey guys,
>
> I've been getting bit by this problem for a while now, and I finally
> sat down and tracked it down last night.
>
> This is what happens with ToscaWidgets 0.9.4::
>
>    >>> from tw.api import js_function, js_callback
>    >>> print js_function('$')({'callback': js_callback('function()
> {}')})
>    $({"callback": function(){}})
>
> Yet in ToscaWidgets-0.9.5dev-20081026 found in the TG2 current index
> gives me this::
>
>    >> from tw.api import js_function, js_callback
>    >>> print js_function('$')({'callback': js_callback('function()
> {}')})
>    $({"callback": "function(){}"})
>
> Come to find out, TG2's ToscaWidgets-0.9.5dev-20081026 package is
> *OLDER* than ToscaWidgets-0.9.4, and thus does not contain Alberto's
> recent fix: http://toscawidgets.org/hg/ToscaWidgets/rev/769a9b08c3a1
>
> So, the solution would be to either remove the TG2 TW package, and
> just let people pull it from PyPi, or to release a newer 0.9.5
> development snapshot.
>
> Cheers,
>
> luke
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to 
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets

[Michael Brickenstein]

Hi Chris!

> The problem with making Catwalk it's own middleware is that I'd have
> to re-implement all of the rest dispatch, and I don't really have a
> desire to do that.

Shouldn't it be possible to make it just a TG2 app mounted in a TG2
app, instead
a TG2 controller.
In this way, you should have much more control and be able to use TG2
dispatching instead of creating your own own.
For example, you could also use your own SA session, since the session
provided by the user might be suboptimal
for your purposes.
Of course TG2's middleware shouldn't be configured full_stack then
(not provide all middleware again).

I mention all these, as I think, that the patch mentioned above is
just a symptom of the same problem.

Michael
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to 
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets

[percious]

I wrote my initial response at like 12am, so sorry it was so terse.  I
wanted to thank Mark for bringing this issue up to the ML, and I will
try to do that more successfully in the future.  I realize that the
change I made effects the entire TG dispatch, and that really needs to
be discussed.  This change is really forward-looking.  I am hoping
that there will be a miriad of tools for TG that can be plugged into
an existing application, and I expect these tools to use TW.  TW is
such a powerful technology, and I would hope that making it as easy as
possible to use would be beneficial.  I hope this explains my POV a
little better.

Oh, and if I get to vote: +1 :-)

cheers.
-chris

On Jan 15, 1:50 am, Michael Brickenstein  wrote:
> Hi Chris!
>
> It easy to suggest something (without having the time to help).
> But I think, this is related to some crucial design problem (at least
> in the old version dbsprockets).
>
> You remember all the problems, we had with having a version of
> dbmechanic for Pylons/TG1/TG2 and to fix bugs in all of them...
> Essentially, I think Catwalk2 should be its own WSGI app.
> It shouldn't need to be it's own framework like RUM, but maybe just be
> a TG2 app, mountable in other TG2 apps.
> I think, that should solve the problem (and would be a good test, if
> TG2 is designed cleanly enough to support that).
>
> Michael
>
> On 15 Jan., 07:48, percious  wrote:
>
> > Just so you guys know, this change allows people with mako, jinja, or
> > chameleon.genshi default_templates to use "tg components" like
> > tgext.admin and Catwalk.  Without this, those libraries have to use XML
> > () all over the place in their templates which also degrades
> > performance.  The default template already loads TW by default, so I
> > am uncertain why having TW as a dep. would be a concern.
>
> > cheers.
> > -chris
>
> > On Jan 14, 9:34 pm, Chris Miles  wrote:
>
> > > On 15/01/2009, at 4:07 AM, Mark Ramm wrote:
>
> > > > if tg.config.use_toscawidgets:
> > > >    import tw
> > > >    tw.framework.default_view = tg.config.tw.framework.default_view
>
> > > > Makes sense, though you only want to do the import once, not on each  
> > > > request. ;)
>
> > > I was going to suggest that there should be no performance penalty  
> > > when repeating an import as Python only imports a module once.  But  
> > > even though that is true, it looks like there is still the overhead of  
> > > processing the import statement and checking whether the import is  
> > > necessary, assigning the reference, etc.  See
> > >  http://wiki.python.org/moin/PythonSpeed/PerformanceTips#ImportStateme...
>
> > > They suggest the use of a global for doing efficient lazy imports.
>
> > > Cheers,
> > > Chris Miles
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to 
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets

[percious]

Michael,

I agree that catwalk should be it's own app at some point.  However, I
think that TG2 is benefiting from the marriage of Catwalk to TG2.  TG2
recently grew a restful controller, and some new decorators because of
the challenges in making Catwalk inside of TG.

I guess one of my goals with Sprox and Catwalk is really to push TG
technology forward.  I also want Sprox components to be easy for a
developer to take a piece of and put it in their own code.  This has
been successful, and I have recently built tgext.admin, and tgext.crud
with what I have learned about REST.

The problem with making Catwalk it's own middleware is that I'd have
to re-implement all of the rest dispatch, and I don't really have a
desire to do that.  Alternatively, I am looking into how Rum serves up
content, and I may shoe-horn sprox into rum's rest controller.  This
is my plan for getting catwalk working on all of the other wsgi
platforms, but for now, I am using it as a tool to help TG be the best
it can be.

cheers.
-chris

On Jan 15, 1:50 am, Michael Brickenstein  wrote:
> Hi Chris!
>
> It easy to suggest something (without having the time to help).
> But I think, this is related to some crucial design problem (at least
> in the old version dbsprockets).
>
> You remember all the problems, we had with having a version of
> dbmechanic for Pylons/TG1/TG2 and to fix bugs in all of them...
> Essentially, I think Catwalk2 should be its own WSGI app.
> It shouldn't need to be it's own framework like RUM, but maybe just be
> a TG2 app, mountable in other TG2 apps.
> I think, that should solve the problem (and would be a good test, if
> TG2 is designed cleanly enough to support that).
>
> Michael
>
> On 15 Jan., 07:48, percious  wrote:
>
> > Just so you guys know, this change allows people with mako, jinja, or
> > chameleon.genshi default_templates to use "tg components" like
> > tgext.admin and Catwalk.  Without this, those libraries have to use XML
> > () all over the place in their templates which also degrades
> > performance.  The default template already loads TW by default, so I
> > am uncertain why having TW as a dep. would be a concern.
>
> > cheers.
> > -chris
>
> > On Jan 14, 9:34 pm, Chris Miles  wrote:
>
> > > On 15/01/2009, at 4:07 AM, Mark Ramm wrote:
>
> > > > if tg.config.use_toscawidgets:
> > > >    import tw
> > > >    tw.framework.default_view = tg.config.tw.framework.default_view
>
> > > > Makes sense, though you only want to do the import once, not on each  
> > > > request. ;)
>
> > > I was going to suggest that there should be no performance penalty  
> > > when repeating an import as Python only imports a module once.  But  
> > > even though that is true, it looks like there is still the overhead of  
> > > processing the import statement and checking whether the import is  
> > > necessary, assigning the reference, etc.  See
> > >  http://wiki.python.org/moin/PythonSpeed/PerformanceTips#ImportStateme...
>
> > > They suggest the use of a global for doing efficient lazy imports.
>
> > > Cheers,
> > > Chris Miles
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to 
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets

[Michael Brickenstein]

Hi Chris!

It easy to suggest something (without having the time to help).
But I think, this is related to some crucial design problem (at least
in the old version dbsprockets).

You remember all the problems, we had with having a version of
dbmechanic for Pylons/TG1/TG2 and to fix bugs in all of them...
Essentially, I think Catwalk2 should be its own WSGI app.
It shouldn't need to be it's own framework like RUM, but maybe just be
a TG2 app, mountable in other TG2 apps.
I think, that should solve the problem (and would be a good test, if
TG2 is designed cleanly enough to support that).

Michael

On 15 Jan., 07:48, percious  wrote:
> Just so you guys know, this change allows people with mako, jinja, or
> chameleon.genshi default_templates to use "tg components" like
> tgext.admin and Catwalk.  Without this, those libraries have to use XML
> () all over the place in their templates which also degrades
> performance.  The default template already loads TW by default, so I
> am uncertain why having TW as a dep. would be a concern.
>
> cheers.
> -chris
>
> On Jan 14, 9:34 pm, Chris Miles  wrote:
>
> > On 15/01/2009, at 4:07 AM, Mark Ramm wrote:
>
> > > if tg.config.use_toscawidgets:
> > >    import tw
> > >    tw.framework.default_view = tg.config.tw.framework.default_view
>
> > > Makes sense, though you only want to do the import once, not on each  
> > > request. ;)
>
> > I was going to suggest that there should be no performance penalty  
> > when repeating an import as Python only imports a module once.  But  
> > even though that is true, it looks like there is still the overhead of  
> > processing the import statement and checking whether the import is  
> > necessary, assigning the reference, etc.  See
> >  http://wiki.python.org/moin/PythonSpeed/PerformanceTips#ImportStateme...
>
> > They suggest the use of a global for doing efficient lazy imports.
>
> > Cheers,
> > Chris Miles
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to 
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets

[percious]

Just so you guys know, this change allows people with mako, jinja, or
chameleon.genshi default_templates to use "tg components" like
tgext.admin and Catwalk.  Without this, those libraries have to use XML
() all over the place in their templates which also degrades
performance.  The default template already loads TW by default, so I
am uncertain why having TW as a dep. would be a concern.

cheers.
-chris

On Jan 14, 9:34 pm, Chris Miles  wrote:
> On 15/01/2009, at 4:07 AM, Mark Ramm wrote:
>
> > if tg.config.use_toscawidgets:
> >    import tw
> >    tw.framework.default_view = tg.config.tw.framework.default_view
>
> > Makes sense, though you only want to do the import once, not on each  
> > request. ;)
>
> I was going to suggest that there should be no performance penalty  
> when repeating an import as Python only imports a module once.  But  
> even though that is true, it looks like there is still the overhead of  
> processing the import statement and checking whether the import is  
> necessary, assigning the reference, etc.  See
>  http://wiki.python.org/moin/PythonSpeed/PerformanceTips#ImportStateme...
>
> They suggest the use of a global for doing efficient lazy imports.
>
> Cheers,
> Chris Miles
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to 
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets

[Chris Miles]

On 15/01/2009, at 4:07 AM, Mark Ramm wrote:

> if tg.config.use_toscawidgets:
>import tw
>tw.framework.default_view = tg.config.tw.framework.default_view
>
> Makes sense, though you only want to do the import once, not on each  
> request. ;)
>

I was going to suggest that there should be no performance penalty  
when repeating an import as Python only imports a module once.  But  
even though that is true, it looks like there is still the overhead of  
processing the import statement and checking whether the import is  
necessary, assigning the reference, etc.  See
  
http://wiki.python.org/moin/PythonSpeed/PerformanceTips#ImportStatementOverhead

They suggest the use of a global for doing efficient lazy imports.

Cheers,
Chris Miles


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to 
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets

[Mark Ramm]

> > Makes sense, though you only want to do the import once, not on each
> > request. ;)
> It's safe to do that on every request since that attribute is a
> descriptor that stores the value you set in thread-local storage.


Safe, yes.  Fast, probably not. ;)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to 
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets

[Alberto Valverde]

Mark Ramm wrote:
>
> if tg.config.use_toscawidgets:
>import tw
>tw.framework.default_view = tg.config.tw.framework.default_view
>
>
> Makes sense, though you only want to do the import once, not on each 
> request. ;)
It's safe to do that on every request since that attribute is a 
descriptor that stores the value you set in thread-local storage.

Alberto



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to 
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets

[Mark Ramm]

>
> if tg.config.use_toscawidgets:
>import tw
>tw.framework.default_view = tg.config.tw.framework.default_view
>

Makes sense, though you only want to do the import once, not on each
request. ;)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to 
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets

[Jorge Vargas]

On Wed, Jan 14, 2009 at 9:26 AM, Mark Ramm  wrote:
>
> I noticed that a recent change in tg.controllers does 2 things:
>
> 1) it allows you to set your toscawidgets to adapt to mako or genshi
> on a per request basis
> 2) it makes a hard dependency on TW in tg.
>
> It was a goal to have the actuall turbogears2 package have as small a
> dependency set as possible, but I think this feature is pretty
> valuable.   So I'm predisposed to keep it, but I think it should be a
> conscious decision by the community so what do you all think?
>
> The actual changeset can be seen here:
>
> http://trac.turbogears.org/changeset/6099
>

-1 as well. The use case in question is when you have an application
that has several rendering engines. It isn't as dark as originally
portraited. The fix was put in place due to an application being coded
in mako, but using tgext.registration (which uses genshi).

perhaps we can do a conditional + a value in app_config.py how about this

app.cfg.py additions

base_config.use_toscawidgets = True
base_config.tw.framework.default_view = base_config.default_renderer

therefore the offending code could be replaced with, something along
the lines of

if tg.config.use_toscawidgets:
import tw
tw.framework.default_view = tg.config.tw.framework.default_view

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to 
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets

[Alberto Valverde]

Mark Ramm wrote:
> I noticed that a recent change in tg.controllers does 2 things:
>
> 1) it allows you to set your toscawidgets to adapt to mako or genshi
> on a per request basis
> 2) it makes a hard dependency on TW in tg.
>
> It was a goal to have the actuall turbogears2 package have as small a
> dependency set as possible, but I think this feature is pretty
> valuable.   So I'm predisposed to keep it, but I think it should be a
> conscious decision by the community so what do you all think?
>   

-1. The use-case it simplifies is pretty unusual (having page templates 
written in different languages and use TW in all of them) to warrant a 
hard-dependency on TW.  Why not implement it as a helper decorator so 
the dep. can be avoided?

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to 
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets 0.9.4 has been released

[percious]

Alberto,

Thanks for this.  This was the last remaining item keeping TW from
supporting Python 2.6 properly.

cheers.
-chris

On Dec 8, 4:53 am, Alberto Valverde <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've just uploaded a 0.9.4 release to PyPI. Most notable change is that
> ToscaWidgets now requires, and works properly with, Simplejson > 2.x.
>
> Full changelog is 
> here:http://toscawidgets.org/trac/tw/browser/CHANGELOG.txt?rev=353
>
> Enjoy,
> Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets Tutorial Project Code

[[EMAIL PROTECTED]]

Thanks Sanjiv!

Worked for me too.

On Sep 3, 12:43 pm, Sanjiv <[EMAIL PROTECTED]> wrote:
> The ToscaWidgets FormsTutorial under project_code has now been changed
> work with tg2a4 and it works fine for me. Can someone else confirm too
> please?
>
> Regards
> Sanjiv
>
> On Sep 3, 5:30 am, Ademan <[EMAIL PROTECTED]> wrote:
>
> > The project code provided doesn't work with alpha 4.  A little bit of
> > googling made it pretty evident that tg.middleware had been first
> > deprecated, then removed altogether, and that was the culprit.  So
> > what needs to be done for the tutorial, is have it setup on top of a
> > new quickstart, this should be fairly trivial, and I'll do it myself
> > and post a ticket if that indeed fixes *everything* but i have my
> > suspicions there could be more lurking around...
>
> > cheers
> > -Dan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets Tutorial Project Code

[Sanjiv]

The ToscaWidgets FormsTutorial under project_code has now been changed
work with tg2a4 and it works fine for me. Can someone else confirm too
please?

Regards
Sanjiv

On Sep 3, 5:30 am, Ademan <[EMAIL PROTECTED]> wrote:
> The project code provided doesn't work with alpha 4.  A little bit of
> googling made it pretty evident that tg.middleware had been first
> deprecated, then removed altogether, and that was the culprit.  So
> what needs to be done for the tutorial, is have it setup on top of a
> new quickstart, this should be fairly trivial, and I'll do it myself
> and post a ticket if that indeed fixes *everything* but i have my
> suspicions there could be more lurking around...
>
> cheers
> -Dan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets Tutorial Project Code

[Mark Ramm]

Well, all the breaking changes since the tutorial was written can be found at:

http://trac.turbogears.org/wiki/2.0/changelog

But yea, I don't think you'll miss any changes if you  quickstart a
new project and doing the same steps in the tutorial -- that should
fix everything.

--Mark Ramm

On Tue, Sep 2, 2008 at 8:30 PM, Ademan <[EMAIL PROTECTED]> wrote:
>
> The project code provided doesn't work with alpha 4.  A little bit of
> googling made it pretty evident that tg.middleware had been first
> deprecated, then removed altogether, and that was the culprit.  So
> what needs to be done for the tutorial, is have it setup on top of a
> new quickstart, this should be fairly trivial, and I'll do it myself
> and post a ticket if that indeed fixes *everything* but i have my
> suspicions there could be more lurking around...
>
> cheers
> -Dan
> >
>



-- 
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets without RuleDispatch (and a bunch of other deps.)

[Mark Ramm]

> Anyway, the release will most probably go out even if not
> all those tickets are closed so these important changes can be tested in
> the wild ASAP.

This is fantastic news.  Thanks for all the hard work Alberto, Paul,
Chris, etc.

I'm very much looking forward to the new ToscaWidgets site.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets 0.8.6 is out

[percious]

if google let me use dancing banana emoticons, you would see a whole
row of them.

-chris

On May 30, 12:31 pm, Alberto Valverde <[EMAIL PROTECTED]> wrote:
> percious wrote:
> > I just wanted to say thank you to Alberto for his hard work.
>
> You're welcome :)> Also, I wanted to mention that I don't know of any widgets 
> in the
> > twtools family that use Rule Dispatch.  I urge those using RD in their
> > widgets to speak up about it so that we can move quickly from
> > deprecation to elimination.
>
> Elimination has hit the repository a few minutes ago :) I'm planning on
> a release this Monday after the sprint.
>
> Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets 0.8.6 is out

[Alberto Valverde]

percious wrote:
> I just wanted to say thank you to Alberto for his hard work.
>   

You're welcome :)
> Also, I wanted to mention that I don't know of any widgets in the
> twtools family that use Rule Dispatch.  I urge those using RD in their
> widgets to speak up about it so that we can move quickly from
> deprecation to elimination.
>   
Elimination has hit the repository a few minutes ago :) I'm planning on
a release this Monday after the sprint.

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets 0.8.6 is out

[percious]

I just wanted to say thank you to Alberto for his hard work.

Also, I wanted to mention that I don't know of any widgets in the
twtools family that use Rule Dispatch.  I urge those using RD in their
widgets to speak up about it so that we can move quickly from
deprecation to elimination.

cheers.
-chris

On May 29, 2:27 pm, Alberto Valverde <[EMAIL PROTECTED]> wrote:
> Hi,
>
> We've just made a new important release, here's the changelog:
>
> 0.8.6 (May, 29 2008)
> 
>
> * Removed use of RuleDispatch but left the requirement in order not to break
>   backwards compatibility. Use of TW's generic functions will issue
>   DeprecationWarnings. Please fix your code ASAP (use peak.rules if
> absolutely
>   need gfs) since deprecated code will be removed in 0.9.
> * fixed memory leak caused by function closures passed to the template
> context
>   when using genshi.
> * injector_middleware now properly handles wrapped apps that use the write
>   func returned by start_response
> * Docs are finally hitting the repository!
> * :func:`tw.core.resource_injector.inject_resources` has changed it's
>   signature making ``resources`` an optional parameter and switched places
>   with ``html``.
>
> The most important change is that ToscaWidgets no longer uses generic
> functions from RuleDispatch internally paving the road for total removal
> of any dependency with C extensions in the very near future.
>
> Probably this change won't affect many users at all since we haven't
> seen much widgets using RuleDispatch in the wild, unless some bug
> introduced by the rewrite slipped in through the test-suite.
>
> This version still depends on RuleDispatch and care has been taken so
> widgets/projects using generic functions from TW (the ones with the
> PriorityDisambiguated method combiner) won't break but issue deprecation
> warnings instead.
>
> Version 0.9 will no longer require RuleDispatch at all and client code
> that extends one of TW's generic functions with RuleDispatch will *not
> work* so please fix your widgets/projects ASAP, possibly using
> PEAK-Rules as an alternative.
>
> Enjoy,
>
> Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: toscawidgets with mako-templates in TG11

[Diez B. Roggisch]

Jorge Vargas schrieb:
> On Fri, May 23, 2008 at 11:00 AM, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I'm getting troubles using TW in TG11 as widgets. Funnily enough I made
>> it work at work - but here on my notebook, it fails. The reason is
>> simple: ToscaWidgets registers a template lookup-thingy that doesn't get
>> passed the directories to search.
>>
>> Thus the lookup fails.
>>
>> Apart from installing tw & twForms and freshly creating a TG11-project,
>> I've put this into my controller:
>>
>> from toscawidgets.api import Widget
>>
>>
>> class MakoWidget(Widget):
>> params = ['count']
>> template = "toscawidgettest.templates.mako_widget"
>> engine_name = "mako"
>>
>> mako_widget = MakoWidget(count=100)
>>
>>
>> Trying this to render gives me
>>
>> http://paste.turbogears.org/paste/2726
>>
>> as an exception.
>>
>> Any suggestions?
>>
> I had a simular problem when I tested TW with plain pylons. The
> problem is that TW tries to emulate genshi's lookup on top of mako and
> it changes mako.directories to be any searchable egg path. If I recall
> correctly I fixed it passing the template_paths var in the pylons host
> framework 
> http://beta.toscawidgets.org/hg/ToscaWidgets-dev/file/9abedebb0e46/tw/mods/pylonshf.py#l26
> 
> although looking that the tg hostframework I don't see a clean way to
> fix it. as the param isn't there.
> 
> As a side note, did you change your TG view to mako? looking at the
> traceback it's going into genshi and then to mako.

No, I didn't - because it's only meant for a widget to be mako, not as 
default.

Hm, I will investigate this on monday at work - for some reason, it 
works there. OTOH other stuff doesn't - testing my app seems not to pick 
up the application config. Strange world...

Diez

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: toscawidgets with mako-templates in TG11

[Jorge Vargas]

On Fri, May 23, 2008 at 11:00 AM, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm getting troubles using TW in TG11 as widgets. Funnily enough I made
> it work at work - but here on my notebook, it fails. The reason is
> simple: ToscaWidgets registers a template lookup-thingy that doesn't get
> passed the directories to search.
>
> Thus the lookup fails.
>
> Apart from installing tw & twForms and freshly creating a TG11-project,
> I've put this into my controller:
>
> from toscawidgets.api import Widget
>
>
> class MakoWidget(Widget):
> params = ['count']
> template = "toscawidgettest.templates.mako_widget"
> engine_name = "mako"
>
> mako_widget = MakoWidget(count=100)
>
>
> Trying this to render gives me
>
> http://paste.turbogears.org/paste/2726
>
> as an exception.
>
> Any suggestions?
>
I had a simular problem when I tested TW with plain pylons. The
problem is that TW tries to emulate genshi's lookup on top of mako and
it changes mako.directories to be any searchable egg path. If I recall
correctly I fixed it passing the template_paths var in the pylons host
framework 
http://beta.toscawidgets.org/hg/ToscaWidgets-dev/file/9abedebb0e46/tw/mods/pylonshf.py#l26

although looking that the tg hostframework I don't see a clean way to
fix it. as the param isn't there.

As a side note, did you change your TG view to mako? looking at the
traceback it's going into genshi and then to mako.

> Diez
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: toscawidgets, thread_local SOLVED

[Alberto Valverde]

iain duncan wrote:
> On Sat, 2007-15-12 at 23:28 +, Alberto Valverde wrote:
>> iain duncan wrote:
>>> I got toscawidgets working in the python shell ( as in I could call and
>>> render a widget ) and in the pylons simple toscawidget example, where
>>> the widget gets attached to that handy 'c' object. Couldn't figure out
>>> what to do in TG2 though. Doing the regular tg way gives me the
>>> following traceback from *paster* ( the browser screen just hangs )
>>>
>>> TypeError: No object (name: ToscaWidgets per-request storage) has been
>>> registered for this thread
>> Did you stack TW's middleware in middleware.py?
> 
> Ok, my fault! I mixed up mywidget.display() and mywidget.render() and in
> this case did not get a traceback as useful as the CP one. ( which
> complains about wrong return type when you do that ). Returning
> mywidget.render is working fine.

Aha, you were returning a genshi Stream object then... display() is to
be used when displaying a widget on a template or another widget since
display() tries to adapt the widget's output so multiple templating
engines can be mixed. Since you've configured the HostFramework with
default_view="genshi" then the widget, being a root widget, believes it
should return output suitable for displaying in genshi.

My guess is that the Stream was being iterated outside the Pylons
context hence the toscawidgets.hostframeowrk StackedObjectProxy was not
with the right context. But I'm digressing now... :)

If returning a widget's output directly you should also encode its
output since widgets always return unicode:

return widget.render().encode('utf8')

> 
> Now I dunno if anyone cares, but if you ( incorrectly ) try to return 
> mywidget.display() from a tg2 controller, the request hangs and paster
> chokes. Not immediately obvious what went wrong.

This error-checking should be done by Pylons if at all... It would
certainly be handy to assist in debugging.
> 
> So, I have a widget, (yay!) but I don't know how to validate it based on
> today's emails. Sounds like that is still up in the air a bit. Anyone
> got an example of any method that will work for the present to validate
> from a widget and redirect errors?

Take a look at this tutorial [1]. It's Pylons' specific but should work
in TG2 (albeit not with controller method's arguments but peeking
directly into the POST/GET params). This is a work-around until I
finally get to write the TG2 valdiate() version.

Alberto

[1] http://wiki.pylonshq.com/x/0YGq

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: toscawidgets, thread_local SOLVED

[iain duncan]

On Sat, 2007-15-12 at 23:28 +, Alberto Valverde wrote:
> iain duncan wrote:
> > I got toscawidgets working in the python shell ( as in I could call and
> > render a widget ) and in the pylons simple toscawidget example, where
> > the widget gets attached to that handy 'c' object. Couldn't figure out
> > what to do in TG2 though. Doing the regular tg way gives me the
> > following traceback from *paster* ( the browser screen just hangs )
> > 
> > TypeError: No object (name: ToscaWidgets per-request storage) has been
> > registered for this thread
> 
> Did you stack TW's middleware in middleware.py?

Ok, my fault! I mixed up mywidget.display() and mywidget.render() and in
this case did not get a traceback as useful as the CP one. ( which
complains about wrong return type when you do that ). Returning
mywidget.render is working fine.

Now I dunno if anyone cares, but if you ( incorrectly ) try to return 
mywidget.display() from a tg2 controller, the request hangs and paster
chokes. Not immediately obvious what went wrong.

So, I have a widget, (yay!) but I don't know how to validate it based on
today's emails. Sounds like that is still up in the air a bit. Anyone
got an example of any method that will work for the present to validate
from a widget and redirect errors?

Iain



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: Toscawidgets Resource Path prefixed with controllermember

[Ivo Looser]

Hi Together

In fact it was a problem with the baseclass of AdminController. It
should be controllers.Controller.

Best Regards Ivo

On 10/5/07, Ivo Looser <[EMAIL PROTECTED]> wrote:
> Hi together
>
> I've tried to use Toscawidgets in the Admin part. I did the following
> structur...
>
> http://paste.turbogears.org/paste/1675
>
> When i acccess http://localhost:8080/admin dont now why the Javascript
> from the welcome Page is now  src="/admin/resources/toscawidgets.widgets.jquery/static/jquery.js">
>
> This produce a 404 Error.
>
> But when i access the Page over
> http://localhost:8080/resources/toscawidgets.widgets.jquery/static/jquery.js
> i got my expected result.
>
> How i can say toscawidgets, dont regognize the root Controller Member
> "admin" of my Controllers?
> Just make the Resource Path as usally like
> "/resources/toscawidgets.widgets.jquery/static/jquery.js".
>
> Thanks for your Help.
>
> Best Regards Ivo
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: AttributeError: 'module' object has no attribute 'copy'

[renier]

Done. http://trac.turbogears.org/ticket/1495

--Renier


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: AttributeError: 'module' object has no attribute 'copy'

[Mark Ramm]

Could you post this patch as a ticket in Trac?  It's a lot easier to
keep track of things there ;)

On 9/8/07, renier <[EMAIL PROTECTED]> wrote:
>
> This is the correct patch. Had created the first one against a
> partially modified version of view.py.
>
> --- view.py.orig2007-09-08 00:32:01.0 -0400
> +++ view.py 2007-09-08 00:34:19.0 -0400
> @@ -54,12 +54,13 @@
>  raise EngineException("No plugin available for engine
> '%s'" % name)
>
>  options = options or self.options or {}
> -options = options.copy()
> +tmp_options = {}
>  # emulate Kid and Genshi's dotted-path notation lookup
> -options.setdefault('mako.directories', []).extend(sys.path)
> +tmp_options.setdefault('mako.directories',
> []).extend(sys.path)
>  # make sure mako produces utf-8 output so we can decode it
> and use
>  # unicode internally
> -options['mako.output_encoding'] = 'utf-8'
> +tmp_options['mako.output_encoding'] = 'utf-8'
> +   options.update(tmp_options)
>  extra_vars_func = extra_vars_func or self.extra_vars_func
>
>  # Check for deprecated use.
>
>
> --Renier
>
>
>
> >
>


-- 
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: AttributeError: 'module' object has no attribute 'copy'

[renier]

This is the correct patch. Had created the first one against a
partially modified version of view.py.

--- view.py.orig2007-09-08 00:32:01.0 -0400
+++ view.py 2007-09-08 00:34:19.0 -0400
@@ -54,12 +54,13 @@
 raise EngineException("No plugin available for engine
'%s'" % name)

 options = options or self.options or {}
-options = options.copy()
+tmp_options = {}
 # emulate Kid and Genshi's dotted-path notation lookup
-options.setdefault('mako.directories', []).extend(sys.path)
+tmp_options.setdefault('mako.directories',
[]).extend(sys.path)
 # make sure mako produces utf-8 output so we can decode it
and use
 # unicode internally
-options['mako.output_encoding'] = 'utf-8'
+tmp_options['mako.output_encoding'] = 'utf-8'
+   options.update(tmp_options)
 extra_vars_func = extra_vars_func or self.extra_vars_func

 # Check for deprecated use.


--Renier



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: [ToscaWidgets] JSSource not included

[Diez B. Roggisch]

 AttributeError: 'Stream' object has no attribute 'tag'
> 
> Hmm, are javascript and css wrapped with ET in sitetemplate.html?  
> They shouldn't be wrapped since TW takes care of adapting output...


They were. But that's how they came out of the quickstart. Me being used 
only KID so far didn't expect that to be a problem.

As much as I'm in favor of options... this template-mixing-thing makes 
me fear that it's not all good...

Diez

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: [ToscaWidgets] JSSource not included

[Alberto Valverde]

On Aug 28, 2007, at 10:41 PM, Diez B. Roggisch wrote:

>
> Alberto Valverde schrieb:
>>
>> On Aug 28, 2007, at 9:06 PM, Diez B. Roggisch wrote:
>>
>>> Ok, I tried the retrieve_javascript-function as well as a simple
>>> javascript-property.
>>>
>>> So my widget looks like this:
>>>
>>> class TagInputWidget(Widget):
>>>
>>>  template = """
>>> http://www.w3.org/1999/xhtml";
>>>xmlns:py="http://genshi.edgewall.org/";
>>>type="text"
>>>name="name"
>>> />
>>> """
>>>  javascript = [JSSource("""
>>> alert("huhu");
>>> """)]
>>>
>>>
>>>
>>> But this gives me the error
>>>
>>>File
>>> "/Users/deets/Projects/privat/TurboGears/Versions/TG11/lib/
>>> python2.5/Genshi-0.4.4-py2.5.egg/genshi/input.py",
>>> line 41, in ET
>>>  tag_name = QName(element.tag.lstrip('{'))
>>> AttributeError: 'Stream' object has no attribute 'tag'

Hmm, are javascript and css wrapped with ET in sitetemplate.html?  
They shouldn't be wrapped since TW takes care of adapting output...

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: [ToscaWidgets] JSSource not included

[Diez B. Roggisch]

Alberto Valverde schrieb:
> 
> On Aug 28, 2007, at 9:06 PM, Diez B. Roggisch wrote:
> 
>> Ok, I tried the retrieve_javascript-function as well as a simple
>> javascript-property.
>>
>> So my widget looks like this:
>>
>> class TagInputWidget(Widget):
>>
>>  template = """
>> http://www.w3.org/1999/xhtml";
>>xmlns:py="http://genshi.edgewall.org/";
>>type="text"
>>name="name"
>> />
>> """
>>  javascript = [JSSource("""
>> alert("huhu");
>> """)]
>>
>>
>>
>> But this gives me the error
>>
>>File
>> "/Users/deets/Projects/privat/TurboGears/Versions/TG11/lib/ 
>> python2.5/Genshi-0.4.4-py2.5.egg/genshi/input.py",
>> line 41, in ET
>>  tag_name = QName(element.tag.lstrip('{'))
>> AttributeError: 'Stream' object has no attribute 'tag'
>>
> 
> Make sure you set the "engine_name" attribute to "genshi" and that  
> toscawidgets.framework.default_view is the engine name of the (page)  
> template your widget is being rendered on. This should default to  
> tg.defaultview so it should have a sane default unless you're mixin  
> template languages for paget templates.

The page-templates I use are genshi, and the defaultview is set to 
genshi as well. But this widget

class TagInputWidget(Widget):

 template = """
http://www.w3.org/1999/xhtml";
   xmlns:py="http://genshi.edgewall.org/";
   type="text"
   name="name"
/>
"""
 javascript = [JSSource("""
alert("huhu");
""")]

 engine_name = 'genshi'


still gives the same error.

Thanks for the help so far,

diez

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: [ToscaWidgets] JSSource not included

[Alberto Valverde]

On Aug 28, 2007, at 9:06 PM, Diez B. Roggisch wrote:

>
> Ok, I tried the retrieve_javascript-function as well as a simple
> javascript-property.
>
> So my widget looks like this:
>
> class TagInputWidget(Widget):
>
>  template = """
> http://www.w3.org/1999/xhtml";
>xmlns:py="http://genshi.edgewall.org/";
>type="text"
>name="name"
> />
> """
>  javascript = [JSSource("""
> alert("huhu");
> """)]
>
>
>
> But this gives me the error
>
>File
> "/Users/deets/Projects/privat/TurboGears/Versions/TG11/lib/ 
> python2.5/Genshi-0.4.4-py2.5.egg/genshi/input.py",
> line 41, in ET
>  tag_name = QName(element.tag.lstrip('{'))
> AttributeError: 'Stream' object has no attribute 'tag'
>

Make sure you set the "engine_name" attribute to "genshi" and that  
toscawidgets.framework.default_view is the engine name of the (page)  
template your widget is being rendered on. This should default to  
tg.defaultview so it should have a sane default unless you're mixin  
template languages for paget templates.

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: [ToscaWidgets] JSSource not included

[Diez B. Roggisch]

Alberto Valverde schrieb:
> 
> On Aug 26, 2007, at 3:30 PM, Diez B. Roggisch wrote:
> 
>> Alberto Valverde schrieb:
>>> retrieve_resources is never called by TG since the "old" mechanism
>>> (retrieve_javascript/retrieve_css) is used instead in
>>> controllers._process_output (which I plan to deprecate sometime...).
>>> The best way to programatically add javascript is to append them to
>>> self.javascript inside __init__. However, there's no way ATM to add
>>> resources once a widget is initialized (which works in both TG 1.0
>>> and Pylons). If you need to do the later please open a ticket so
>>> someone/I can look at it.
>> Hrmpf. It's a bit misleading then that it reads in the source
>>
>> """
>>  @only_if_initialized
>>  def retrieve_javascript(self):
>>  #XXX: Should be deprecatred and use only retrieve_resources
>>  from toscawidgets.resources import JSMixin
>>  return filter(lambda r: isinstance(r, JSMixin),  
>> self._resources)
>>
>> """
>>
>>
>> without any comment on the retrieve_resources method that it's  
>> currently
>> not in use.
> 
> Pylons and WSGI apps do use it :) (its only TG 1.0 the one it  
> doesn't). However, you're right that I should add a comment in the  
> source explaining it.

Ok, I tried the retrieve_javascript-function as well as a simple 
javascript-property.

So my widget looks like this:

class TagInputWidget(Widget):

 template = """
http://www.w3.org/1999/xhtml";
   xmlns:py="http://genshi.edgewall.org/";
   type="text"
   name="name"
/>
"""
 javascript = [JSSource("""
alert("huhu");
""")]



But this gives me the error

   File 
"/Users/deets/Projects/privat/TurboGears/Versions/TG11/lib/python2.5/Genshi-0.4.4-py2.5.egg/genshi/input.py",
 
line 41, in ET
 tag_name = QName(element.tag.lstrip('{'))
AttributeError: 'Stream' object has no attribute 'tag'

Any idea what's going on here?

Diez

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: [ToscaWidgets] JSSource not included

[Alberto Valverde]

On Aug 26, 2007, at 3:30 PM, Diez B. Roggisch wrote:

>
> Alberto Valverde schrieb:
>>
>> retrieve_resources is never called by TG since the "old" mechanism
>> (retrieve_javascript/retrieve_css) is used instead in
>> controllers._process_output (which I plan to deprecate sometime...).
>> The best way to programatically add javascript is to append them to
>> self.javascript inside __init__. However, there's no way ATM to add
>> resources once a widget is initialized (which works in both TG 1.0
>> and Pylons). If you need to do the later please open a ticket so
>> someone/I can look at it.
>
> Hrmpf. It's a bit misleading then that it reads in the source
>
> """
>  @only_if_initialized
>  def retrieve_javascript(self):
>  #XXX: Should be deprecatred and use only retrieve_resources
>  from toscawidgets.resources import JSMixin
>  return filter(lambda r: isinstance(r, JSMixin),  
> self._resources)
>
> """
>
>
> without any comment on the retrieve_resources method that it's  
> currently
> not in use.

Pylons and WSGI apps do use it :) (its only TG 1.0 the one it  
doesn't). However, you're right that I should add a comment in the  
source explaining it.

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets+TG2 integration

[Alberto Valverde]

On Aug 26, 2007, at 10:46 PM, Mark Ramm wrote:

>
> Any thoughts on the best way to integrate ToscaWidgets into TG2?

See my comments at http://trac.turbogears.org/ticket/1426

>
> We can modify the TG controller code to just call the special pylons
> response handlers right? Is there any disadvantage to doing that?

This could be done but won't be needed (and will "get in the way") if  
the middleware is configured to inject resources using lxml. I'd like  
to make this the preferred approach to include js & css since it's so  
much cleaner not to mix controller code with widget imports (albeit  
it can only serialize HTML at the moment) once it gets more testing.

Alberto


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: [ToscaWidgets] JSSource not included

[Diez B. Roggisch]

Alberto Valverde schrieb:
> 
> On Aug 24, 2007, at 4:08 PM, Diez B. Roggisch wrote:
> 
>> Hi,
>>
>> I'm trying to wet my feet with TWs. But I encounter a problem with the
>> following widget:
>>
>> class TagInputWidget(Widget):
>>
>>  template = """
>> http://www.w3.org/1999/xhtml";
>>xmlns:py="http://genshi.edgewall.org/";
>>type="text"
>>name="name"
>> />
>> """
>>  def retrieve_resources(self):
>>  print "foobar"
>>  res = super(TagInputWidget, self).retrieve_resources()
>>  res.append(JSSource("""
>> alert("huhu");
>> """))
>>  return res
>>
>> The retrieve_resources-method is never called, I don't get to see the
>> foobar in the output.
>>
>> So I was wondering what I'm supposed to do to get my JSSource  
>> rendered.
> 
> retrieve_resources is never called by TG since the "old" mechanism  
> (retrieve_javascript/retrieve_css) is used instead in  
> controllers._process_output (which I plan to deprecate sometime...).  
> The best way to programatically add javascript is to append them to  
> self.javascript inside __init__. However, there's no way ATM to add  
> resources once a widget is initialized (which works in both TG 1.0  
> and Pylons). If you need to do the later please open a ticket so  
> someone/I can look at it.

Hrmpf. It's a bit misleading then that it reads in the source

"""
 @only_if_initialized
 def retrieve_javascript(self):
 #XXX: Should be deprecatred and use only retrieve_resources
 from toscawidgets.resources import JSMixin
 return filter(lambda r: isinstance(r, JSMixin), self._resources)

"""


without any comment on the retrieve_resources method that it's currently 
not in use.

Regarding the post-initilization-JS: For my usecase at hand, I don't 
think I need that.

Regards,

Diez

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: wrapping TurboGears widgets

[Alberto Valverde]

On Aug 23, 2007, at 2:07 PM, stephen emslie wrote:

>
> Thanks for the offer of help. I made a start at tackling this myself
> without terribly much success, and I've got more widgets in mind that
> I'd like to build from scratch as TW widgets.
>
> The widget in question is TGFusionCharts:
> http://www.thesamet.com/TGFusionCharts/

Ok, so you couldn't find a more complex widget, huh? :P

I've taken a quick look at it and it seems it has some dependencies  
with TG itself that will need some more though... I'd try to take a  
closer look and try to set you in the right path sometime this week.  
Please open a ticket at trac.turbogears.org (component: ToscaWidgets)  
so I remember, thanks :)

Alberto



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: [ToscaWidgets] JSSource not included

[Alberto Valverde]

On Aug 24, 2007, at 4:08 PM, Diez B. Roggisch wrote:

>
> Hi,
>
> I'm trying to wet my feet with TWs. But I encounter a problem with the
> following widget:
>
> class TagInputWidget(Widget):
>
>  template = """
> http://www.w3.org/1999/xhtml";
>xmlns:py="http://genshi.edgewall.org/";
>type="text"
>name="name"
> />
> """
>  def retrieve_resources(self):
>  print "foobar"
>  res = super(TagInputWidget, self).retrieve_resources()
>  res.append(JSSource("""
> alert("huhu");
> """))
>  return res
>
> The retrieve_resources-method is never called, I don't get to see the
> foobar in the output.
>
> So I was wondering what I'm supposed to do to get my JSSource  
> rendered.

retrieve_resources is never called by TG since the "old" mechanism  
(retrieve_javascript/retrieve_css) is used instead in  
controllers._process_output (which I plan to deprecate sometime...).  
The best way to programatically add javascript is to append them to  
self.javascript inside __init__. However, there's no way ATM to add  
resources once a widget is initialized (which works in both TG 1.0  
and Pylons). If you need to do the later please open a ticket so  
someone/I can look at it.

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: wrapping TurboGears widgets

[stephen emslie]

Thanks for the offer of help. I made a start at tackling this myself
without terribly much success, and I've got more widgets in mind that
I'd like to build from scratch as TW widgets.

The widget in question is TGFusionCharts:
http://www.thesamet.com/TGFusionCharts/

I'd like to wrap my head around TW a little better so any help is appreciated!

Stephen Emslie

On 8/23/07, Alberto Valverde <[EMAIL PROTECTED]> wrote:
>
>
> On Aug 14, 2007, at 6:50 PM, stephen emslie wrote:
>
> >
> > I'd like to pull a regular TurboGears widget into a project using
> > ToscaWidgets. The TurboGears widget is rendering with kid, and I would
> > like to have it included into my genshi template. ToscaWidgets appears
> > to handle the kid-to-genshi part well, but the kid-based widget needs
> > to be a ToscaWidget for the correct conversions to happen.
> >
> > Can anyone suggest a way to wrap a TurboGears widget with the smarter
> > ToscaWidgets rendering behaviour?
>
> There's no easy way (read: without a heck-lot-of-monkey-patching-
> unlikely-to-succeed) to use a TG widget inside a TW widget precisely
> because of the conversion being done between different template
> languages.
>
> However, both APIs are quite similar so if the widget you're trying
> to port is not very complex it should be fairly easy to port. Send me
> a link to it and I'll try to look and give you a head-start on how it
> could be ported.
>
> Alberto
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: wrapping TurboGears widgets

[Alberto Valverde]

On Aug 14, 2007, at 6:50 PM, stephen emslie wrote:

>
> I'd like to pull a regular TurboGears widget into a project using
> ToscaWidgets. The TurboGears widget is rendering with kid, and I would
> like to have it included into my genshi template. ToscaWidgets appears
> to handle the kid-to-genshi part well, but the kid-based widget needs
> to be a ToscaWidget for the correct conversions to happen.
>
> Can anyone suggest a way to wrap a TurboGears widget with the smarter
> ToscaWidgets rendering behaviour?

There's no easy way (read: without a heck-lot-of-monkey-patching- 
unlikely-to-succeed) to use a TG widget inside a TW widget precisely  
because of the conversion being done between different template  
languages.

However, both APIs are quite similar so if the widget you're trying  
to port is not very complex it should be fairly easy to port. Send me  
a link to it and I'll try to look and give you a head-start on how it  
could be ported.

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: wrapping TurboGears widgets

[stephen emslie]

On 8/15/07, Mark Ramm <[EMAIL PROTECTED]> wrote:
>
> Is there a reason you don't want to use regular TG widgets?

Not particularly. I was just getting to know TW by attempting to work
it into an existing project using non-core TG Widgets.

I've no desperate need to do this because as you mentioned, TG Widgets
can be wrapped in ET calls. Still, a facility for wrapping TG Widgets
in a TW would be a nice facility for experimenting with it. Are there
big enough differences that this cant be done?

Stephen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: wrapping TurboGears widgets

[Mark Ramm]

Is there a reason you don't want to use regular TG widgets?

You should be able to use tg widgets with Genshi templates, you may
need to wrap them in the ET() function, in your template, but they
should work fine.

If you want to use a TG Widget in TW, you'll have to port it (which
shouldn't be all that hard...).

I also thought that all the core widgets were already ported by
Alberto, if something's missing, let us know.

--Mark

On 8/14/07, stephen emslie <[EMAIL PROTECTED]> wrote:
>
> I'm using TurboGears 1.0.3.2 with toscawidgets 0.1a1 and twForms0.1a1
>
> On 8/14/07, Mark Ramm <[EMAIL PROTECTED]> wrote:
> >
> > What version of TurboGears are you using?
> >
> > On 8/14/07, stephen emslie <[EMAIL PROTECTED]> wrote:
> > >
> > > I'd like to pull a regular TurboGears widget into a project using
> > > ToscaWidgets. The TurboGears widget is rendering with kid, and I would
> > > like to have it included into my genshi template. ToscaWidgets appears
> > > to handle the kid-to-genshi part well, but the kid-based widget needs
> > > to be a ToscaWidget for the correct conversions to happen.
> > >
> > > Can anyone suggest a way to wrap a TurboGears widget with the smarter
> > > ToscaWidgets rendering behaviour?
> > >
> > > Thanks
> > >
> > > Stephen Emslie
> > >
> > > >
> > >
> >
> >
> > --
> > Mark Ramm-Christensen
> > email: mark at compoundthinking dot com
> > blog: www.compoundthinking.com/blog
> >
> > >
> >
>
> >
>


-- 
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: wrapping TurboGears widgets

[stephen emslie]

I'm using TurboGears 1.0.3.2 with toscawidgets 0.1a1 and twForms0.1a1

On 8/14/07, Mark Ramm <[EMAIL PROTECTED]> wrote:
>
> What version of TurboGears are you using?
>
> On 8/14/07, stephen emslie <[EMAIL PROTECTED]> wrote:
> >
> > I'd like to pull a regular TurboGears widget into a project using
> > ToscaWidgets. The TurboGears widget is rendering with kid, and I would
> > like to have it included into my genshi template. ToscaWidgets appears
> > to handle the kid-to-genshi part well, but the kid-based widget needs
> > to be a ToscaWidget for the correct conversions to happen.
> >
> > Can anyone suggest a way to wrap a TurboGears widget with the smarter
> > ToscaWidgets rendering behaviour?
> >
> > Thanks
> >
> > Stephen Emslie
> >
> > >
> >
>
>
> --
> Mark Ramm-Christensen
> email: mark at compoundthinking dot com
> blog: www.compoundthinking.com/blog
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: wrapping TurboGears widgets

[Mark Ramm]

What version of TurboGears are you using?

On 8/14/07, stephen emslie <[EMAIL PROTECTED]> wrote:
>
> I'd like to pull a regular TurboGears widget into a project using
> ToscaWidgets. The TurboGears widget is rendering with kid, and I would
> like to have it included into my genshi template. ToscaWidgets appears
> to handle the kid-to-genshi part well, but the kid-based widget needs
> to be a ToscaWidget for the correct conversions to happen.
>
> Can anyone suggest a way to wrap a TurboGears widget with the smarter
> ToscaWidgets rendering behaviour?
>
> Thanks
>
> Stephen Emslie
>
> >
>


-- 
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: toscawidgets-discuss (Was: toscawidgets/core.py [...])

[Alberto Valverde]

On May 19, 2007, at 2:40 PM, Christopher Arndt wrote:

>
> Alberto Valverde schrieb:
>> BTW, crossposting to toscawidgets-discuss. Let's please move this  
>> thread
>> there since there are TW users subscribed there who might not be  
>> in TG
>> trunk and a, most  probable, change that might break their apps will
>> surely be of interest to them :)
>
> I noticed that http://toscawidgets.org/ still says under "Mailing  
> list":
>
> "ToscaWidgets and related packages can be discussed in the TurboGears
> trunk mailing list."
>
> It should probably point to
>
> http://groups.google.com/group/toscawidgets-discuss

Thanks for pointing it out... I really need to get toscawidgets.org  
updated since it has been stale for a couple of months.

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: toscawidgets/core.py -- valid_id should accept hypens, underscores, periods, colons

[Ian Charnas]

... moving discussion to toscawidgets-discuss ...


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: toscawidgets/core.py -- valid_id should accept hypens, underscores, periods, colons

[Alberto Valverde]

On May 7, 2007, at 6:35 AM, Ian Charnas wrote:
> http://trac.turbogears.org/ticket/1383
>
> Some discussion might be necessary on this.  Basically in xhtml the
> "id" attribute is defined by the w3c as
>
> ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
> followed by any number of letters, digits ([0-9]), hyphens ("-"),
> underscores ("_"), colons (":"), and periods (".").
>
> However, currently the "valid_id" regular expression on line 55 of
> core.py only accepts alphanumeric characters.  Although periods and
> colons are not often used, I use the hyphen and underscore all the
> time.  Allowing elements to have ids with underscores might confuse
> toscawidgets though, because it seems that's how toscawidgets keeps
> track of compound widgets.  Not really sure what a solution would be,
> I imagine this must have come up before???


On May 7, 2007, at 8:18 PM, Ian Charnas wrote:

>
> Hyphens and Underscores are definitely included in the specs, and I
> haven't run across a good argument that would urge us not to use
> them.  Colons and periods however, *are* problematic because they are
> also special characters in CSS selectors, as I believe Jorge was
> pointing out.  The period denotes a css class, and the colon denotes a
> pseudo-class or a pseudo-element.  I haven't seen any webmasters using
> periods and colons as part of an id... which gives us an interesting
> option.  Currently, underscores are used to form the ids of compound
> widgets.  If we switched that to periods (or colons), we would open up
> the door for people to use underscores in ids, without losing anything
> in the process.  This would however, potentially break some people's
> css, if they had used the existing underscore-laden id fields as css
> selectors in their css.

There's no problem in using underscores in widget ids but there are  
two problems with using hyphens or dots:

1) First (and least important) is that accessing child widgets as  
attributes of widget.c will not work:

mywidget.c.some-id-with-hyphens

This however can easily be worked around by the fact that the object  
at the "c" attribute implements __getitem__:

mywidget.c["some-id-with-hyphens"]

2) The biggest problem is that FE's NestedVariables [1] will  
completely break since it uses dots and hyphens to decode the nested  
structure generated on the form field widgets' names (which are  
derived from the ids). However, this should be solvable because those  
separators are configurable. To go this route we just need to decide  
on two "reserved" chars to act as separators that are w3c compliant  
too. The regexp should not allow them to be used for input names to  
avoid confusion.

>
> Of course, an even better option (if possible) would be to force
> people to use ids for their widgets that are unique throughout a
> page.  There are a number of difficulties in this however (repeating
> fields pose a challenge, extra work needed to find parents/children of
> widgets)

TW tries to ease this job by generating ids automatically taking into  
account their position in the tree, for example, a coumpund widget  
with a button with id "btn" would be mangled to "mywid_btn" so you  
could have two of these compound widgets in the same page with no  
collisions as long as all widgets in the same nesting level and  
rooted at the same widget/page have distinct ids. The autogenenrated  
id can always be accessed at the widget's "id" attribute (unlike TG  
widgets where this info is only available during a request)
>
> Alberto, could you comment on the idea of switching from underscores
> to periods for compound widget ids?

I've initially implemented the compund-widget-id-building using dots  
but changed back to underscores (like TG widgets are) since jQuery  
choked on things like:

jQuery("#foo.bar")

I guess because it interprets the dot as a CSS class selector.

I've aplied your patch to try it out but it breaks two tests related  
to widget names beginning with an underscore (which was asked for in  
another ticket). It would be solved by tweaking the regexp to allow  
ids beginning with an underscore though it would not follow the  
spec... anyway, the spec should take preference over that ticket I  
guess so I'll have to change those tests.

Alberto

[1] http://formencode.org/Validator.html#http-html-form-input

BTW, crossposting to toscawidgets-discuss. Let's please move this  
thread there since there are TW users subscribed there who might not  
be in TG trunk and a, most  probable, change that might break their  
apps will surely be of interest to them :)


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-

[tg-trunk] Re: ToscaWidgets: options validatation

[Alberto Valverde]

On Apr 5, 2007, at 1:50 PM, Max Ischenko wrote:

> Alberto,
>
> On 4/5/07, Alberto Valverde <[EMAIL PROTECTED]> wrote:
>
> > def test_options():
> > w = MultipleSelectField(options="Group1 Group2 Group3".split())
> > eq_(['Group3', 'Group1'], w.validate(['Group3', 'Group1']))
> > print w.validate(['GroupX'])
> > assert 0, "formencode.Invalid not raised"
> >
> > I was assuming that the select widget will only accept options that
> > are in the options list. No?
>
> This is a tricky case. For that test to pass a OneOf valiadator is
> needed, however, that would break the callable support for the
> "options" parameter since the validator is fixed at construction
> time. I can think of 2 ways to solve it:
>
> 1) avoid using a callable for "options" and pass a OneOf validator
> explicitly
>
> That's hardly an option (sorry for pun) -- callable are invaluable  
> in certain situations.

I know. I was refering to avoiding callabes only when you absolutely  
need a OneOf validator (hence know needed options before-hand when  
instantiating the widget).

Another solution would be to create the form instance dynamically in  
every request, however, this would "break" TG's way of validating  
through the validate decorator since it needs the form instance at  
class or module scope (or do some dirty hacks with the callable you  
can pass it to provide the form instance). This could be solved by  
validating inside the controller with an equivalent form (twForms  
doesn't check on form identity like TG widgets do so different but  
equivalent form instances can work)

>
> 2) Use a hidden field to store view state and make validators aware
> of it to validate accordingly.
>
> What's a "view state"?
>
> By design, widgets are static: you can create one as a module  
> global and keep using it for the program's lifetime.
>
> OTOH, to validate with OneOf you need to know which options were  
> actually used to render the form last time and this information has  
> to be kept somewhere. You can pickle and sign this into a bundle  
> and put as a hidden field on a form. Is it what you means?

Exactly

>
> It may be not very elegant but I don't see a better way. You can  
> also save options temporarily in the the widget itself and passing  
> some bucket-id as a hidden. This can also work as long as widgets  
> does it in a thread safe way.

I've heard ASP does something similar. I don't thiink that saving  
options temporarily in the widget is a viable solution because they  
have to survive across requests. How could we handle that?

Alberto

P.S: lets move this thread to toscawidgets-discuss please :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: options validatation

[Max Ischenko]

Alberto,

On 4/5/07, Alberto Valverde <[EMAIL PROTECTED]> wrote:
>
>
> > def test_options():
> > w = MultipleSelectField(options="Group1 Group2 Group3".split())
> > eq_(['Group3', 'Group1'], w.validate(['Group3', 'Group1']))
> > print w.validate(['GroupX'])
> > assert 0, "formencode.Invalid not raised"
> >
> > I was assuming that the select widget will only accept options that
> > are in the options list. No?
>
> This is a tricky case. For that test to pass a OneOf valiadator is
> needed, however, that would break the callable support for the
> "options" parameter since the validator is fixed at construction
> time. I can think of 2 ways to solve it:
>
> 1) avoid using a callable for "options" and pass a OneOf validator
> explicitly


That's hardly an option (sorry for pun) -- callable are invaluable in
certain situations.


2) Use a hidden field to store view state and make validators aware
> of it to validate accordingly.


What's a "view state"?

By design, widgets are static: you can create one as a module global and
keep using it for the program's lifetime.

OTOH, to validate with OneOf you need to know which options were actually
used to render the form last time and this information has to be kept
somewhere. You can pickle and sign this into a bundle and put as a hidden
field on a form. Is it what you means?

It may be not very elegant but I don't see a better way. You can also save
options temporarily in the the widget itself and passing some bucket-id as a
hidden. This can also work as long as widgets does it in a thread safe way.

Max.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: options validatation

[Alberto Valverde]

On Apr 5, 2007, at 9:45 AM, Max Ischenko wrote:

> Hello,
>
> I wonder why this test fails:
>
> def test_options():
> w = MultipleSelectField(options="Group1 Group2 Group3".split())
> eq_(['Group3', 'Group1'], w.validate(['Group3', 'Group1']))
> print w.validate(['GroupX'])
> assert 0, "formencode.Invalid not raised"
>
> I was assuming that the select widget will only accept options that  
> are in the options list. No?

This is a tricky case. For that test to pass a OneOf valiadator is  
needed, however, that would break the callable support for the  
"options" parameter since the validator is fixed at construction  
time. I can think of 2 ways to solve it:

1) avoid using a callable for "options" and pass a OneOf validator  
explicitly
2) Use a hidden field to store view state and make validators aware  
of it to validate accordingly.

2 is probably the best option in the long-run but the hardest to  
design/implement. It would also allow disabling fields dynamically  
which is now not possible for required fields since validation would  
fail.

Ideas?

Alberto

P.S: Cross-posting to toscawidgets-discuss

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[Claudio Martínez]

On Jan 30, 11:39 am, Alberto Valverde <[EMAIL PROTECTED]> wrote:
> On Jan 26, 2007, at 7:34 PM, shday wrote:
>
>
>
>
>
> >> So the tests at test_genericfucntions.py are passing? :)
>
> > I guess not:
>
> > C:\Documents and
> > Settings\Daystev\Desktop\Downloads\toscawidgets\tests>nosetests
> >  test_genericfunctions.py
> > ...FF
> > ==
> > FAIL: Non-prioritized ambiguous methods are processed fine
> > --
> > Traceback (most recent call last):
> >   File "C:\Documents and
> > Settings\Daystev\Desktop\Downloads\toscawidgets\tests\t
> > est_genericfunctions.py", line 32, in test_non_prioritized_ambiguous
> > self.assertRaises(dispatch.AmbiguousMethod, self.demo_func, 10)
> > AssertionError: AmbiguousMethod not raised
>
> > ==
> > FAIL: Prioritized ambiguous methods are processed fine
> > --
> > Traceback (most recent call last):
> >   File "C:\Documents and
> > Settings\Daystev\Desktop\Downloads\toscawidgets\tests\t
> > est_genericfunctions.py", line 54, in test_prioritized_ambiguous
> > self.assertEqual(self.demo_func(10),0)
> > AssertionError: 10 != 0
>
> > --
> > Ran 5 tests in 0.521s
>
> > FAILED (failures=2)
>
> :(The only thing I can think of is to try it out in a clean  
> workingenv. I've done some tests in windows xp using workingenv and  
> everything went smoothly so I guess it's not a windows related problem.
>
> Alberto

I was having exactly the same problem with the same tests. Looks like
it's when you mix RuleDispatch/PyProtocols versions with
different .egg files and .egg directories, looks like that's when
setuptools barfs. I was only checking the eggs, when I deleted
the .egg directories (and reinstalled the .eggs) it started working.

Now I just deleted every .egg I had and reinstalled with easy_install -
Z to have them on .egg directories.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets - engine entry point loading

[robinbryce]

Oh, excellent. Exactly what I wanted; I feel truly spoiled :-D

[sending this for the second time - no idea what happened to last
nights reply]

The patch applied perfectly and works a charm. I noticed that you
don't make any attempt to clear out cached templates in
_initialize_engine. Think this is the right thing to do; this kind of
customization is really a "during startup or certainly before first
render" feature.

> specific distribution. To use it you'll need to subclass the specific
> HostFramework class you're using and, instead of letting the EM
> initialize itself with "load_all", call

Yes, for a variety of reasons I have my own start_extentions entry
point. Which, amongst other things, completely by passes tg.config.
With your patch the following worked perfectly::


framework =toscawidgets.framework = self.widget_framework =
TurbogearsHost(
environ=dict(turbogears_config =
self.turbogears_config)
)
framework.engines.load_all(self.turbogears_config)
framework.engines.load_engine_from_distribution(
'MyApp', 'genshi',
engine_options, stdvars=stdvars)
framework.engines.load_engine_from_distribution(
'MyApp', 'genshi-markup',
engine_options)

Initialization of the genshi plugin (In Genshi 0.3.6) is the thing I
actually want to intercept. There is a minimal wrapper in 'MyApp' that
supliments the existing options handling to forward loader options to
TemplateLoader.

I'm running with tg.defaultview set to "genshi" but temporarily switch
it back to "kid" while turbogears is importing; in order to let the tg
widgets find there legacy templates. Once tg is up I do::

turbogears.view.base.engines['genshi'] = self.genshi
turbogears.view.base.engines['genshi-markup'] = self.genshi

And now I have my Pony :-)

Again: Thankyou!

Best Regards,
Robin



On Mar 7, 4:56 pm, Alberto Valverde <[EMAIL PROTECTED]> wrote:
> On Mar 7, 2007, at 12:57 PM, robinbryce wrote:
>
>
>
>
>
> > Hi,
>
> > On the tw trunk; The engine manager currently unconditionally loads
> > all "python.templating.engines" entry points::
>
> > toscawidgets.view.py
> > for entrypoint in
> > iter_entry_points("python.templating.engines"):
> > engine_factory = entrypoint.load()
> > self._factories[entrypoint.name] = engine_factory
>
> > pkg_resources yields entry points in distribution order - as defined
> > by "first on path" to "last on path"
>
> >  AFAICT; If two modules define the same entry point, for example
> > 'genshi', then the *last* distribution to define the entry point wins.
> > I propose that this should be changed to *first wins" and the above
> > entrypoint.load() should be guarded::
>
> > if entrypoint.name not in self._factories:
> > engine_factory = entrypoint.load()
> > self._factories[entrypoint.name] = engine_factory
>
> > Typically the application can arrange to control its PYTHONPATH and,
> > in extremes, the contents of pkg_resources.working_set.entries. The
> > above change would allow an application to intercept engine
> > instantiation in a relatively painless way.
>
> > A specific motivation for wanting this change is the way Genshi 0.3.6
> > implements its plugin::
>
> > class AbstractTemplateEnginePlugin(object):
> > """Implementation of the plugin API."""
>
> > template_class = None
> > extension = None
>
> > def __init__(self, extra_vars_func=None, options=None):
> > if options is None:
> > options = {}
> > # TODO get loader_args from the options dict
>
> > self.loader = TemplateLoader(auto_reload=True)
> > self.options = options
> > self.get_extra_vars = extra_vars_func
>
> > In particular; it does not seek to obtain the 'search_path' used for
> > Xinlcuded documents from options and I need this.
>
> > Perhaps there is a broader question here; What is the "right
> > thing"(tm) wrt treatment of multiply defined package entry points that
> > represent extensions to specific areas of functionality ?
>
> > Thoughts anyone ?
>
> I guess you want to load the genshi template plugin from a specific
> version of Genshi, right? If that is the case I've made a patch that
> adds a method to the EngineManager to load the entrypoint from a
> specific distribution. To use it you'll need to subclass the specific
> HostFramework class you're using and, instead of letting the EM
> initialize itself with "load_all", call
> "load_engine_from_distribution" instead with the distribution you
> need plus extra options if needed. You could also do something like
> this after the EM is initialized (that is, after the
> toscawidgets.mods.XXX module you're using is imported):
>
> from toscawidgets import framework
> options = {'search_path' : 'foo'}
> framework.engines.load_engine_from_distribution("Genshi == 0.3.6",
> "genshi", options)

[tg-trunk] Re: ToscaWidgets - engine entry point loading

[Alberto Valverde]

On Mar 7, 2007, at 12:57 PM, robinbryce wrote:

>
> Hi,
>
> On the tw trunk; The engine manager currently unconditionally loads
> all "python.templating.engines" entry points::
>
> toscawidgets.view.py
> for entrypoint in
> iter_entry_points("python.templating.engines"):
> engine_factory = entrypoint.load()
> self._factories[entrypoint.name] = engine_factory
>
> pkg_resources yields entry points in distribution order - as defined
> by "first on path" to "last on path"
>
>  AFAICT; If two modules define the same entry point, for example
> 'genshi', then the *last* distribution to define the entry point wins.
> I propose that this should be changed to *first wins" and the above
> entrypoint.load() should be guarded::
>
> if entrypoint.name not in self._factories:
> engine_factory = entrypoint.load()
> self._factories[entrypoint.name] = engine_factory
>
> Typically the application can arrange to control its PYTHONPATH and,
> in extremes, the contents of pkg_resources.working_set.entries. The
> above change would allow an application to intercept engine
> instantiation in a relatively painless way.
>
> A specific motivation for wanting this change is the way Genshi 0.3.6
> implements its plugin::
>
> class AbstractTemplateEnginePlugin(object):
> """Implementation of the plugin API."""
>
> template_class = None
> extension = None
>
> def __init__(self, extra_vars_func=None, options=None):
> if options is None:
> options = {}
> # TODO get loader_args from the options dict
>
> self.loader = TemplateLoader(auto_reload=True)
> self.options = options
> self.get_extra_vars = extra_vars_func
>
> In particular; it does not seek to obtain the 'search_path' used for
> Xinlcuded documents from options and I need this.
>
> Perhaps there is a broader question here; What is the "right
> thing"(tm) wrt treatment of multiply defined package entry points that
> represent extensions to specific areas of functionality ?
>
> Thoughts anyone ?

I guess you want to load the genshi template plugin from a specific  
version of Genshi, right? If that is the case I've made a patch that  
adds a method to the EngineManager to load the entrypoint from a  
specific distribution. To use it you'll need to subclass the specific  
HostFramework class you're using and, instead of letting the EM  
initialize itself with "load_all", call  
"load_engine_from_distribution" instead with the distribution you  
need plus extra options if needed. You could also do something like  
this after the EM is initialized (that is, after the  
toscawidgets.mods.XXX module you're using is imported):

from toscawidgets import framework
options = {'search_path' : 'foo'}
framework.engines.load_engine_from_distribution("Genshi == 0.3.6",  
"genshi", options)

Try out the attached patch and if it's fine I'll commit it when I  
have a chance.

Alberto


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---



load_from_dist.diff.gz
Description: GNU Zip compressed data

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[shday]

Thanks for your help. I've decided that being on the bleeding edge may 
not be a good idea as I'm trying to build something quickly. For now 
I'm just going to use plain old 1.01 widgets. The only "non-standard" 
part will be SQLAlchemy.

Steve

On Jan 30, 9:39 am, Alberto Valverde <[EMAIL PROTECTED]> wrote:
> On Jan 26, 2007, at 7:34 PM, shday wrote:
>
>
>
>
>
>
>
> >> So the tests at test_genericfucntions.py are passing? :)
>
> > I guess not:
>
> > C:\Documents and
> > Settings\Daystev\Desktop\Downloads\toscawidgets\tests>nosetests
> >  test_genericfunctions.py
> > ...FF
> > ==
> > FAIL: Non-prioritized ambiguous methods are processed fine
> > --
> > Traceback (most recent call last):
> >   File "C:\Documents and
> > Settings\Daystev\Desktop\Downloads\toscawidgets\tests\t
> > est_genericfunctions.py", line 32, in test_non_prioritized_ambiguous
> > self.assertRaises(dispatch.AmbiguousMethod, self.demo_func, 10)
> > AssertionError: AmbiguousMethod not raised
>
> > ==
> > FAIL: Prioritized ambiguous methods are processed fine
> > --
> > Traceback (most recent call last):
> >   File "C:\Documents and
> > Settings\Daystev\Desktop\Downloads\toscawidgets\tests\t
> > est_genericfunctions.py", line 54, in test_prioritized_ambiguous
> > self.assertEqual(self.demo_func(10),0)
> > AssertionError: 10 != 0
>
> > --
> > Ran 5 tests in 0.521s
>
> > FAILED (failures=2):(The only thing I can think of is to try it out in a 
> > clean  
> workingenv. I've done some tests in windows xp using workingenv and  
> everything went smoothly so I guess it's not a windows related problem.
>
> Alberto- Hide quoted text -- Show quoted text -


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[Alberto Valverde]

On Jan 26, 2007, at 7:34 PM, shday wrote:

>
>> So the tests at test_genericfucntions.py are passing? :)
>
> I guess not:
>
> C:\Documents and
> Settings\Daystev\Desktop\Downloads\toscawidgets\tests>nosetests
>  test_genericfunctions.py
> ...FF
> ==
> FAIL: Non-prioritized ambiguous methods are processed fine
> --
> Traceback (most recent call last):
>   File "C:\Documents and
> Settings\Daystev\Desktop\Downloads\toscawidgets\tests\t
> est_genericfunctions.py", line 32, in test_non_prioritized_ambiguous
> self.assertRaises(dispatch.AmbiguousMethod, self.demo_func, 10)
> AssertionError: AmbiguousMethod not raised
>
> ==
> FAIL: Prioritized ambiguous methods are processed fine
> --
> Traceback (most recent call last):
>   File "C:\Documents and
> Settings\Daystev\Desktop\Downloads\toscawidgets\tests\t
> est_genericfunctions.py", line 54, in test_prioritized_ambiguous
> self.assertEqual(self.demo_func(10),0)
> AssertionError: 10 != 0
>
> --
> Ran 5 tests in 0.521s
>
> FAILED (failures=2)

:(The only thing I can think of is to try it out in a clean  
workingenv. I've done some tests in windows xp using workingenv and  
everything went smoothly so I guess it's not a windows related problem.

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[shday]

>So the tests at test_genericfucntions.py are passing? :)

I guess not:

C:\Documents and
Settings\Daystev\Desktop\Downloads\toscawidgets\tests>nosetests
 test_genericfunctions.py
...FF
==
FAIL: Non-prioritized ambiguous methods are processed fine
--
Traceback (most recent call last):
  File "C:\Documents and
Settings\Daystev\Desktop\Downloads\toscawidgets\tests\t
est_genericfunctions.py", line 32, in test_non_prioritized_ambiguous
self.assertRaises(dispatch.AmbiguousMethod, self.demo_func, 10)
AssertionError: AmbiguousMethod not raised

==
FAIL: Prioritized ambiguous methods are processed fine
--
Traceback (most recent call last):
  File "C:\Documents and
Settings\Daystev\Desktop\Downloads\toscawidgets\tests\t
est_genericfunctions.py", line 54, in test_prioritized_ambiguous
self.assertEqual(self.demo_func(10),0)
AssertionError: 10 != 0

--
Ran 5 tests in 0.521s

FAILED (failures=2)

> The error you're getting is the same as 
> in:http://trac.turbogears.org/ticket/1200
>
> Delete al pyc files in tgsample/templates and it should work...
> 
> Alberto

I still get the error... :(


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[Alberto Valverde]

On Jan 26, 2007, at 6:44 PM, shday wrote:

>
> Okay... my easy_install.pth was pointing to a non existent version of
> RuleDispatch (one with (2) at the end which I had removeded 8\ ).
> That's fixed now, but I am getting yet another error
> http://paste.turbogears.org/paste/913

So the tests at test_genericfucntions.py are passing? :)

The error you're getting is the same as in:
http://trac.turbogears.org/ticket/1200

Delete al pyc files in tgsample/templates and it should work...

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[shday]

Okay... my easy_install.pth was pointing to a non existent version of
RuleDispatch (one with (2) at the end which I had removeded 8\ ).
That's fixed now, but I am getting yet another error
http://paste.turbogears.org/paste/913

Here is my easy_install.pth... in case it looks fishy:
http://paste.turbogears.org/paste/914

Steve

On Jan 26, 12:07 pm, Alberto Valverde <[EMAIL PROTECTED]> wrote:
> On Jan 26, 2007, at 5:58 PM, Alberto Valverde wrote:
>
>
>
> > Hmmm, I remember Karl having the same problem with display rules and
> > solved it by erasing the old versions' eggs... can you try that?More 
> > precisely, remove only the old version of RuleDispatch which
> came with TG (which has a bug the new one fixes anyway). I suspect it
> has somethig to do with it's bundled C extension and how setuptools
> treats it's old version...
> 
> Alberto


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[shday]

> > 2) When I upgraded from kid-0.9.3 to 0.9.4 I get an "internal server
> > error". Here is the console output:
> >http://paste.turbogears.org/paste/910This is due to the pyc precompiled 
> >templates 0.9.3 left behind are
> incompatible with 0.9.4. Erase them and that error will dissapear.

Now I get a different error:
http://paste.turbogears.org/paste/912

>Hmmm, I remember Karl having the same problem with display rules and
> solved it by erasing the old versions' eggs... can you try that?

I've also noticed some funky stuff happening if you leave old eggs
around. So now I always prefix the old egg file/folder with an
underscore or delete it...


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[Alberto Valverde]

On Jan 26, 2007, at 5:58 PM, Alberto Valverde wrote:
>
> Hmmm, I remember Karl having the same problem with display rules and
> solved it by erasing the old versions' eggs... can you try that?

More precisely, remove only the old version of RuleDispatch which  
came with TG (which has a bug the new one fixes anyway). I suspect it  
has somethig to do with it's bundled C extension and how setuptools  
treats it's old version...

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[Alberto Valverde]

On Jan 26, 2007, at 5:44 PM, shday wrote:

>
> Hi,
>
> I've update/installed everything in your list:
>
> Genshi-0.3.6-py2.4.egg - "upgraded" with warning messages
> Mako-0.1.1-py2.4.egg - installed it
> MyghtyUtils-0.52-py2.4.egg - installed it
> Paste-1.1.1-py2.4.egg - already had it
> PasteDeploy-1.1-py2.4.egg -upgraded
> PasteScript-1.1-py2.4.egg -upgraded
> PyProtocols-1.0a0dev_r2082-py2.4-macosx-10.4-fat.egg -already had it
> RuleDispatch-0.5a0.dev_r2247-py2.4-macosx-10.4-fat.egg -upgraded
> ToscaWidgets-0.1a2dev_r2453-py2.4.egg - already had it
> TurboCheetah-0.9.5-py2.4.egg - already had it
> TurboKid-0.9.9-py2.4.egg - already had it
> elementtree-1.2.6_20050316-py2.4.egg - upgraded
> kid-0.9.4-py2.4.egg - upgraded but it didn't work at all
> setuptools-0.6c5-py2.4.egg - already had it
> simplejson-1.5-py2.4.egg - upgraded
>
> Note the following:
>
> 1) 5 test now fail when I run the toscawidgets test. The output is
> here:
> http://paste.turbogears.org/paste/909

Hmm, same as before... :-/
>
> 2) When I upgraded from kid-0.9.3 to 0.9.4 I get an "internal server
> error". Here is the console output:
> http://paste.turbogears.org/paste/910

This is due to the pyc precompiled templates 0.9.3 left behind are  
incompatible with 0.9.4. Erase them and that error will dissapear.
>
> If I go back to kid-0.9.3 I get the same bits of raw html as before.
>
> 3) "Upgrading" Genshi (I didn't see the egg file) gave several
> warnings:
> http://paste.turbogears.org/paste/911

No idea... I think you can safely ignore them
>
> 4) The other app I have running on the same computer still works fine.
> Note that it uses only Genshi and there are no widgets of any kind.
>
> I have access to a few other computers here at work, so I can try a
> clean install of everything. One PITA is that I have to download all
> the eggs manually because of my company's firewall (I briefly tried to
> set-up a proxy server with no luck).

Hmmm, I remember Karl having the same problem with display rules and  
solved it by erasing the old versions' eggs... can you try that?

Thanks :)

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[shday]

Hi,

I've update/installed everything in your list:

Genshi-0.3.6-py2.4.egg - "upgraded" with warning messages
Mako-0.1.1-py2.4.egg - installed it
MyghtyUtils-0.52-py2.4.egg - installed it
Paste-1.1.1-py2.4.egg - already had it
PasteDeploy-1.1-py2.4.egg -upgraded
PasteScript-1.1-py2.4.egg -upgraded
PyProtocols-1.0a0dev_r2082-py2.4-macosx-10.4-fat.egg -already had it
RuleDispatch-0.5a0.dev_r2247-py2.4-macosx-10.4-fat.egg -upgraded
ToscaWidgets-0.1a2dev_r2453-py2.4.egg - already had it
TurboCheetah-0.9.5-py2.4.egg - already had it
TurboKid-0.9.9-py2.4.egg - already had it
elementtree-1.2.6_20050316-py2.4.egg - upgraded
kid-0.9.4-py2.4.egg - upgraded but it didn't work at all
setuptools-0.6c5-py2.4.egg - already had it
simplejson-1.5-py2.4.egg - upgraded

Note the following:

1) 5 test now fail when I run the toscawidgets test. The output is
here:
http://paste.turbogears.org/paste/909

2) When I upgraded from kid-0.9.3 to 0.9.4 I get an "internal server
error". Here is the console output:
http://paste.turbogears.org/paste/910

If I go back to kid-0.9.3 I get the same bits of raw html as before.

3) "Upgrading" Genshi (I didn't see the egg file) gave several
warnings:
http://paste.turbogears.org/paste/911

4) The other app I have running on the same computer still works fine.
Note that it uses only Genshi and there are no widgets of any kind.

I have access to a few other computers here at work, so I can try a
clean install of everything. One PITA is that I have to download all
the eggs manually because of my company's firewall (I briefly tried to
set-up a proxy server with no luck).

Steve


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets first alpha has been released!

[Jorge Vargas]

> > On 1/22/07, Alberto Valverde <[EMAIL PROTECTED]> wrote:
> >
> > [...]
> >
> >> In case you haven't read it at the non-trunk ML, I've switched to
> >> simplejson to avoid another C extension dependency (though I might
> >> switch back if I can get a windows precompiled egg).
> >
> > A naive question here, but could you put in place some mechanism to
> > try and import cjson and then if it fails load simplejson (ala
> > celementtre/elementtre) ?
>
> Yep, that would work... :) I would need to list python-cjson as an
> "extras_require" though or else TW will fail to install...

I wanted to learn how to use the json api's in python and I remember
this so here are my findings.

I started playing with this and I got it almost working, keeping the
cjson interface.
they both encode to json without problems but when reading from json
cjson uses str while simplejson uses unicode.

the assumption seems to start in decoder.py lines 81:84
if content:
if not isinstance(content, unicode):
content = unicode(content, encoding)
_append(content)

the only way I can think of making this work is patching simplejson :(

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

"""
>>> import cjson
>>> import simplejson
>>> py = {'key' : 'value','anotherKey':['a','list'],'numbers':(1,3.14),'boolean':True}
>>> py
{'boolean': True, 'anotherKey': ['a', 'list'], 'numbers': (1, 3.1401), 'key': 'value'}
>>> sj=simplejson.dumps(py)
>>> sj
'{"boolean": true, "anotherKey": ["a", "list"], "numbers": [1, 3.14], "key": "value"}'
>>> cj = cjson.encode(py)
>>> cj
'{"boolean": true, "anotherKey": ["a", "list"], "numbers": [1, 3.14], "key": "value"}'
>>> assert sj == cj
>>> simplejson.loads(cj)
{u'boolean': True, u'anotherKey': [u'a', u'list'], u'numbers': [1, 3.1401], u'key': u'value'}
>>> cjson.decode(cj)
{'boolean': True, 'anotherKey': ['a', 'list'], 'numbers': [1, 3.1401], 'key': 'value'}
>>> assert simplejson.load(cj) == cjson.decode(cj)
Traceback (most recent call last):
  File "", line 1, in ?
  File "/home/elpargo/code/python/CP3/lib/python2.4/simplejson-1.5-py2.4.egg/simplejson/__init__.py", line 208, in load
return cls(encoding=encoding, **kw).decode(fp.read())
AttributeError: 'str' object has no attribute 'read'
"""
import doctest
doctest.testmod()

#TODO replace with setuptools stuff
try:
	#import cjson
	import cjsonERROR#make this fail on purpose
except ImportError:
	import simplejson as cjson
	import logging
	logging.warning('cjson not found using the slower simplejson implementation')
	
	def encode(obj):
		return cjson.dumps(obj)
	
	def decode(obj):
		return cjson.loads(obj,encoding='ascii')#doesn't works see decoder.py:82+
		
	setattr(cjson,'encode',encode)
	setattr(cjson,'decode',decode)

py = {'key' : 'value','anotherKey':['a','list'],'numbers':(1,3.14),'boolean':True}
json = cjson.encode(py)
newpy = cjson.decode(json)
assert py == newpy

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[shday]

I ran:

easy_install -f http://toscawidgets.org/download -U RuleDispatch
TurboKid

But I still have the problem with the rendering. The output of the
tests are below. For some reason the test.log file got truncated so I
just pasted from the dos box.

Next I'll try upgrading those packages 1 by 1.

Steve

C:\Documents and
Settings\Daystev\Desktop\Downloads\toscawidgets>python.exe setup.py
develop test
running develop
running egg_info
writing requirements to ToscaWidgets.egg-info\requires.txt
writing ToscaWidgets.egg-info\PKG-INFO
writing namespace_packages to
ToscaWidgets.egg-info\namespace_packages.txt
writing top-level names to ToscaWidgets.egg-info\top_level.txt
writing dependency_links to ToscaWidgets.egg-info\dependency_links.txt
writing entry points to ToscaWidgets.egg-info\entry_points.txt
reading manifest file 'ToscaWidgets.egg-info\SOURCES.txt'
writing manifest file 'ToscaWidgets.egg-info\SOURCES.txt'
running build_ext
Creating c:\python24\lib\site-packages\ToscaWidgets.egg-link (link to
.)
ToscaWidgets 0.1a2dev-r2453 is already the active version in
easy-install.pth

Installed c:\documents and
settings\daystev\desktop\downloads\toscawidgets
Processing dependencies for ToscaWidgets==0.1a2dev-r2453
running test
running build_ext
No handlers could be found for logger "toscawidgets.resources"
Doctest: doc_index.txt ... ok
Doctest: index.txt ... ok
Doctest: toscawidgets.txt ... ok
Doctest: test_base.txt ... ok
Doctest: test_resources.txt ... ok
Doctest: test_view.txt ... ok
Doctest: test_widget_lists.txt ... ok
Doctest: README.txt ... ok
Doctest: toscawidgets.core.Child ... ok
Doctest: toscawidgets.core.Widget ... ok
Doctest: toscawidgets.core.Widget.ifilter_children ... ok
Doctest: toscawidgets.core.Widget.update_params ... ok
Doctest: toscawidgets.core.Widget.walk ... ok
Doctest: toscawidgets.core.WidgetBunch ... ok
Doctest: toscawidgets.core.WidgetsList ... ok
Doctest: toscawidgets.util.pre_post_wrapper ... ok
Doctest: toscawidgets.resources.Source ... ok
Doctest: toscawidgets.js ... ok
Doctest: toscawidgets.js.js_callback ... ok
Doctest: toscawidgets.js.js_function ... ok
test_children_receive_args (tests.test_base.TestArgsForChilds) ... ok
test_are_collected (tests.test_base.TestChildrenAreCollectedFromBases)
... ok
test_is_bunch (tests.test_base.TestDictInUpdateParamsIsABunch) ... ok
test_display_child_accepts_kw (tests.test_base.TestDisplayChild) ... ok
test_normal_display (tests.test_base.TestDisplayChild) ... ok
test_class_and_args_not_modified_on_init
(tests.test_base.TestMutableTemplateVar
sNotClobbered) ... ok
test_instance_and_args_not_modified_on_display
(tests.test_base.TestMutableTempl
ateVarsNotClobbered) ... ok
test_callable_default_params (tests.test_base.TestParams) ... ok
test_callable_display_overriden_params (tests.test_base.TestParams) ...
ok
test_params_are_set_to_None_by_default (tests.test_base.TestParams) ...
ok
test_gets_default (tests.test_base.TestRequestLocalDescriptorDeafult)
... ok
test_can_be_del (tests.test_base.TestRequestLocalDescriptorNoDeafult)
... ok
test_can_be_del_resetted
(tests.test_base.TestRequestLocalDescriptorNoDeafult) .
.. ok
test_can_be_set (tests.test_base.TestRequestLocalDescriptorNoDeafult)
... ok
test_default_is_respected (tests.test_base.TestSimpleWidget) ... ok
test_at_class_template (tests.test_base.TestTemplate) ... ok
test_at_display_template (tests.test_base.TestTemplate) ... ok
test_children_receive_value (tests.test_base.TestValueForChilds) ... ok
test_can_setattr (tests.test_base.TestWidgetBunch) ... ok
test_correct_ids (tests.test_base.TestWidgetRepeater) ... ok
test_limit_repetitions (tests.test_base.TestWidgetRepeater) ... ok
test_render (tests.test_base.TestWidgetRepeater) ... ok
test_children_can_receive_args_by_key
(tests.test_base.TestWidgetRepeaterNestedR
epeated) ... ok
test_children_receive_args
(tests.test_base.TestWidgetRepeaterNestedRepeated) ..
. ok
test_children_receive_args_dotted_id
(tests.test_base.TestWidgetRepeaterNestedRe
peated) ... ok
test_children_receive_args_dotted_id_outside_child_args
(tests.test_base.TestWid
getRepeaterNestedRepeated) ... ok
test_children_receive_values
(tests.test_base.TestWidgetRepeaterNestedRepeated)
... ok
test_correct_ids (tests.test_base.TestWidgetRepeaterNestedRepeated) ...
ok
test_first_child_can_receive_in_dotted_args_outside_child_args
(tests.test_base.
TestWidgetRepeaterNestedRepeated) ... ok
test_limit_repetitions
(tests.test_base.TestWidgetRepeaterNestedRepeated) ... ok

test_render (tests.test_base.TestWidgetRepeaterNestedRepeated) ... ok
test_widget_is_built_correctly
(tests.test_base.TestWidgetRepeaterNestedRepeated
) ... ok
test_order_is_preserved (tests.test_base.TestWidgetsList) ... ok
Priority is respected when decorating with before ... ok
Non-ambiguous methods are processed fine ... ok
NoApplicableMethods is raised when it should ... ok
Non-prioritized ambiguous methods are processed fine ... FAIL
Prioritized ambiguous methods are processed fine ... FAIL
test_can_chain_c

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[Alberto Valverde]

On Jan 25, 2007, at 6:56 PM, shday wrote:

>
> Okay, that got it working... sort of. Most of the page seems to be
> rendered okay but there are large bits of raw html showing also.
>
> http://img49.imageshack.us/img49/7075/tgsamplebug3rs.png

Doh, that should *not* be happening. This has happened before to some  
people but I'm afraid I don't know the root cause yet. I do know what  
the problem is though... display rules are misbehaving. I don't know  
exactly what package is causing it but it has been solved by  
upgrading all packages TW requires which might be already in your  
system. Try upgrading TurboKid and RuleDispatch (from toscawidgets'  
website)

easy_install -f http://toscawidgets/download -U RuleDispatch TurboKid

If it's still a problem, it'll be of great help to me to see the  
output of TW's unittests... to do so


# Install an editable version of TW with tests
easy_install -e -b . ToscaWidgets
cd toscawidgets
python2.4 setup.py develop test
# If tests fail or there are errors...
python2.4 setup.py develop test > test.log

Send me test.log if failures/errors... to see what package might need  
upgrading, this is what TW requires (for all tests, not all template  
engines are needed):

Genshi-0.3.6-py2.4.egg
Mako-0.1.1-py2.4.egg
MyghtyUtils-0.52-py2.4.egg
Paste-1.1.1-py2.4.egg
PasteDeploy-1.1-py2.4.egg
PasteScript-1.1-py2.4.egg
PyProtocols-1.0a0dev_r2082-py2.4-macosx-10.4-fat.egg
RuleDispatch-0.5a0.dev_r2247-py2.4-macosx-10.4-fat.egg
ToscaWidgets-0.1a2dev_r2453-py2.4.egg
TurboCheetah-0.9.5-py2.4.egg
TurboKid-0.9.9-py2.4.egg
elementtree-1.2.6_20050316-py2.4.egg
kid-0.9.4-py2.4.egg
setuptools-0.6c5-py2.4.egg
simplejson-1.5-py2.4.egg

That combination in a clean testing workingenv makes all 139 tests  
pass in my system(s). Try upgrading each of those packages, one by  
one with "easy_install -U"· (mind that for RuleDispatch you'll need  
to pass the -f flag so it downloads it from toscawidgets.org) and run  
the tests in between, as soon as all pass, please tell me who the  
culprit was and what was it's previous version so I can investigate  
and help future users. If all tests pass tgsample should be working  
flawlessly

Alberto


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[shday]

Okay, that got it working... sort of. Most of the page seems to be
rendered okay but there are large bits of raw html showing also.

http://img49.imageshack.us/img49/7075/tgsamplebug3rs.png

I suspect the problem is somewhere with kid or the template (I have
kid-0.9.3-py2.4.egg). I have another tg app on the same computer that
works, but I'm using Genshi for that one. I actually want to use Genshi
for this project also. What I'll probaly try to do is convert your
tgsample app to use Genshi...

Steve

On Jan 25, 6:16 am, Alberto Valverde <[EMAIL PROTECTED]> wrote:
> On Jan 25, 2007, at 4:39 AM, shday wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > I managed to get my boss to allow me to build a very small app (just a
> > single form to update a database) using TG. Anyhow, I figured I'd use
> > ToscaWidgets, but I can't even get the sample app to work.
> >http://svn.turbogears.org/projects/ToscaWidgets/trunk/examples/
> > tgsample/
>
> > Traceback (most recent call last):
> >   File "start-tgsample.py", line 26, in ?
> > from tgsample.controllers import Root
> >   File "C:\Documents and
> > Settings\Daystev\Desktop\tgsample\tgsample\controllers.
> > py", line 12, in ?
> > from tw_samples import AddUserForm
> >   File "C:\Documents and
> > Settings\Daystev\Desktop\tgsample\tgsample\tw_samples\_
> > _init__.py", line 2, in ?
> > from js_forms import AddUserForm
> >   File "C:\Documents and
> > Settings\Daystev\Desktop\tgsample\tgsample\tw_samples\j
> > s_forms.py", line 7, in ?
> > from toscawidgets.widgets.mochikit import mochikit, connect
> > ImportError: No module named mochikit
>
> > I'm using r2453 of ToscaWidgets. Is this sample app badly broken,  
> > or is
> > there an easy fix here?... I couldn't figure it out.MochiKit lives in a 
> > separate egg, twMochiKit. You can either install  
> that manually by:
>
> easy_install twMochiKit
>
> or upgrade tgsample which I just fixed to correct the dependencies so  
> it automatically pulls everything it needs:
>
> easy_install -fhttp://toscawidgets.org/download-U tgsample
> 
> Alberto- Hide quoted text -- Show quoted text -


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets "TG sample app" is broken

[Alberto Valverde]

On Jan 25, 2007, at 4:39 AM, shday wrote:

>
> Hi,
>
> I managed to get my boss to allow me to build a very small app (just a
> single form to update a database) using TG. Anyhow, I figured I'd use
> ToscaWidgets, but I can't even get the sample app to work.
> http://svn.turbogears.org/projects/ToscaWidgets/trunk/examples/ 
> tgsample/
>
> Traceback (most recent call last):
>   File "start-tgsample.py", line 26, in ?
> from tgsample.controllers import Root
>   File "C:\Documents and
> Settings\Daystev\Desktop\tgsample\tgsample\controllers.
> py", line 12, in ?
> from tw_samples import AddUserForm
>   File "C:\Documents and
> Settings\Daystev\Desktop\tgsample\tgsample\tw_samples\_
> _init__.py", line 2, in ?
> from js_forms import AddUserForm
>   File "C:\Documents and
> Settings\Daystev\Desktop\tgsample\tgsample\tw_samples\j
> s_forms.py", line 7, in ?
> from toscawidgets.widgets.mochikit import mochikit, connect
> ImportError: No module named mochikit
>
>
> I'm using r2453 of ToscaWidgets. Is this sample app badly broken,  
> or is
> there an easy fix here?... I couldn't figure it out.

MochiKit lives in a separate egg, twMochiKit. You can either install  
that manually by:

easy_install twMochiKit

or upgrade tgsample which I just fixed to correct the dependencies so  
it automatically pulls everything it needs:

easy_install -f http://toscawidgets.org/download -U tgsample

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets first alpha has been released!

[Alberto Valverde]

On Jan 22, 2007, at 9:59 PM, Florent Aide wrote:

>
> On 1/22/07, Alberto Valverde <[EMAIL PROTECTED]> wrote:
>
> [...]
>
>> In case you haven't read it at the non-trunk ML, I've switched to
>> simplejson to avoid another C extension dependency (though I might
>> switch back if I can get a windows precompiled egg).
>
> A naive question here, but could you put in place some mechanism to
> try and import cjson and then if it fails load simplejson (ala
> celementtre/elementtre) ?

Yep, that would work... :) I would need to list python-cjson as an  
"extras_require" though or else TW will fail to install...

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets first alpha has been released!

[Florent Aide]

On 1/22/07, Alberto Valverde <[EMAIL PROTECTED]> wrote:

[...]

> In case you haven't read it at the non-trunk ML, I've switched to
> simplejson to avoid another C extension dependency (though I might
> switch back if I can get a windows precompiled egg).

A naive question here, but could you put in place some mechanism to
try and import cjson and then if it fails load simplejson (ala
celementtre/elementtre) ?

Maybe that's what you did I did not look at the sources yet ;)

Florent.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets first alpha has been released!

[Alberto Valverde]

On Jan 21, 2007, at 9:40 AM, [EMAIL PROTECTED] wrote:

>
> Hi:
>
> ToscaWidgets looks cool but I had a problem to install the current
> version on windows because it depends with cjson, which need a vc 2003
> compiler (I do have vc 2005 express version).

In case you haven't read it at the non-trunk ML, I've switched to  
simplejson to avoid another C extension dependency (though I might  
switch back if I can get a windows precompiled egg).

easy_install -U ToscaWidgets

To install the latest snapshot.

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets first alpha has been released!

[Alberto Valverde]

On Jan 21, 2007, at 9:40 AM, [EMAIL PROTECTED] wrote:

>
> Hi:
>
> ToscaWidgets looks cool but I had a problem to install the current
> version on windows because it depends with cjson, which need a vc 2003
> compiler (I do have vc 2005 express version).

Hmmm, I should provide pre-compiled eggs at http://toscawidgets/ 
download then... However, I haven't got a windows compiler... :(
Can someone please send me privately a pre-compiled win32 egg for  
python-cjson?

Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets first alpha has been released!

[Robin Bryce]

Excellent work,

> * You no longer need to register_static_directories for JS and
> CSSLinks. These are registered automatically when Links are initialized
> so that's less bolier-plate for you. The syntax is also friendlier and
> takes care of finding the full path for resources for you:
>
> JSLink(modname='turbogears', filename='static/js/MochiKit.js')
>
> will automatically link to the mochikit TG 1.0 bundles (uses
> pkg_resources.resource_filename internally)
>

I'd like to see this patch http://trac.turbogears.org/ticket/1257, or
something like it applied.

I thought of futzing around with some extra complexity that would
allow CSSLink(modname=Requirement.parse("site >= 1.2"),
'static/site.css') to be relative to the top level package name (same
as existing modname behaviour) and
CSSLink(modname=Requirement.parse("site >= 1.2"), '/static/site.css')
to be the 'egg-root' relative one.

But in the end this didn't seem worth the pain, 'egg-root' is what I
want, and resource_accessor(Requirement.parse('proj >= M.m'), '')
always gives you the path to the directory (or zipfile) that contains
the .egg-info dir.


Cheers,
Robin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets first alpha has been released!

[[EMAIL PROTECTED]]

Hi:

ToscaWidgets looks cool but I had a problem to install the current
version on windows because it depends with cjson, which need a vc 2003
compiler (I do have vc 2005 express version).


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: What is the timeframe for a first release?

[Jorge Godoy]

Alberto Valverde <[EMAIL PROTECTED]> writes:


I'm afraid you can't have a genshi (nor kid) template consisting of a single
XML opening or closing tag (it's not well formed XML) so neither
tabber_start or tabber_end can be implemented as single widgets. However,
you can create a DIV FormFieldContainer widget which has the correct css
class so the tabber's javascript makes it into a tab. The list tabber as the
widget's javascript and it should be included in every page automatically.


Yes, this is possible but it looks so ugly...  Specially when you need just
one item inside the container.  Maybe this is a widget that could be
implemented using Cheetah :-)

The tabber was just one example but there might be other things that could be
done and benefit from that.  Of course all of them might use the -- ugly --
solution above :-)


P.S Happy new year! ;)


For you and everyone else here as well :-)

--
Jorge Godoy  <[EMAIL PROTECTED]>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: What is the timeframe for a first release?

[Alberto Valverde]

On Dec 26, 2006, at 7:10 PM, Jorge Godoy wrote:



Alberto Valverde <[EMAIL PROTECTED]> writes:


3) I need to implement a way to signal all root widgets what template
language they're displaying on. The current implementation needs   
manually
setting toscawidgets.framework.default_view in each request.  That  
is fine for
Pylons as the framework object only lives for one  request... but  
it's
problematic on TG 1.0b2 which keeps the same  framework instance  
for the whole

app's lifetime.

4) Some other minor tweaks here and there... (grep recursively  
for  "XXX" to

find out)


I'd like to see the possibility to send a complementary pair of  
widgets so
that we can enclose other elements within them.  This would be  
useful for,

e.g., the Tabber widget:

   class MyNewMegaFormWidgets(widgets.WidgetsList):
 #
 # widgets outside of tabs here
 #
 tabber_start = widgets.StartElement(
 template = '')
 tabbertab_start = widgets.StartElement(
 template = '')
 #  # Other widgets inside this tab here
 #
 tabbertab_end = widgets.EndElement(
 template = '')
 tabbertab_start = widgets.StartElement(
 template = '')
 #  # Other widgets inside this tab here
 #
 tabbertab_end = widgets.EndElement(
 template = '')
 tabber_end = widgets.EndElement(
 template = '')
 #
 # widgets outside of tabs here
 #


If I were implementing that I'd also make a requirement that the  
names be

"_start" and that there's always a "_end".  The
generated names (id, classes, whatever) would use only the  
"" part,

without "start" or "end".
This can't be easily done with Kid (can it be done?) but I believe  
that Genshi

would allow that more easily...


I'm afraid you can't have a genshi (nor kid) template consisting of a  
single XML opening or closing tag (it's not well formed XML) so  
neither tabber_start or tabber_end can be implemented as single  
widgets. However, you can create a DIV FormFieldContainer widget  
which has the correct css class so the tabber's javascript makes it  
into a tab. The list tabber as the widget's javascript and it should  
be included in every page automatically.


Alberto.

P.S Happy new year! ;)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: What is the timeframe for a first release?

[Jorge Godoy]

Alberto Valverde <[EMAIL PROTECTED]> writes:


3) I need to implement a way to signal all root widgets what template
language they're displaying on. The current implementation needs  manually
setting toscawidgets.framework.default_view in each request.  That is fine for
Pylons as the framework object only lives for one  request... but it's
problematic on TG 1.0b2 which keeps the same  framework instance for the whole
app's lifetime.

4) Some other minor tweaks here and there... (grep recursively for  "XXX" to
find out)


I'd like to see the possibility to send a complementary pair of widgets so
that we can enclose other elements within them.  This would be useful for,
e.g., the Tabber widget:

   class MyNewMegaFormWidgets(widgets.WidgetsList):
 #
 # widgets outside of tabs here
 #
 tabber_start = widgets.StartElement(
 template = '')
 tabbertab_start = widgets.StartElement(
 template = '')
 # 
 # Other widgets inside this tab here

 #
 tabbertab_end = widgets.EndElement(
 template = '')
 tabbertab_start = widgets.StartElement(
 template = '')
 # 
 # Other widgets inside this tab here

 #
 tabbertab_end = widgets.EndElement(
 template = '')
 tabber_end = widgets.EndElement(
 template = '')
 #
 # widgets outside of tabs here
 #


If I were implementing that I'd also make a requirement that the names be
"_start" and that there's always a "_end".  The
generated names (id, classes, whatever) would use only the "" part,
without "start" or "end". 


This can't be easily done with Kid (can it be done?) but I believe that Genshi
would allow that more easily... 


--
Jorge Godoy  <[EMAIL PROTECTED]>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets: What is the timeframe for a first release?

[Alberto Valverde]

On Dec 25, 2006, at 9:43 AM, Bill wrote:



Hello Alberto,

I see that you are a very busy fellow these days.  There are lots of
changes and code reorganization going on in the ToscaWidgets SVN.  So
far I've been able to keep my Pylons test code in sync with the
changes.   But it's got me wondering when we can plan on something  
like

an initial beta release; something we can start building prototype
applications around.  Do you have any thoughts on a timeframe?  Or is
it just too early to tell?



Ooops, sorry. I was planning to announce all tha code shuffling and  
provide some "migration" guidelines but had no time to do it until  
now. Glad you've managed to keep up (looks like you're a good "svn  
log" reader... ;)


I was in fact planning to release a first alpha in about 2 or 3 weeks  
which should begin working towards API stability. There are a couple  
of things I'd like to polish up first:


1) toscawidgets.js.functions needs to address those XXXs (\me clears  
his throat... I mean, #XXX marks in the code)


2) write some docs. The api is already covered by the (improveable)  
docstrings and pudge. However, some real-world examples and a  
tutorial are needed.


3) I need to implement a way to signal all root widgets what template  
language they're displaying on. The current implementation needs  
manually setting toscawidgets.framework.default_view in each request.  
That is fine for Pylons as the framework object only lives for one  
request... but it's problematic on TG 1.0b2 which keeps the same  
framework instance for the whole app's lifetime.


4) Some other minor tweaks here and there... (grep recursively for  
"XXX" to find out)


Best regards,
Alberto

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets Pylons sample: initial http request fails

[Kevin Dangoor]

On Dec 21, 2006, at 3:55 PM, Bill wrote:


A  bit of confusion here.  I originally posted this on the
pylons-discuss group but it didn't show up for hours so I thought
something was wrong.   I decided to then post here to see if it would
get through to Alberto one way or another.  Well, a day later my
original post shows up on pylons-discuss and Alberto has addressed it
there.  I didn't realize the posts on Google Groups take so long to
arrive.


I wouldn't be surprised if Ben has the pylons list set up the same  
way the TG lists are: new members are moderated. It prevents spam  
from making it through.


Kevin


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets Pylons sample: initial http request fails

[Bill]

Hi All,

On Dec 20, 10:48 am, "Bill" <[EMAIL PROTECTED]> wrote:

I've been experimenting with the Pylons ToscaWidgets (TW) sample with



A  bit of confusion here.  I originally posted this on the
pylons-discuss group but it didn't show up for hours so I thought
something was wrong.   I decided to then post here to see if it would
get through to Alberto one way or another.  Well, a day later my
original post shows up on pylons-discuss and Alberto has addressed it
there.  I didn't realize the posts on Google Groups take so long to
arrive.

Sorry for the confusion,
Bill


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets and Pylons: should I post here?

[Kevin Dangoor]

On 12/20/06, Bill <[EMAIL PROTECTED]> wrote:


I've been experimenting with the Pylons ToscaWidgets sample.  I have
been doing some debugging.  Should I report my analysis here or on the
pylons-discuss group?


This is a good place to talk about ToscaWidgets-related issues.

Kevin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Ian Bicking]

Karl Guertin wrote:
> On 12/12/06, Jonathan LaCour <[EMAIL PROTECTED]> wrote:
>> You could even have it generate a cached version that
>> gets run through a JavaScript packing tool.
> 
> The problem with this is that unless the extraction is done on a
> site-wide basis, you'll have to re-download the same set of core
> components repeatedly. e.g. If one component uses only MochiKit.Async
> and one uses MochiKit.Visual, you'll have to download Base and Iter
> (off the top of my head) twice. It doesn't take too long before it's
> quicker just to grab everything once.
> 
> I'm interested in dojo's experimental javascript linker. It should be
> possible to  get it worked into the toolchain as part of the
> deployment process and have it produced a minimized single download of
> all the javascript in a project. AOL donated it right before 0.4, but
> I haven't heard much about it since.

That sounds like a much better idea, though it requires whole-project 
analysis of how what libraries you use (potentially even whole-site). 
Then ideally you'd gzip that ahead of time, and send that gzip encoded. 
  (By not gzipping in a filter it's a lot easier to figure out things 
like Content-Length.)

-- 
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Karl Guertin]

On 12/12/06, Karl Guertin <[EMAIL PROTECTED]> wrote:
> I'm interested in dojo's experimental javascript linker.

So I did a bit of testing to see what was up with this. The good news
is that it compiles cleanly (yay!) and it seems to work on the test
cases. The bad news is that the current version of the code removal
action (janitor) is built for the dojo codebase. Basically, the tool
builds an AST of the source code, detects assignments at the global
level and builds a callgraph off of that.

e.g.


dojo.a = function(){dojo.b();}
dojo.b = function(){alert('b');}
dojo.c = function(){alert('c');}

In the above example the linker recognizes all three assignments and
if dojo.a is the entry point, will correctly include dojo.b and
eliminate dojo.c. Not so with the following code:

dojo = {
  'a':function(){dojo.b;},
  'b':function(){alert('b');},
  'c':function(){alert('c');}
}

Here the assignment isn't recognized as a function and no callgraph is
built. Unfortunately, the second example is how the MochiKit (and most
other JS libraries) is written, so it doesn't look like this linker
will be working on MochiKit very soon. Actually, it's a bit more
complex in MochiKit because MochiKit.Base.update() is used to modify
items after it's been declared, so I don't see how an AST parser can
reliably detect code written using this style.

Anyway, figured people might be interested.

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[fumanchu]

Ian Charnas wrote:
> I realize that I'm moving off-topic, but I think that a CherryPy filter
> (now called a 'hook') is the place to do javascript compression (read:
> removing comments and whitespace, changing variable names to
> single-letters) and also (of course) gzip compression.  A CherryPy
> filter could be made that does both of these things

IMO it would be silly to make your new filter do gzip, as that's
already available as a builtin filter/tool (the overhead of calling a
separate hook for gzip is negligible).

> Has this already been done?  Does anyone forsee more than typical
> trouble with changing the html output as I suggested in the last part
> there?  This seems to be something TurboGears should include, as it's
> useful at the framework level.

+1


Robert Brewer
System Architect
Amor Ministries
[EMAIL PROTECTED]


--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Karl Guertin]

On 12/12/06, Jonathan LaCour <[EMAIL PROTECTED]> wrote:
> You could even have it generate a cached version that
> gets run through a JavaScript packing tool.

The problem with this is that unless the extraction is done on a
site-wide basis, you'll have to re-download the same set of core
components repeatedly. e.g. If one component uses only MochiKit.Async
and one uses MochiKit.Visual, you'll have to download Base and Iter
(off the top of my head) twice. It doesn't take too long before it's
quicker just to grab everything once.

I'm interested in dojo's experimental javascript linker. It should be
possible to  get it worked into the toolchain as part of the
deployment process and have it produced a minimized single download of
all the javascript in a project. AOL donated it right before 0.4, but
I haven't heard much about it since.

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Ian Charnas]

On Dec 12, 7:27 am, Kevin Dangoor <[EMAIL PROTECTED]> wrote:
>That's true. From the tests I've been reading lately, making fewer
> requests to the server has a bigger impact on the client-side
> performance than most anything else.

I've found that to be true as well.  Even with keep-alive, the cost (in
time) for each request seems to be worth just as much as compression.

I realize that I'm moving off-topic, but I think that a CherryPy filter
(now called a 'hook') is the place to do javascript compression (read:
removing comments and whitespace, changing variable names to
single-letters) and also (of course) gzip compression.  A CherryPy
filter could be made that does both of these things, takes into account
browser quirks, and caches the results for better performance.  On top
of that, such a filter could (potentially) also read through the html,
and convert the multiple javascript and css links and includes into one
JS file request and one CSS file request, again caching the results.

Has this already been done?  Does anyone forsee more than typical
trouble with changing the html output as I suggested in the last part
there?  This seems to be something TurboGears should include, as it's
useful at the framework level.

Saving half a second in load time makes all the difference with today's
web apps!

-ian


--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Jonathan LaCour]

Kevin Dangoor wrote:

>> However, I'm not sure of the net benefit of this... surely total page
>> size will drop, but I've seen many places that recommend joining all
>> JS (and CSS) into a single file for lower load on the server... I
>> guess a "mochikit_full" will keep everyone happy :)
>
> That's true. From the tests I've been reading lately, making fewer
> requests to the server has a bigger impact on the client-side
> performance than most anything else. If you're looking for more than
> just a couple of functions from MochiKit, having one JavaScript file
> speeds things up considerably over having several.

In this case, it might be a useful optimization to create a widget
that you can pass a list of JavaScript files and when its inserted
into a template, it will generate a single static file to minimize
server traffic.  You could even have it generate a cached version that
gets run through a JavaScript packing tool.

Seems an interesting idea, at least...

--
Jonathan LaCour
http://cleverdevil.org


--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Kevin Dangoor]

On Dec 11, 2006, at 7:44 PM, Alberto Valverde wrote:

> However, I'm not sure of the net benefit of this... surely total page
> size will drop, but I've seen many places that recommend joining all
> JS (and CSS) into a single file for lower load on the server... I
> guess a "mochikit_full" will keep everyone happy :)

That's true. From the tests I've been reading lately, making fewer  
requests to the server has a bigger impact on the client-side  
performance than most anything else. If you're looking for more than  
just a couple of functions from MochiKit, having one JavaScript file  
speeds things up considerably over having several.

Kevin


--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Ian Charnas]

+1 on this.  Although it's more work, if it's going to really be
framework-independent then we need to support at least some of the
major javascript kits.

-ian

On Dec 11, 2:40 pm, Alberto Valverde <[EMAIL PROTECTED]> wrote:
> On Dec 11, 2006, at 12:47 AM, Lee McFadden wrote:
>
>
>
> > I think that if ToscaWidgets are to be truly framework independant
> > then the core widgets shouldn't use a JS library at all.This is more or 
> > less what I've been thinking about as I've meditated
> the issue more carefully...
>
> How about not including *any* JS library at all?
>
> I mean, my idea for ToscaWidgets (the ToscaWidgets distribution egg
> itself) since I splitted the forms into a separate distribution was
> to provide only the core "framework" to build widgets with.  In fact,
> the only Widget it bundles at the moment is
> toscawidgets.js_interface.mochikit which is needed for the
> "add_event_handler" stuff (which I'm thinking to remove as well).
>
> Since I decided to remove the Genshi dependancy on the widgets core
> to allow flexibility it now seems contradictory to "force" a specific
> JS library to users
>
> So now my plan for action is:
>
> 1) new ToscaWidgetsMochi egg with the mochikit widget
> 2) new ToscaWidgetsJQuery egg with the jQuery widget and wrappers for
> the cool accordions, tabs, bells and whistles.
> 3) js_interface.core.EventAware bye, bye... so no ties to any
> specific events API. the js_inteface.functions wrappers (which I'm
> about to rewrite as the current implementation sux) should enable
> writting EventAware mixins using the JS library of choice.
> 
> Does it sound reasonable?
> 
> Alberto


--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Karl Guertin]

On 12/12/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
> I guess it was added: http://mochikit.com/doc/html/MochiKit/Selector.html

Wonder how I managed to miss that...

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Ian Bicking]

Jorge Godoy wrote:
> There was an implementation of that on the MochiKit mailing list
>   

I guess it was added: http://mochikit.com/doc/html/MochiKit/Selector.html




--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Karl Guertin]

I'll pitch in my opinions:

On 12/11/06, Kevin Dangoor <[EMAIL PROTECTED]> wrote:
> Dojo has more features than any other JavaScript toolkit that I've come
> across (it also has the infrastructure to support that -- flexible build
> system, new inline documentation tool). Perhaps it's slower, I haven't seen
> any quantitative comparison.

I love the dojo core (io, event, infrastructure) and some of the
addons (storage) but am displeased with dojo.widgets. I've never been
a huge fan of the invasive style dojo's widgets are based on, but I
can live with that. What's soured me on the implementation is that
every widget I've tried has been based on design decisions opposite to
my preferences*.

The goal seems to be implementing a windowing toolkit for any DOM/CSS
environment. This leads to widgets that work poorly standalone but
reasonably well together. The occasional widget I use from the library
is usually very heavy due to the widgets infrastructure it's built on,
integrates poorly with non-dojo elements on the page, is difficult to
customize, and is often buggy (I'm looking at you, ComboBox). I
generally wind up having to rewrite substantial parts of the widget in
order to get something I'm happy with. As far as speed, I can't decide
if dojo widgets are slow or if I'm not using it correctly. It seems to
work well enough on the dojo site.

I am currently fond of the YUI widgets, which I find to be very well
written with design decisions I agree with. I plan on porting them to
MochiKit at some point in the near future.

*  My philosophy is that we need to develop interaction
patterns that work well on the web. We've been living with interaction
patterns invented for a simpler computing environment. These patterns
aren't necessarily the best patterns, but it hasn't been worth
throwing away familiarity to experiment with new patterns.

The rise of ajax apps gives us a clean break in user expectations and
therefore the opportunity to invent new patterns. The next 3-4 years
is a very exciting time if you're interested in interaction design.
I'm not going to waste the opportunity by copying the desktop poorly.
The humanized[1] blog provides more detail. He uses 'humane' like the
python community uses 'pythonic'. I don't agree with everything the
Raskins come up with, but I do agree here.

[1] 
http://www.humanized.com/weblog/2006/11/06/web_20_is_converging_towards_the_desktop_good/

> MochiKit 1.4 (with either the Scriptaculous port or Karl's newer Animator
> library) seems to do just about everything the others (proto+Scriptaculous,
> jQuery, moo) do. jQuery has the CSS selector thing, but if it's truly useful
> I'd imagine that Bob would consider a patch to add it to MochiKit.

I believe that Bob has turned this idea down with the justification
that MochiKit plays just fine with an external CSS Selector lib. I've
been happy with Dean Edwards' cssQuery[2], but I'm not sure if it's
the fastest approach anymore. I believe that the dojo.behavior
implementation is still using Alex Russell's hack rather than Edwards'
suggested improvements[3]. I glanced through the jQuery docs and they
seem to be using the cssQuery (i.e. slower) techniques, though I
didn't actually trace the code path.

[2] http://dean.edwards.name/my/cssQuery/
[3] http://dean.edwards.name/weblog/2006/03/faster/?full

> MochiKit's bigger, if you're using an all-in-one MochiKit.js, but MochiKit's 
> also modular if you want to use it that way.

I need to get around to setting up a clever web page like mootools[3].
For downloading MochiKit. It'll still be big compared to other
frameworks, but that should make it a good bit simpler to use
modularly.

[3] http://mootools.net/download/

As for jQuery vs MochiKit:

I'll admit that I haven't used jQuery, but it does have a terse API
and doesn't prototype hack, so it's worth a shot. The single page to
collect all the addons is a particularly good move. On the downside, I
do wish they'd chosen something with fewer conflicts than $. I'll have
to experiment with using it for sprinkle-on-js pages since I like the
API better than moo.

MochiKit tackles some bigger problems (comparison, deferreds, signals)
that are important to me when I'm doing client-side app development.
I'm pretty happy with MochiKit for general use, but it is on the heavy
side when all you want is just ___.

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Alberto Valverde]

On Dec 12, 2006, at 1:22 AM, Jorge Godoy wrote:
>> MochiKit's bigger, if you're using an all-in-one MochiKit.js, but  
>> MochiKit's
>> also modular if you want to use it that way.
>
> It is hard to use it modularly with our current implementation...   
> If we need
> it our widgets will call the packed version...  If we start  
> splitting things
> as needed for widgets then we might end up loading things twice...

Hmmm, I'm going to play with this idea when (re)packing MochiKit into  
a TW...

TW allows JSLinks & JSSources to have a "javascript" attribute like  
other widgets have, JS* included there will get into the page  
*before* the Link/Source itself. This means that a JS* can list it's  
dependencies there so they get automatically included in the template.

Maybe MochiKit can be splitted so it's DOM, Signal, Base, etc...  
modules live in different files (can this be done? I mean, does MK  
function properly if splitted in this way?).

TW should take care of pulling MK.Base, MK.Style and MK.Iter into the  
template if a widget requires MK.DOM (for example).

However, I'm not sure of the net benefit of this... surely total page  
size will drop, but I've seen many places that recommend joining all  
JS (and CSS) into a single file for lower load on the server... I  
guess a "mochikit_full" will keep everyone happy :)

Alberto

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Jorge Godoy]

Kevin Dangoor <[EMAIL PROTECTED]> writes:

> TurboGears 2.0 will be 100 eggs by the time we're done with this )

I don't mind.  setuptools downloads everything that is required :-) 

> Luckily, tgsetup.py will make it one install. We'll definitely need  
> to have a script to provide an offline install solution then.

I hope it helps people that are not on *nix...  


-- 
Jorge Godoy  <[EMAIL PROTECTED]>

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Jorge Godoy]

Kevin Dangoor <[EMAIL PROTECTED]> writes:

> MochiKit 1.4 (with either the Scriptaculous port or Karl's newer Animator
> library) seems to do just about everything the others (proto+Scriptaculous,
> jQuery, moo) do. jQuery has the CSS selector thing, but if it's truly useful
> I'd imagine that Bob would consider a patch to add it to MochiKit.

There was an implementation of that on the MochiKit mailing list.

> MochiKit's bigger, if you're using an all-in-one MochiKit.js, but MochiKit's
> also modular if you want to use it that way.

It is hard to use it modularly with our current implementation...  If we need
it our widgets will call the packed version...  If we start splitting things
as needed for widgets then we might end up loading things twice...  Looking at
this, a small library would be more interesting, but if we have to search
around for everything that we have with MochiKit (its DOM manipulation is
simply great!) then it will be a great loss.


Be seeing you,
-- 
Jorge Godoy  <[EMAIL PROTECTED]>

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Kevin Dangoor]

On Dec 11, 2006, at 2:40 PM, Alberto Valverde wrote:

> So now my plan for action is:
>
> 1) new ToscaWidgetsMochi egg with the mochikit widget
> 2) new ToscaWidgetsJQuery egg with the jQuery widget and wrappers for
> the cool accordions, tabs, bells and whistles.
> 3) js_interface.core.EventAware bye, bye... so no ties to any
> specific events API. the js_inteface.functions wrappers (which I'm
> about to rewrite as the current implementation sux) should enable
> writting EventAware mixins using the JS library of choice.
>
> Does it sound reasonable?

A framework-independent library needs to be even more flexible and  
open than one that is part of a framework like TurboGears... so I  
think this makes sense for ToscaWidgets.

TurboGears 2.0 will be 100 eggs by the time we're done with this )

Luckily, tgsetup.py will make it one install. We'll definitely need  
to have a script to provide an offline install solution then.

Kevin


--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Kevin Dangoor]

On Dec 11, 2006, at 2:08 AM, Max Ischenko wrote:

>
>
> On 12/10/06, Ian Charnas <[EMAIL PROTECTED]> wrote:
> Is the accordion in jquery any better than
> the accordion in mootools?  Is scriptaculous' lightbox any better than
> jquery's graybox?  Because we can't provide them all so that people  
> can
> use whichever they want for their application, I think we need to pick
> one that has the widest audience base, and one that can work well with
> other more application-specific frameworks.
>
> I came to a different conclusion.
>
> Because we don't have a clear winner it is much more important to  
> able to use _any_ js library user likes and/or uses in the project.  
> ToscaWidgets just has to play nicely with different libraries.
>

The reason this question comes up, however, is that Alberto would  
probably want to ship some rich widgets, as we do currently. And  
writing all of that "richness" specifically into ToscaWidgets doesn't  
seem wise... therefore, a choice of toolkit is necessary.

Dojo has more features than any other JavaScript toolkit that I've  
come across (it also has the infrastructure to support that --  
flexible build system, new inline documentation tool). Perhaps it's  
slower, I haven't seen any quantitative comparison.

MochiKit 1.4 (with either the Scriptaculous port or Karl's newer  
Animator library) seems to do just about everything the others (proto 
+Scriptaculous, jQuery, moo) do. jQuery has the CSS selector thing,  
but if it's truly useful I'd imagine that Bob would consider a patch  
to add it to MochiKit.

MochiKit's bigger, if you're using an all-in-one MochiKit.js, but  
MochiKit's also modular if you want to use it that way.

I recognize that among tools of similar levels of power, the choice  
comes down to a qualitative one rather than a quantitative one. It's  
often a matter of which library "feels" right. I'd be interested to  
see snippets of code that people think are illuminating and  
interesting about the feel of a given library.

Kevin



--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Alberto Valverde]

On Dec 11, 2006, at 12:47 AM, Lee McFadden wrote:

>
> I think that if ToscaWidgets are to be truly framework independant
> then the core widgets shouldn't use a JS library at all.

This is more or less what I've been thinking about as I've meditated  
the issue more carefully...

How about not including *any* JS library at all?

I mean, my idea for ToscaWidgets (the ToscaWidgets distribution egg  
itself) since I splitted the forms into a separate distribution was  
to provide only the core "framework" to build widgets with.  In fact,  
the only Widget it bundles at the moment is  
toscawidgets.js_interface.mochikit which is needed for the  
"add_event_handler" stuff (which I'm thinking to remove as well).

Since I decided to remove the Genshi dependancy on the widgets core  
to allow flexibility it now seems contradictory to "force" a specific  
JS library to users

So now my plan for action is:

1) new ToscaWidgetsMochi egg with the mochikit widget
2) new ToscaWidgetsJQuery egg with the jQuery widget and wrappers for  
the cool accordions, tabs, bells and whistles.
3) js_interface.core.EventAware bye, bye... so no ties to any  
specific events API. the js_inteface.functions wrappers (which I'm  
about to rewrite as the current implementation sux) should enable  
writting EventAware mixins using the JS library of choice.

Does it sound reasonable?

Alberto


--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---

[tg-trunk] Re: ToscaWidgets to bundle jQuery

[Max Ischenko]

On 12/10/06, Ian Charnas <[EMAIL PROTECTED]> wrote:
>
> Is the accordion in jquery any better than
> the accordion in mootools?  Is scriptaculous' lightbox any better than
> jquery's graybox?  Because we can't provide them all so that people can
> use whichever they want for their application, I think we need to pick
> one that has the widest audience base, and one that can work well with
> other more application-specific frameworks.


I came to a different conclusion.

Because we don't have a clear winner it is much more important to able to
use _any_ js library user likes and/or uses in the project. ToscaWidgets
just has to play nicely with different libraries.

Just my opinion,
Max.


--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---