[web2py] Re: Is it possible to define how a field is rendered in the DB model?
it's completely up to you. Try to do some tests though. Unless you're
storing millions of markmin fragments, having a row holding 0,2 KB of
markmin source or 0,2+0,4 of markmin source + html at the end of the day
means adding few megs up.
On the other end, a reddited blog post having to render the markmin to 1M
users may speed down your app a bit.
On the far end, caching the html of the page in ram or in memcache or in
redis in the controller will be the best possible solution but again,
it depends on the app.
On Monday, January 7, 2013 9:51:36 PM UTC+1, HittingSmoke wrote:
>
> Thanks. Concerning saving the computed result, would that be another field
> which saves the post in HTML and using that field when rendering pages? I
> wouldn't think rendering markmin to HTML would be of an consequence on CPU
> load. I think the complication involved in storing the same data in two
> formats in the database as well as the database size would be something I'd
> want to avoid.
>
> On Monday, January 7, 2013 12:28:55 PM UTC-8, Niphlod wrote:
>>
>> using field.represent or the new filter_out parameter ... docs aren't
>> there but it's pretty simple.
>>
>> db.define_table('test3',
>> Field('testfield', filter_out=lambda value : value.upper)
>> )
>>
>> However, for "computations" like MARKMIN, the better choice is to store
>> in another computed field the result, so you don't "spend" cpu cycles on
>> rendering over and over the same thing every time.
>>
>> On Monday, January 7, 2013 8:53:43 PM UTC+1, HittingSmoke wrote:
>>>
>>> For instance, could I set a field in the database to be always rendered
>>> in Markmin or sanitized HTML instead of in the view every time it's queried?
>>
>>
--
[web2py] Re: Is it possible to define how a field is rendered in the DB model?
"represent" only affects how the value is displayed in forms (including
read-only forms) and the grid, whereas "filter_out" is applied when the
database result is parsed into the Rows object, so it affects everywhere
the value might be used or displayed. "represent" is often used with
reference fields, which typically makes more sense than using "filter_out"
because although you may want to display the reference field differently,
you probably still want to retain the original id value as well
("filter_out" replaces the original value with the transformed value).
Anthony
On Monday, January 7, 2013 3:35:09 PM UTC-5, szimszon wrote:
>
> Hi!
>
> What is a difference between represent and filter_out? Tnx.
>
--
[web2py] Re: Is it possible to define how a field is rendered in the DB model?
Thanks. Concerning saving the computed result, would that be another field
which saves the post in HTML and using that field when rendering pages? I
wouldn't think rendering markmin to HTML would be of an consequence on CPU
load. I think the complication involved in storing the same data in two
formats in the database as well as the database size would be something I'd
want to avoid.
On Monday, January 7, 2013 12:28:55 PM UTC-8, Niphlod wrote:
>
> using field.represent or the new filter_out parameter ... docs aren't
> there but it's pretty simple.
>
> db.define_table('test3',
> Field('testfield', filter_out=lambda value : value.upper)
> )
>
> However, for "computations" like MARKMIN, the better choice is to store in
> another computed field the result, so you don't "spend" cpu cycles on
> rendering over and over the same thing every time.
>
> On Monday, January 7, 2013 8:53:43 PM UTC+1, HittingSmoke wrote:
>>
>> For instance, could I set a field in the database to be always rendered
>> in Markmin or sanitized HTML instead of in the view every time it's queried?
>
>
--
[web2py] Re: Is it possible to define how a field is rendered in the DB model?
Hi! What is a difference between represent and filter_out? Tnx. --
[web2py] Re: Is it possible to define how a field is rendered in the DB model?
using field.represent or the new filter_out parameter ... docs aren't there
but it's pretty simple.
db.define_table('test3',
Field('testfield', filter_out=lambda value : value.upper)
)
However, for "computations" like MARKMIN, the better choice is to store in
another computed field the result, so you don't "spend" cpu cycles on
rendering over and over the same thing every time.
On Monday, January 7, 2013 8:53:43 PM UTC+1, HittingSmoke wrote:
>
> For instance, could I set a field in the database to be always rendered in
> Markmin or sanitized HTML instead of in the view every time it's queried?
--
