Is this a good idea?

[Massimo Di Pierro]

already in trunk, experimentally.

1) create a file web2py/applications/myapp/app.conf
2) and in the file put something like:

dict(
name = 'myapp',
version = 1,
built_date = datetime.date(2012,4,8),
comments = '',
)

3( than make a controller:

def edit():
import os
filename = os.path.join(request.folder,'app.conf')
form = SQLFORM.smartdictform(session,'config',filename)
return dict(form=form)

the controller will create a form to edit the file, will guess the types of vars from current values, will cache the dict in session. The idea is that it could be used to configure apps. If a filename is not specified, it will only change the vars in the session['config'] dictionary.

what do you think?

Massimo

[Jonathan Lundell]

Interesting. I'm imagining the same thing stored as a field in auth_user.

[Anthony]

Can you explain more how this is intended to be used for app configuration? Because the dict goes in each user's session, it looks like it would be for user-specific configurations, but there is only one "app.conf" file -- how does that work?

Anthony

[Massimo Di Pierro]

There are different applications.

One case could be when you install a new app. The administrator could use this function to edit the configuration file (if any, via admin or via appadmin). How the application uses the file is not discussed in the example.

Another case is when an app need a edit interface for a dict. The dict can be stored on file but does not have to. It can be stored in a session variable but does not have to.

Massimo

--
mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/

[Anthony]

One case could be when you install a new app. The administrator could use this function to edit the configuration file (if any, via admin or via appadmin). How the application uses the file is not discussed in the example.

But how would the app then use the configuration file? I assume we wouldn't want to read it on every request. Do you read it once and cache in ram? Is that better than just using a module file? Would it be better to include more complete app configuration functionality?

 

Another case is when an app need a edit interface for a dict. The dict can be stored on file but does not have to. It can be stored in a session variable but does not have to.

What are some use cases for this?

Anthony

[Massimo Di Pierro]

On Apr 7, 2012, at 10:25 PM, Anthony wrote:

One case could be when you install a new app. The administrator could use this function to edit the configuration file (if any, via admin or via appadmin). How the application uses the file is not discussed in the example.

But how would the app then use the configuration file? I assume we wouldn't want to read it on every request. Do you read it once and cache in ram? Is that better than just using a module file? Would it be better to include more complete app configuration functionality?

yes. This is just a piece that could be useful.

 

Another case is when an app need a edit interface for a dict. The dict can be stored on file but does not have to. It can be stored in a session variable but does not have to.

What are some use cases for this?

I was thinking of improving the wizard with a visualbasic style designer. This could be useful to edit the properties of the objects. 

Anthony

[guruyaya]

Love it. The only problem I have, is I don't understand how I access
the config data. But when I would, I won't stop using it.


On Apr 8, 6:33 am, Massimo Di Pierro <massimo.dipie...@gmail.com>
wrote:

[Massimo Di Pierro]

if not session.config: session.config=eval(open('app.conf').read()) # assume the data is stored as a dict.

[Stefaan Himpe]

> the controller will create a form to edit the file, will guess the types of vars from current values, will cache the dict in session. The idea is that it could be used to configure apps. If a filename is not specified, it will only change the vars in the session['config'] dictionary.

Looks like a good idea.
For a small pet project of mine I could use something as follows:
-> generate form + set default values from an existing .ini file
-> save the modified form under a unique name, which then is associated
to the currently logged in user

* Will the smartdictform modify the file on the server?
Or just cache the resuting dict ?
* Could smartdictform be used with a dict not coming from a file?

Best regards,
Stefaan.

[Anthony]

if not session.config: session.config=eval(open('app.conf').read()) # assume the data is stored as a dict.

For app configuration, is there an advantage to opening and eval'ing a file vs. importing a module? 

[guruyaya]

Ah, thanks

On 8 אפריל, 19:26, Massimo Di Pierro <massimo.dipie...@gmail.com>

[Michael Toomim]

I like:

 • Having a built-in / sanctioned method of specifying app settings

 • Storing them in web2py/applications/myapp/app.conf instead of models/0_settings.py

 • Having a web form to edit settings vs. editing a file (much better experience for a new dev installing my code)

I need:

 • Settings to be loaded and available for all model files, for any user, with any session

 • Default settings to be stored somewhere in my git repository...

   ...but changes saved in a new file NOT in git, so that edits don't get committed

[Jonathan Lundell]

On Apr 7, 2012, at 4:49 PM, Massimo Di Pierro wrote:
>

An implementation suggestion: pass db as an argument. (Also, kwargs isn't used.)

[Massimo DiPierro]

Can you show me an example? I do not understand your suggestion

[Jonathan Lundell]

On May 21, 2012, at 7:38 AM, Massimo DiPierro wrote:
>
> Can you show me an example? I do not understand your suggestion

In the trunk, SQLFORM.smartdictform accesses db with the apparent assumption that it's in globals. That doesn't seem ideal.

Alternatively, you could pass db(query).

@staticmethod
def smartdictform(session,name,filename=None,query=None,**kwargs):
import os
if query:
session[name] = db(query).select().first().as_dict()
elif os.path.exists(filename):
env = {'datetime':datetime}
session[name] = eval(open(filename).read(),{},env)
form = SQLFORM.dictform(session[name])
if form.process().accepted:
session[name].update(form.vars)
if query:
db(query).update(**form.vars)
else:
open(filename,'w').write(repr(session[name]))
return form

[Massimo DiPierro]

That's a bug. fixed. Thanks Jonathan