Multi-line string value

[Google Code Exporter]

I would like to be able to have multi-line string values (for example, to 
edit email message templates). Alas, I couldn't achieve that with the 
current API, so I had to patch dbsettings/forms.py

Perhaps we need some refactoring to make it easier (I don't like much my 
approach...)?

class MultilineStringValue(dbsettings.Value):
    field = forms.CharField
    field_kwargs = {'widget':forms.Textarea}

Index: forms.py
===================================================================
--- forms.py    (revision 63)
+++ forms.py    (working copy)
@@ -66,6 +66,8 @@
                 # Provide current setting values for initializing the 
form
                 'initial': setting.to_editor(storage.value),
             }
+           if 'field_kwargs' in setting.__class__.__dict__:
+               kwargs.update(setting.__class__.field_kwargs)
             if setting.choices:
                 field = forms.ChoiceField(choices=setting.choices, 
**kwargs)
             else:

Original issue reported on code.google.com by [e-mail] on 31 Aug 2007 at 12:17

[Google Code Exporter]

I specifically avoided adding in a TextField (which is what you're really 
asking for)
for two reasons. First, allowing longer input would likely run into problems 
with the
storage mechanism, since it uses 255-character CharField to store the values. In
addition (and more importanly), I don't want this to become a replacement for
standard templates. Django already has a great template loading system, and I 
don't
see any reason for you to not use that.

You can still modify templates without restarting the server, so the only 
potential
benefit to having it here is to be able to do so in a browser. If that's really 
what
you're after, I would recommend you create a custom view to load up the 
template into
a newforms TextField and have the form save it back to the file after editing.

I'm marking this as WontFix unless you can provide some reason you want this, 
other
than just for editing templates in a browser.

Original comment by [e-mail] on 31 Aug 2007 at 12:39

• Changed state: WontFix

[Google Code Exporter]

> I specifically avoided adding in a TextField (which is what you're really 
asking 
for)

What's a TextField? There's no django.newforms.TextField, it's CharField with 
Textarea widget. And in dbsettings architecture, there's no Fields at all, 
there 
are Values, correct?

> I'm marking this as WontFix unless you can provide some reason you want this, 
other than just for editing templates in a browser.

I believe the whole idea of dbsettings project is to allow non-qualified 
personnel 
to manage the website settings which affect its functionality. For example, 
change 
the number of news blocks on the index page, or allow/disallow posting comments 
in 
realtime.

In my particular case, I need to allow the webmaster to edit notification email 
frequency, subject and body. With the current dbsettings implementation, I can 
allow to edit frequency (a number), subject (a string), but can't allow to edit 
the 
message body (a multi-line string). Such limitation doesn't seem logical for me 
neither from user point of view, neither from programmer's point of view.

> I would recommend you create a custom view to load up the template into
a newforms TextField and have the form save it back to the file after editing.

Suggesting to edit templates directly is like suggesting to use edit 
settings.py 
directly instead of using dbsettings. That definitely would work, but that is 
far 
from optimal.

For example, since templates are under source control, editing them directly 
would 
lead to more chaos with the project. Thinking more, I actually would like to 
have 
two types of templates - hardcoded by programmer (as files under source 
control) 
and editable by webmasters (kept in the database). I do understand however that 
is 
beyound the scope of your project.

Thanks anyway.

Original comment by [e-mail] on 3 Sep 2007 at 11:30

[Google Code Exporter]

I admit I misspoke when I said TextField, I did indeed mean TextValue.

Editing templates directly is a very different case from editing settings.py 
directly. The main reason I started this project is to avoid having to restart 
the 
server after each edit, which is what would be required if editing settings.py. 
Editing templates directly doesn't have that problem, so I see no reason for 
this 
project to cover that option.

And yes, much of the point of this project is to allow "non-qualified 
personnel" to 
manage the settings of a site. However, the real point here is that this 
project 
intends to allow non-programmers access to settings which would have otherwise 
required a programmer. Editing templates doesn't require programmers, as they 
can be 
stored in a completely separate area of your filesystem, which can be opened to 
up 
to designers without exposing the rest of your source. In fact, for your 
particular 
need, you could open up just the location of this one template, so your users 
could 
use the filesystem directly, perhaps FTP or SSH, or whatever method you prefer. 
And 
since editing templates takes effect immediately without the need for any 
additional 
intervening software (like dbsettings), I see little value in including them 
here.

Essentially, the only functional difference between standard filesystem 
templates 
and dbsettings templates is where they're stored. All other abilities, 
capabilities 
and features remain the same. So it really comes down to whether or not I want 
to 
encourage people to use this for templates, and I don't.

For your last comment regarding to types of templates, one for programmers, one 
for 
webmasters, I suggest you split your templates into two filesystem locations, 
and 
simply add them both to your settings. Then you can open each set to the proper 
group however you like.

Original comment by [e-mail] on 3 Sep 2007 at 3:24

[Google Code Exporter]

Okay, I agree with your point. Perhaps I need to come up with "dbtemplates" 
project
 :-)

Original comment by [e-mail] on 3 Sep 2007 at 3:51