The new template system supports custom lexers, if web2py would expose
the correct interface, it would allow you to define something like
{{:PT}}
Which would translate to
response.write(XML(simplejson.dumps(PT), escape=False)
We can add as many of these custom named commands as we would like...
I agree that it should be available in either context, which means
including the helper. If folks wish to implement it in the view, they
could continue to do so...
On Jul 24, 10:40 pm, Michael Ellis wrote:
> I'm of two minds on this. It's a one-liner to implement as I've done it,
> but my imple
This is a good argument to not include it.
On Jul 24, 9:40 pm, Michael Ellis wrote:
> I'm of two minds on this. It's a one-liner to implement as I've done it,
> but my implementation hides the rich argument set available in
> simplejson.dumps():
>
> dumps(obj, skipkeys=False, ensure_ascii=True,
I'm of two minds on this. It's a one-liner to implement as I've done it,
but my implementation hides the rich argument set available in
simplejson.dumps():
dumps(obj, skipkeys=False, ensure_ascii=True, check_circular=True,
allow_nan=True, cls=None, indent=None, separators=None, encoding='utf-8',
I think the JSON helper function should be implemented. This logic
should be contained within the controller and not within the view as I
would deem it business logic and not rendering logic.
On Jul 24, 7:52 pm, mdipierro wrote:
> Should we have a JSON helper (same as you JD)?
>
> On Jul 24, 1:1
I don't know enough about the problem to say if I would support or
oppose this change.
I also agree that a template symbol is easier than having to wrap the
entirety around a function.
--
Thadeus
On Sat, Jul 24, 2010 at 3:02 AM, mdipierro wrote:
> ad a review board, would you have opp
Should we have a JSON helper (same as you JD)?
On Jul 24, 1:15 pm, Michael Ellis wrote:
> Something good has come out of this: while looking for a workaround I
> learned about simplejson.dumps(). So now I've defined my own little helper
> JD()
>
> import simplejson
> def JD(obj):
> return XM
Something good has come out of this: while looking for a workaround I
learned about simplejson.dumps(). So now I've defined my own little helper
JD()
import simplejson
def JD(obj):
return XML(simplejson.dumps(obj,indent=4))
In my view (or controller) I can lump into one variable everything I
I am also doing more and more in JS for views. Even search engine for
tables, i am using JQGrid's local search (at latest version if JQGrid).It
dont need server side at all for search to work, which make it a lot faster
+ lesser hit on server performance.
On Sat, Jul 24, 2010 at 7:53 PM, Michael E
My bad. It does work. In my earlier attempt to use it I forgot that a for
loop variable isn't an object reference when looping over a list of strings.
So the value of schartoptions wasn't being altered at all, just the loop
variable.
I'm still in favor of an alternate operator, though. As it i
I am confused:
Does this now work?
{{
schartoptions = """{
type: 'bar',
barColor: 'green',
chartRangeMin: '%d',
chartRangeMax: '%d'
}
"""%(chartmin,chartmax)
}}
and later on I use the variables within a script tag, e.g.
/*
Massimo, I'm not following you. I tried using XML (see earlier post) and it
had no effect. Does it only work if applied immediately before the =
operator?
Also, I think ":=" or something similar is much cleaner than wrapping
everything in a function call.
Cheers,
Mike
On Sat, Jul 24, 2010 at
This
{{:=never_escaped}}
would be the same as
{{=XML(ever_escaped)}}
so why introduce new syntax?
On Jul 24, 7:14 am, Michael Ellis wrote:
> I could happily live with a solution that adds a 'no escape' operator to the
> template language, e.g.
>
> {{:=never_escaped}}
>
> vs
>
> {{=always_esca
I could happily live with a solution that adds a 'no escape' operator to the
template language, e.g.
{{:=never_escaped}}
vs
{{=always_escaped}}
1. Backward compatible,
2. Safe by default,
3. Allows designer to decide what's safe and what isn't,
4. Seems like an easier fix than trying to ma
Thadeus,
This was a security fix. We had a a security review and this was
determined to be a weakness. The code by Mike Ellis broke not because
of the fix but because it incorrectly implicitly assumed that the
strings were HTML/XML and therefore needed escaping when, in reality,
they were JS stri
Also, I don't have time to read every google group posting anymore. This may
have been suggested in a thread that was buried from those who just scan the
post titles.
Changes like this need to be called out, we need some way of being able to
review and vote for certain changes something like u
There was talk of a week long RC period for all releases unless there
was an important bug fix but we seem to have reverted to old habits.
On Jul 23, 5:28 pm, Thadeus Burgess wrote:
> I also agree that this is a break in backwards compatibility. It is also a
> change that was never considered for
I also agree that this is a break in backwards compatibility. It is also a
change that was never considered for longer than 15 minutes before the
decision to make the change was implemented.
I really wish we would put certain things such as this under a review board
so they don't get into web2py a
Typo: 2 sentence in prior message should read
" ... after XML() supplies the unescaped string."
On Jul 23, 3:28 pm, Michael Ellis wrote:
> Urgh! FWIW, putting XML() around the strings doesn't seem to work. Looks
> like the escaping is applied after XML() supplies the unquoted string.
>
> I tr
Urgh! FWIW, putting XML() around the strings doesn't seem to work. Looks
like the escaping is applied after XML() supplies the unquoted string.
I tried
{{
for optstring in (schartoptions, countpieoptions, cchartoptions):
optstring = XML(optstring)
debug("opstring=%s"%optstring)
pass
Thanks, Nathan. That's certainly a possibility. It's just that I'm not sure
what security issue this change actually fixes. There are no user-supplied
strings in what I'm using to generate the jQuery calls. If that were the
case, then yes it would definitely be my responsibility to properly sani
It was probably introduced as a security fix. You can do:
{{
schartoptions = XML("""{
type: 'bar',
barColor: 'green',
chartRangeMin: '%d',
chartRangeMax: '%d'
}
"""%(chartmin,chartmax))
}}
and it won't be escaped.
On Jul 23, 12:39 pm, Michael Ellis wrote:
> I've got an a
22 matches
Mail list logo
