This is my first time using Catalyst and I'm hitting a problem that
I've been trying to debug for a shamefully long time now with no
success.
I started by going step-by-step through Jon Rockway's tutorial on
CPAN
Thanks to all of you for Your postings. I have continued to investigate.
I found, that TT is not the reason. I can reproduce the problem in 4
simple steps just by using Catalyst.
1. Create a Catalyst application
catalyst.pl CatSimple
2. cd CatSimple
3. Create a Controller
what does the browser tell you is the encoding of the page it is getting?
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev
Josef Chladek wrote:
hi list,
I have a strange problem, that occurs for some clients, for most not: we
have a form, that is setup by javascript dynamically (form consits of
one input field, one textarea and 2 hidden fields)
...
form.setAttribute('action','/cat/postings/post_comment');
Am 07.09.2007 um 16:44 schrieb Christopher H. Laco:
Josef Chladek wrote:
hi list,
I have a strange problem, that occurs for some clients, for most
not: we
have a form, that is setup by javascript dynamically (form
consits of
one input field, one textarea and 2 hidden fields)
...
Stefan Kühn wrote:
GERMAN UMLAUT HERE: ___\xFC\xFC\xFC___
AFAIK, single-byte-width \xxx escapes are always treated as bytes, not
as characters. Even if they are outside the 7-bit range, and even in the
presence of the utf8 pragma.
Try inserting real Unicode characters into the string,
hi list,
I have a strange problem, that occurs for some clients, for most not:
we have a form, that is setup by javascript dynamically (form
consits of one input field, one textarea and 2 hidden fields)
...
form.setAttribute('action','/cat/postings/post_comment');
Hi Emanuele
thanks for the response. I took a look with the debugger this morning
but didn't have too much time ... you are obviously much further with
this than me.
whatever happens, the code should at least be fixed enough to give
some sensible default behaviour, along with a docs patch, and
On 9/7/07, Matt Lawrence [EMAIL PROTECTED] wrote:
AFAIK, single-byte-width \xxx escapes are always treated as bytes, not
as characters. Even if they are outside the 7-bit range, and even in the
presence of the utf8 pragma.
Try inserting real Unicode characters into the string, explicitly
Matt Lawrence wrote:
Stefan Kühn wrote:
GERMAN UMLAUT HERE: ___\xFC\xFC\xFC___
AFAIK, single-byte-width \xxx escapes are always treated as bytes, not
as characters. Even if they are outside the 7-bit range, and even in the
presence of the utf8 pragma.
Try inserting real
Daniel McBrearty wrote:
ok, i searched the list but stupidly didn't look at cpan bugtracker
... it is a reported bug. in fact there seem to be several issues with
the live_app.t in 0.07
what's the implication? sessions will time out even if though the user
has revisited?
Exactly (because the
Good evening,
On 6/9/07 at 11:15 PM -0700, Dustin Suchter [EMAIL PROTECTED] wrote:
The overall question is, what the heck is going on?!?
What does your conf file look like (probably yaml file)? I'm
guessing the user/roles setup doesn't match the database schema.
Thanks to anyone who even
On Fri, Sep 07, 2007 at 04:26:56PM +0200, Josef Chladek wrote:
from debugging I found out, that $remaining in fact is $length, so it
seems, that nothing was read from the post body
Are you using SSL? This is way old and doesn't seem to fit your case,
but some old versions of IE post with zero
Unfortunately I thought of that one already, and the two do match.
Here's the useful YAML and below is the useful SQL just to double
check. I believe the underlying MySQL engine is 4.1.
# cat adblue.yml | grep -v \s*#
---
name: AdBlue
authentication:
dbic:
user_class: AdBlueDB::User
Am 07.09.2007 um 21:24 schrieb Bill Moseley:
On Fri, Sep 07, 2007 at 04:26:56PM +0200, Josef Chladek wrote:
from debugging I found out, that $remaining in fact is $length, so it
seems, that nothing was read from the post body
Are you using SSL? This is way old and doesn't seem to fit your
Good morning,
On 7/9/07 at 12:22 PM -0700, Dustin Suchter [EMAIL PROTECTED] wrote:
authorization:
dbic:
role_class: AdBlueDB::User
role_field: role
role_rel: map_user_role
user_role_user_field: user_id
Shouldn't that be:
authorization:
dbic:
On Sep 7, 2007, at 3:22 PM, Dustin Suchter wrote:
Unfortunately I thought of that one already, and the two do match.
Here's the useful YAML and below is the useful SQL just to double
check. I believe the underlying MySQL engine is 4.1.
# cat adblue.yml | grep -v \s*#
---
name: AdBlue
Yup - that was it!! I have no idea when I introduced that error in
my code, but it is fixed and working now. I also think I get why the
SQL was selecting me.role - because I had the User class in place
of the role class. I does map_user_role.role in the correct case.
Thanks Charlie and Jason.
18 matches
Mail list logo
