Re: [web2py] Re: Functions in Views

I goofed, A big apology to Anthony and Max. It works now, I actually didnt define a FIELDTYPE in my db definition so I guess it just defaulted to storing the field values as a string. On Thursday, August 16, 2012 8:37:56 PM UTC+1, Anthony wrote: > > Can we see your model? Are you sure the "times

Re: [web2py] Re: Functions in Views

Can we see your model? Are you sure the "timestamp" field is a datetime field and not a string field? When I try prettydate with a datetime field, it works fine? Anthony On Thursday, August 16, 2012 3:26:24 PM UTC-4, Pystar wrote: > > To Max, > Like Anthony said, why is a datetime object I retr

Re: [web2py] Re: Functions in Views

I would also like to know the format that the request.now value which is equivalent to datetime.datetime.now() follow? i,e, If I was to convert a string to a datetime object using the datetime.datetime.strptime("datetimestring", [format]), I tried passing %Y-%m-%d %h:%m:%f but I got a traceback

Re: [web2py] Re: Functions in Views

To Max, Like Anthony said, why is a datetime object I retrieved from my database in a controller automatically converted to a string object? and how come prettydate() cant convert datetime objects that are strings too? Is this a feature of a bug? I also discovered that if i do this in my view

Re: [web2py] Re: Functions in Views

Does this break backward compatibility, or do you consider this a bug? Note, Pystar's problem is not that the function was failing silently, but that his item.now value was a string when he expected it to be a datetime object (i.e., now it will still fail, but not silently). Anthony On Thursda

Re: [web2py] Re: Functions in Views

you are right. I think this is now fixed on google code (not on github because I am behind a firewall and cannot push to github right now). Massimo On Thursday, 16 August 2012 00:42:34 UTC-5, Anthony wrote: > > Massimo, note that prettydate() does fail silently due to a try/except > (the except

Re: [web2py] Re: Functions in Views

Massimo, note that prettydate() does fail silently due to a try/except (the except returns '') -- see https://groups.google.com/forum/#!msg/web2py/Rguuny9E3X8/-a976Tjx4EIJ%5B1-25%5D . Anthony On Thursday, August 16, 2012 1:14:47 AM UTC-4, Massimo Di Pierro wrote: > > Try: > > {{=prettydate(item

Re: [web2py] Re: Functions in Views

Try: {{=prettydate(item.timestamp)}} {{=item.timestamp}} to check there is actually something to display. functions cannot fail silently in view. If they are executed and fail, they raise an exception. On Wednesday, 15 August 2012 22:24:08 UTC-5, Pystar wrote: > > still doesnt work > > On Wedn

Re: [web2py] Re: Functions in Views

still doesnt work On Wednesday, August 15, 2012 1:45:47 AM UTC+1, Pystar wrote: > > OK, After doing type(item.now). I discovered that web2py is escaping my > retrieved data from the database and converting everything into strings. > And since prettydate() doesnt work on strings but datetime obje

Re: [web2py] Re: Functions in Views

OK, After doing type(item.now). I discovered that web2py is escaping my retrieved data from the database and converting everything into strings. And since prettydate() doesnt work on strings but datetime objects, it fails. For this prettydate to work in the views, I would have to import datetim

Re: [web2py] Re: Functions in Views

It fails silently, it outputs nothing. On Tuesday, August 14, 2012 11:34:54 PM UTC+1, Anthony wrote: > > item.now is a field in my database whose default value is request.now. > > > Yes, I understand, but can you report the error raised as well as checking > the type of item.now? > > Anthony >

Re: [web2py] Re: Functions in Views

> > item.now is a field in my database whose default value is request.now. Yes, I understand, but can you report the error raised as well as checking the type of item.now? Anthony --

Re: [web2py] Re: Functions in Views

item.now is a field in my database whose default value is request.now. So I am confused why {{=prettydate(request.now, T)}} works and {{=prettydate(item.now, T)}} doesnt? Although I am looping through all the returned values from a db select and applying the prettydate function On Tuesday, Augu

Re: [web2py] Re: Functions in Views

What error is being raised? What is the type of item.now? On Tuesday, August 14, 2012 6:00:31 PM UTC-4, Pystar wrote: > > I just noticed that doing {{=prettydate(request.now, T)}} in my views > works, but doing {{=prettydate(item.now, T)}} doesnt work in my views, even > when my default value in

Re: [web2py] Re: Functions in Views

I just noticed that doing {{=prettydate(request.now, T)}} in my views works, but doing {{=prettydate(item.now, T)}} doesnt work in my views, even when my default value in the database definition is request.now for the timestamp. What exactly am I doing wrong? On Tuesday, August 14, 2012 8:32:18

Re: [web2py] Re: Functions in Views

tried prettydate(item.timestamp, T) still didnt work On Tuesday, August 14, 2012 8:16:39 PM UTC+1, rochacbruno wrote: > > maybe > > {{=prettydate(item.timestamp, *T*)}} > --

[web2py] Re: Functions in Views

I don't know, but see suggestion hereto help diagnose. I don't think it's related to being in the view (as opposed to in the controller). Anthony On Tuesday, August 14, 2012 3:15:19 PM UTC-4, Pystar wrote: > > In my controller, I

Re: [web2py] Re: Functions in Views

maybe {{=prettydate(item.timestamp, *T*)}} --

[web2py] Re: Functions in Views

In my controller, I do this: def index(): rows = db().select(db.post.ALL, orderby=~db.post.timestamp) return locals() In my view I do this: for item in rows: {{=prettydate(item.timestamp)}} it fails quie

[web2py] Re: Functions in Views

it works in the controller and shell but if I try calling it in the view, it fails silently. On Tuesday, August 14, 2012 7:47:09 PM UTC+1, Anthony wrote: > > I am having issues calling the prettydate function in my views as its not >> working, I pull the datetime variable stored in my database a

[web2py] Re: Functions in Views

> > I am having issues calling the prettydate function in my views as its not > working, I pull the datetime variable stored in my database and when I call > the prettydate function, it fails quietly without throwing any errors. Are you saying it only fails in the view? I know it worked in the

[web2py] Re: Functions in Views

I am having issues calling the prettydate function in my views as its not working, I pull the datetime variable stored in my database and when I call the prettydate function, it fails quietly without throwing any errors. On Tuesday, August 14, 2012 1:50:52 AM UTC+1, Anthony wrote: > > The view d

[web2py] Re: Functions in Views

The view does not see objects created in the controller unless they are returned in the dict from the controller function that was called. So, you can do: def view_func(arg1, arg2): [do something] return something def index(): return dict(message='Hello World', func=view_func) And

Re: [web2py] Re: functions

ok, i'll follow your adviced to put it on models, it's clear for me as a newbie in python and web2py. pardon me, to asked many times about this matter. thanks and best regards, steve van christie

Re: [web2py] Re: functions

The advice reamins the same: put them in models. Please, please, please disregard the section on scalability for now. You will know when you need to read it and it is not now.

Re: [web2py] Re: functions

I think this is probably fine in a model file. You've got references to a number of web2py globals in those functions, so if you move them to a module, you've got some extra hassle importing framework classes and passing globals as parameters. If at some point you've got *a lot* of long function

Re: [web2py] Re: functions

hi antony, thank you so much for your adviced, in my case (please see attached file), would you prefer to put it on models or modules? right now i put it on models, please give an advice or suggestion? thank you very much in advance. steve van christie On Thu, Apr 14, 2011 at 7:17 AM, Anthony

[web2py] Re: functions

If it's just a few (small) functions, go ahead and put them in model files, as reading a few extra function definitions will probably have a negligible impact on performance. In particular, if the functions are used in many/most requests, you would save little by moving them to modules because y