TW 0.9.8 & non-wsgi middleware (TG 1)
Christophe de VIENNE
When I upgrade TW on my TG1 application, I get errors like :
2009-10-23 12:28:24,678 cherrypy.msg INFO HTTP: Traceback (most recent call last):
File "/home/cdevienne/ws/starform-7.1/lib/python2.5/site-packages/cherrypy-2.3.0-py2.5.egg/cherrypy/_cphttptools.py", line 119, in _run
applyFilters('before_main')
File "/home/cdevienne/ws/starform-7.1/lib/python2.5/site-packages/cherrypy-2.3.0-py2.5.egg/cherrypy/filters/__init__.py", line 151, in applyFilters
method()
File "/home/cdevienne/prog/ToscaWidgets/tw/mods/cp2.py", line 53, in before_main
stream, ct, enc = reg.get_stream_type_encoding(path)
File "/home/cdevienne/prog/ToscaWidgets/tw/core/resources.py", line 202, in get_stream_type_encoding
path_info = req.path_info
AttributeError: 'str' object has no attribute 'path_info'
It seems that ResourcesApp.get_stream_type_encoding waits for a webob Request instance, but the cp2 mod gives it a path.
My understanding is that ResourcesApp is not designed to work propertly in non-wsgi environment.
Do you think we make it CP2 compliant easily ?
I will give it a try but I would welcome any advice/hint/opinion.
Thanks,
Christophe
Diez B. Roggisch
Hm. TW is WSGI - and IMHO whatever you do, you need to make it in a way that
it will fool TW into thinking that it *is* WSGI. You can construct
Request-objects yourself easily, and populate them with whatever environ TW
expects. So if you create an additional adapter-project, that would be the
best way to go I'd say.
Diez
Christophe de VIENNE
It make sense, but I am having a hard time juggling with Request, Response and start_response in mods.cp2.
The thing is that tw<0.4.8 was working properly with cp2, so it is a nasty regression for TG1 users that are using TW.
Anyway, if someone knowing wsgi could have a look at mods.cp2.TWInitFilter.before_main, I would be glad.
Thanks
Christophe
Christophe de VIENNE
Ok, here is bundle that make before_main work the same way it did before. However it uses directly get_stream_type_encoding instead of __call__, which means the new callback feature will not work.
It is still worth applying since it avoid a regression.
diff -r 4e306e08dcfb -r 5ba455b3eb9a tw/mods/cp2.py
--- a/tw/mods/cp2.py Fri Sep 25 14:46:32 2009 -0600
+++ b/tw/mods/cp2.py Fri Oct 23 16:12:51 2009 +0200
@@ -50,7 +50,12 @@
if path.startswith(self.prefix):
reg = resources.registry
path = path[len(self.prefix)+len(reg.prefix):]
- stream, ct, enc = reg.get_stream_type_encoding(path)
+ class FakeRequest(object):
+ path_info = path
+ params = req.params
+ environ = {}
+ stream, ct, enc = reg.get_stream_type_encoding(
+ FakeRequest())
if stream:
resp.body = stream
if ct:
Thanks,
Christophe
Diez B. Roggisch
first of all - I wasn't aware of the cp2-mod. So if there is already
CP2-specific code in the codebase, I'm fine with bringing that up to date.
> Ok, here is bundle that make before_main work the same way it did before.
> However it uses directly get_stream_type_encoding instead of __call__,
> which means the new callback feature will not work.
>
I don't understand this.
> It is still worth applying since it avoid a regression.
Will do so, hopefully tomorrow. Prod me if I didn't do it over the weekend.
> diff -r 4e306e08dcfb -r 5ba455b3eb9a tw/mods/cp2.py
> --- a/tw/mods/cp2.py Fri Sep 25 14:46:32 2009 -0600
> +++ b/tw/mods/cp2.py Fri Oct 23 16:12:51 2009 +0200
> @@ -50,7 +50,12 @@
> if path.startswith(self.prefix):
> reg = resources.registry
> path = path[len(self.prefix)+len(reg.prefix):]
> - stream, ct, enc = reg.get_stream_type_encoding(path)
> + class FakeRequest(object):
> + path_info = path
> + params = req.params
> + environ = {}
> + stream, ct, enc = reg.get_stream_type_encoding(
> + FakeRequest())
> if stream:
> resp.body = stream
> if ct:
Diez
Christophe de VIENNE
Hi,
first of all - I wasn't aware of the cp2-mod. So if there is already
CP2-specific code in the codebase, I'm fine with bringing that up to date.
I don't understand this.
> Ok, here is bundle that make before_main work the same way it did before.
> However it uses directly get_stream_type_encoding instead of __call__,
> which means the new callback feature will not work.
>
The 'registry' (a ResourcesApp instance) is callable, and its __call__ method does everything needed to either call a callback, either serve the adequate resource file.
I could not fake the wsgi behavior enough to be able to use that method of ResourcesApp.
Instead, I just changed a bit the way we call get_stream_type_encoding() to that the resources are correctly served. Since it bypass __call__, the callbacks are not handled.
Will do so, hopefully tomorrow. Prod me if I didn't do it over the weekend.
> It is still worth applying since it avoid a regression.
Thanks !
Christophe
Krishnakant
I have been trying to use tw.Forms with pylons for quite some time and I
am pritty impressed with the library.
I now have a big challenge demanded by an interesting situation.
Firstly let me point out at the outset that I am absolutely new to
tw.Forms and as a beginner, I have a complain that unfortunately we
don't have a really good API reference.
many methods or class properties are marked as "undocumented".
this can prove to be a big setback for many new comers who are not as
determined as I am.
For example the style property is not properly documented.
Secondly I don't really understand whether I should use css to change
the attributes of a given widget and this is where things start to fall
apart for me and hence this email.
I am going to b build a production level application and will make all
the forms with tw.Forms (hopefully).
But our ui designer has given us very good looking designs which I know
can be only implemented using CSS.
Now I want to know how can I set some attributes such as the colour of
the widgit, the texture etc by using a CSS template?
For example suppose I want rounded edges to all buttons, I might have a
css template that contains the code to do this. But my widgets get
generated out of a python control containing the code to build the form.
Now my question is where I connect the CSS file and how the python
generated tw.Form will get the effect from CSS?
This is very interesting for me and I would loave to get this solved.
Happy hacking.
Krishnakant.
Diez B. Roggisch
first: please *don't* reply to other posts when formulating a new
question. Some people (including me) read this ML with threaded mail
readers, and thus your post appears below an ongoing discussion.
Write a *new* mail.
> I have been trying to use tw.Forms with pylons for quite some time and I
> am pritty impressed with the library.
>
> I now have a big challenge demanded by an interesting situation.
> Firstly let me point out at the outset that I am absolutely new to
> tw.Forms and as a beginner, I have a complain that unfortunately we
> don't have a really good API reference.
> many methods or class properties are marked as "undocumented".
> this can prove to be a big setback for many new comers who are not as
> determined as I am.
It sure is. There is an enchanced documentation that might suit your
needs a bit better - it's sphinx-based, and thus does *not* change the
way the API-docs itself are generated. But unfortunately, it hasn't been
put up on the website, so if you want to read it, you need to clone the
HG-repository, and either build the docs, or simply read through them as
text - the file "usage.rst" is the one most helpful I guess.
> For example the style property is not properly documented.
> Secondly I don't really understand whether I should use css to change
> the attributes of a given widget and this is where things start to fall
> apart for me and hence this email.
>
> I am going to b build a production level application and will make all
> the forms with tw.Forms (hopefully).
>
> But our ui designer has given us very good looking designs which I know
> can be only implemented using CSS.
> Now I want to know how can I set some attributes such as the colour of
> the widgit, the texture etc by using a CSS template?
>
> For example suppose I want rounded edges to all buttons, I might have a
> css template that contains the code to do this. But my widgets get
> generated out of a python control containing the code to build the form.
> Now my question is where I connect the CSS file and how the python
> generated tw.Form will get the effect from CSS?
The aforementioned docs mention this. There are several things that make
this easy as cake:
- per form, declare a CSSLink containing your styles as dependency,
like this:
class MyForm(TableForm):
css = [the_styles_css]
...
- the widgets should already have rather good usable CSS-classes, but
if you want more, you can set additional classes per widget. Do so by
setting css_class or css_classes on the form and/or the individual widgets.
- using the attrs-parameter, you can set the attributes of a tag, of
course including the class.
I suggest you do *not* use the style-property, because that makes your
styles rather hard-coded.
HTH,
Diez
Krishnakant
> Hello,
>
> first: please *don't* reply to other posts when formulating a new
> question. Some people (including me) read this ML with threaded mail
> readers, and thus your post appears below an ongoing discussion.
>
> Write a *new* mail.
I will correct it. Thanks for pointing it out.
> > I have been trying to use tw.Forms with pylons for quite some time and I
> > am pritty impressed with the library.
> >
> > I now have a big challenge demanded by an interesting situation.
> > Firstly let me point out at the outset that I am absolutely new to
> > tw.Forms and as a beginner, I have a complain that unfortunately we
> > don't have a really good API reference.
> > many methods or class properties are marked as "undocumented".
> > this can prove to be a big setback for many new comers who are not as
> > determined as I am.
>
> It sure is. There is an enchanced documentation that might suit your
> needs a bit better - it's sphinx-based, and thus does *not* change the
> way the API-docs itself are generated. But unfortunately, it hasn't been
> put up on the website, so if you want to read it, you need to clone the
> HG-repository, and either build the docs, or simply read through them as
> text - the file "usage.rst" is the one most helpful I guess.
It would be a great help.
> > For example the style property is not properly documented.
> > Secondly I don't really understand whether I should use css to change
> > the attributes of a given widget and this is where things start to fall
> > apart for me and hence this email.
> >
> > I am going to b build a production level application and will make all
> > the forms with tw.Forms (hopefully).
> >
> > But our ui designer has given us very good looking designs which I know
> > can be only implemented using CSS.
> > Now I want to know how can I set some attributes such as the colour of
> > the widgit, the texture etc by using a CSS template?
> >
> > For example suppose I want rounded edges to all buttons, I might have a
> > css template that contains the code to do this. But my widgets get
> > generated out of a python control containing the code to build the form.
> > Now my question is where I connect the CSS file and how the python
> > generated tw.Form will get the effect from CSS?
>
> The aforementioned docs mention this. There are several things that make
> this easy as cake:
>
> - per form, declare a CSSLink containing your styles as dependency,
> like this:
>
>
> class MyForm(TableForm):
>
> css = [the_styles_css]
>
Do I just mention the path to my css file here?
In addition do I also need to change any thing in any of the associated
templates provided with toscawidgets which are found in the templates
directory of the package?
I see some <span> tags defined for example in the tableform.html file.
Do I need to make changes to such files as well or is it just an
optional thing?
> ...
>
>
> - the widgets should already have rather good usable CSS-classes, but
> if you want more, you can set additional classes per widget. Do so by
> setting css_class or css_classes on the form and/or the individual widgets.
>
> - using the attrs-parameter, you can set the attributes of a tag, of
> course including the class.
>
Can you provide me a small example please?
It will give me bettre insight into what's actually going on under the
covers.
Happy hacking.
Krishnakant.
Diez B. Roggisch
>> like this:
>>
>>
>> class MyForm(TableForm):
>>
>> css = [the_styles_css]
>>
>
> Do I just mention the path to my css file here?
No, you declare a CSSLink
from tw.api import CSSLink
my_styles_css = CSSLink(modname="myapplication",
filename="path/to/the/resource.css")
> In addition do I also need to change any thing in any of the associated
> templates provided with toscawidgets which are found in the templates
> directory of the package?
Maybe, maybe not, that depends on your design.
> I see some <span> tags defined for example in the tableform.html file.
> Do I need to make changes to such files as well or is it just an
> optional thing?
Not to the files, but you can (and sometimes certainly must) declare a
new template, and change things in there, if pure CSS and e.g. ListForm
aren't sufficient.
>
>> ...
>>
>>
>> - the widgets should already have rather good usable CSS-classes, but
>> if you want more, you can set additional classes per widget. Do so by
>> setting css_class or css_classes on the form and/or the individual widgets.
>>
>> - using the attrs-parameter, you can set the attributes of a tag, of
>> course including the class.
>>
>
> Can you provide me a small example please?
> It will give me bettre insight into what's actually going on under the
> covers.
Please clone the repository & take a look at the docs, there are even
some small examples.
Diez
Krishnakant
> No, you declare a CSSLink
>
> from tw.api import CSSLink
>
> my_styles_css = CSSLink(modname="myapplication",
> filename="path/to/the/resource.css")
>
>
> > In addition do I also need to change any thing in any of the associated
> > templates provided with toscawidgets which are found in the templates
> > directory of the package?
>
> Maybe, maybe not, that depends on your design.
>
> > I see some <span> tags defined for example in the tableform.html file.
> > Do I need to make changes to such files as well or is it just an
> > optional thing?
>
> Not to the files, but you can (and sometimes certainly must) declare a
> new template, and change things in there, if pure CSS and e.g. ListForm
> aren't sufficient.
Actually Some people from the pylons group suggested to me that I have
css files include in the headers of the respective mako templates where
the tw.form gets rendered.
I got the idea that if the class names and the widget types match, then
my problem of applying CSS will be totally solved.
But I am still not sure if that is the right method?
I am confused because the widgets will be rendered to the browser as
html, but they themselves come with some pre-defined css, will that not
clash?
If no then I think I got the solution.
Happy hacking.
Krishnakant.
Diez B. Roggisch
>css files include in the headers of the respective mako templates where
>the tw.form gets rendered.
Then they don't know how TW works. Dependencies of Javascript & CSS are
automatically injected.
>I got the idea that if the class names and the widget types match, then
>my problem of applying CSS will be totally solved.
>But I am still not sure if that is the right method?
That is the way CSS works, you should read up on that.
>I am confused because the widgets will be rendered to the browser as
>html, but they themselves come with some pre-defined css, will that not
>clash?
This is wrong, they don't come with predefined CSS. They come with
predefined *classes* which can be used to style them using CSS.
Diez
Krishnakant
> >Actually Some people from the pylons group suggested to me that I have
> >css files include in the headers of the respective mako templates where
> >the tw.form gets rendered.
>
> Then they don't know how TW works. Dependencies of Javascript & CSS are
> automatically injected.
Let's say that the mako template includes a CSS file which has some
classes for buttons and input types like text box.
Now if this same mako template has a form which was actually rendered
through tw.Forms, will the widgets get the css effects if they contain
input text boxes?
My analogy was that since all that browser gets is html, the CSS should
apply.
>
> >I got the idea that if the class names and the widget types match, then
> >my problem of applying CSS will be totally solved.
> >But I am still not sure if that is the right method?
>
> That is the way CSS works, you should read up on that.
> So what will exactly happen if I decide to apply CSS to the forms from the mako template which renders the form?
I am still not clear.
happy hacking.
Krishnakant.
Graham Higgins
Hash: SHA1
On 26 Oct 2009, at 06:30, Krishnakant wrote:
> Let's say that the mako template includes a CSS file which has some
> classes for buttons and input types like text box.
> Now if this same mako template has a form which was actually rendered
> through tw.Forms, will the widgets get the css effects if they contain
> input text boxes?
Yes.
If you use the existing tw.forms widgets, they are rendered into HTML
with appropriate ids and classes, e.g. for an instance of a defined
form class NewRegistrationForm:
class NewRegistrationForm(ListForm, SecureFormMixin):
class fields(WidgetsList):
rest_method = HiddenField(
default = "PUT",
name = "_method")
[ ... ]
company = TextField(
validator = All(
NotDefault(default = "Company or organisation"),
UnicodeString(not_empty=True,
default = "Company")),
help_text = "Enter your company's name",
label_text = "Company Name:",
maxlength = 255,
size = 50,
default = "Company or organisation"
)
the form's rubric and the "company" textfield is rendered broadly thus:
<form id="new_registration_form"
action="/bookings/registration"
method="post"
class="cmxform newregistrationform">
<div>
<ul class="field_list" >
<li class="even"
id="new_registration_form_company_container"
title="Enter your company's name">
<label id="new_registration_form_company_label"
for="new_registration_form_company"
class="fieldlabel required"
>Company Name:</label>
<input type="text"
id="new_registration_form_company"
class="textfield required"
name="company"
value="Company or organisation"
maxlength="255"
size="50" />
</li>
[ ... ]
and the CSS runs along the lines of:
form.cmxform input[type="text"] {color: #aaa;}
label.required { font-weight: bold; }
i.e. you use the the tw.forms-provided id and class selectors to drive
the CSS styling.
Cheers,
Graham
http://www.linkedin.com/in/ghiggins
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkrlTncACgkQOsmLt1Nhivz8kACgk1uWk2rO/xuwUC3jfAAWBIGk
8qAAoKuNP+lCpjP9eVI15Nxzr07WiSVYiQCVAgUBSuVOd1nrWVZ7aXD1AQInBgP8
Dvfj9AuiHUlaxTHCONc7JjeutQLIS1/0wuisTBhzYnFAcj4aYICOowJah5fxHzYy
qbrKjv7eAqP7H5Nctog0JRC1j3KFYkQ44wZjLQHgsWFi2k9+R7aVwP01CvtsJbdm
Msh5IDFVklIgkIwrU6G3OSLICFeOhRTBn4FzvDgBZGo=
=/lbZ
-----END PGP SIGNATURE-----
Diez B. Roggisch
> On Sun, 2009-10-25 at 23:20 +0100, Diez B. Roggisch wrote:
> > >Actually Some people from the pylons group suggested to me that I have
> > >
> > >css files include in the headers of the respective mako templates where
> > >the tw.form gets rendered.
> >
> > Then they don't know how TW works. Dependencies of Javascript & CSS are
> > automatically injected.
> > OK, so including the css files in the headers won't have any impact on
> > the forms in the same page is it?
>
> Let's say that the mako template includes a CSS file which has some
> classes for buttons and input types like text box.
> Now if this same mako template has a form which was actually rendered
> through tw.Forms, will the widgets get the css effects if they contain
> input text boxes?
> My analogy was that since all that browser gets is html, the CSS should
> apply.
This is not true, the browser gets HTML & CSS. They depend on each other, and
when developing you must adapt one to work with the other - and vice versa.
This is CSS 101, so again I suggest you try & educate yourself on what it is
and how it works.
In the actual context, I suggest you adapt the CSS to have classnames that
match the ones TW, because then you will have less hassle developing.
Diez
Krishnakant
Thanks a lot graham.
That solves my confusion.
I am seeing your message after a long time.
so I am pritty happy to hear you again.
I think I will mail you off the list for some accessibility related
discussion which we have left incomplete.
Happy hacking.
Krishnakant.