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?
>>
>>
--
