Ubiquo_config proposal
David Lozano
Hi,
I would like to ask feedback about the possibility to add a new plugin
to the family. We would love to have any information/suggestion/need/
requirement you can provide.
Thanks,
David Lozano
ubiquo_config
=========================
Date: 2010/03/02
Table of Contents
=================
1. Introduction
2. Needs
3. Implementation
4. Things to do
1. Introduction
~~~~~~~~~~~~~~
The plugin could be used for two types of settings:
Plugin Settings: Right now they are specified and initialized in each
plugin Init.rb, and overridden per application in ubiquo_config.rb.
They are hard-coded and not easily and/or safely changeable on
runtime.
There are two kinds of settings depending if they can be changed
freely or have some relation with the system or database design:
Static: i.e. the connector used. If we use i18n version of
ubiquo_categories we cannot change it without other serious
implications
Dynamic:
asset_type_icons or mime_types of ubiquo_media
Number of elements in lists (elements_per_page in ubiquo_core)
Default metatags for ubiquo_design
Which ones can be dynamic must be discussed, we can maintain how we
handle now 'static' settings.
Application settings: There are being added/customized in each
project. For example:
Email validation enabled?
Logos (application, company, etc.)
Access to external services (webservices?: URL, user, password...)
Google API's ids
Failure/s crash log mail recipients
Extra: User settings like:
Ubiquo home configuration
2. Needs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Dynamism: Changeable at runtime implies a database structure to
handle it
- Setting types
- text: Metatags
- integer: elements_per_page
- bool: administrable_category_sets
- list: Email recipients list
- asset: application logo
- Validation:
- Regex
- List of allowed values
- I18n: The settings should be locale aware, metatags will probably
change for each locale.
3. Implementation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Model
Key / value model like Redmine has for custom_fields:
--------------------------------
| Setting |
--------------------------------|
| translatable |
|-------------------------------|
| context |
| key |
| type |
| value |
| possible_values |
| |
---------------------------------
context: 'ubiquo_core', 'ubiquo_categories' ...
key: unique identifier inside a context
type: string, integer, float, boolean, asset, list_of_values
value: serialized value
possible_values: serialized list of allowed values
- Initialization of settings
Two of the alternatives to discuss:
- Migration based
Each plugin will have a set of migrations as usual in install
directory that will create Setting objects.
We may have problem with plugin updates because migrations must be
copied from plugin directory, we may have to create/force the
synchronization of both directories.
- Read from each plugin
Redesign what we have now in Ubiquo::Config and loaded from Init.rb
and create hash/structure for dynamic settings.
- Access to settings
- From code
Keep using Ubiquo::Config?
- Visualization / administration
- Tab on superadmin mode?
- Even if we render each setting type as it should, would be useful
to allow plugins to define a form template for their own.
- Settings home could better be shown with tab system to easy/fast
visualization.
- Access control
4. Things to do
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Discussion about this proposal
Plugin scaffold
Bernat Foj Capell
You can find the origins of this in the discussion about ubiquo_settings
initiated in
http://groups.google.com/group/ubiquo-gnuine/browse_thread/thread/ccbba5de4963d01d?hl=ca
the proposal takes into account the ideas from Carlos and Ramon.
Cheers,
Bernat
El dc 02 de 03 de 2011 a les 08:37 -0800, en/na David Lozano va
escriure:
David Lozano
Hi,
Sorry for the format. I created a ticket with a pdf file here:
http://ubiquo.lighthouseapp.com/projects/27683-ubiquo/tickets/484-ubiquo_config-proposal
Regards,
David
Bernat Foj Capell ha escrito:
Bernat Foj Capell
Some feedback on some points:
- I'm not sure about moving Ubiquo::Config ("static" configuration) also
in this plugin. For now I'd start just with the dynamic part (calling it
ubiquo_settings)
- How to access: I'd create an API in the Setting class, pretty much
like redmine's one.
- Initialization: For now I'd go with migrations, but mainly because I
don't see a clear way of doing it automatically.
- Setting types: text and integer are pretty much not distinguishable
Cheers,
Bernat
El dc 02 de 03 de 2011 a les 08:57 -0800, en/na David Lozano va
escriure:
> Hi,
>
> Sorry for the format. I created a ticket with a pdf file here:
> http://ubiquo.lighthouseapp.com/projects/27683-ubiquo/tickets/484-ubiquo_config-proposal
>
>
> Regards,
> David
>
> Bernat Foj Capell ha escrito:
> > Side note:
> >
> > You can find the origins of this in the discussion about ubiquo_settings
> > initiated in
> > http://groups.google.com/group/ubiquo-gnuine/browse_thread/thread/ccbba5de4963d01d?hl=ca
> >
> > the proposal takes into account the ideas from Carlos and Ramon.
> >
> > Cheers,
> > Bernat
> >
> > El dc 02 de 03 de 2011 a les 08:37 -0800, en/na David Lozano va
> > escriure:
> > > I would like to ask feedback about the possibility to add a new plugin
> > > to the family. We would love to have any information/suggestion/need/
> > > requirement you can provide.
>
--
Bernat Foj Capell
bf...@gnuine.com
gnuine
www.gnuine.com
C/ Pamplona, 96
Local 17
22@ - 08018 Barcelona
Tel: +34.93.567.94.94
Fax: +34.93.567.94.95
Toni Reina
--
Heu rebut aquest missatge perquè esteu subscrit al grup "ubiquo" de Grups de Google.
Per publicar a aquest grup, envieu un correu electrònic a ubiquo...@googlegroups.com.
Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuin...@googlegroups.com.
Per obtenir més opcions, visiteu aquest grup a http://groups.google.com/group/ubiquo-gnuine?hl=ca.
--
Toni Reina Pérez
are...@gnuine.com
gnuine
http://www.gnuine.com
Fax: +34.93.567.94.95
David Lozano
Hello,
Thanks for the feedback, I've just updated the specs
The name has been changed to ubiquo_settings as it seems that only
would used for 'dynamic' application settings.
http://ubiquo.lighthouseapp.com/projects/27683/tickets/484/a/963685/ubiquo_settings.pdf
ticket: http://ubiquo.lighthouseapp.com/projects/27683-ubiquo/tickets/484-ubiquo_config-proposal#ticket-484-2
Comments are welcomed
Thanks!
--
David Lozano Romera
dlo...@gnuine.com
gnuine
www.gnuine.com
C/ Pamplona, 96
Local 17
22@ - 08018 Barcelona
Tel: +34.93.567.94.94
Fax: +34.93.567.94.95
> Hello,
>
> I agree with Bernat and I think that solving the dynamic part is a good
> choice. Just add a few details: I see no need here the concept of context,
> and I think that 'name' or 'caption' field can be useful to identify setting
> values.
>
> Could you please add examples of how to work with ubiquo_settings? Bernat
> talks about Redmine, but I have no idea how it works :-/
>
> Thanks
>
>
>
>
> > Hi,
>
> > Some feedback on some points:
>
> > - I'm not sure about moving Ubiquo::Config ("static" configuration) also
> > in this plugin. For now I'd start just with the dynamic part (calling it
> > ubiquo_settings)
>
> > - How to access: I'd create an API in the Setting class, pretty much
> > like redmine's one.
>
> > - Initialization: For now I'd go with migrations, but mainly because I
> > don't see a clear way of doing it automatically.
>
> > - Setting types: text and integer are pretty much not distinguishable
>
> > Cheers,
> > Bernat
>
> > El dc 02 de 03 de 2011 a les 08:57 -0800, en/na David Lozano va
> > escriure:
> > > Hi,
>
> > > Sorry for the format. I created a ticket with a pdf file here:
>
> > > Regards,
> > > David
>
> > > Bernat Foj Capell ha escrito:
> > > > Side note:
>
> > > > You can find the origins of this in the discussion about
> > ubiquo_settings
> > > > initiated in
>
> > > > the proposal takes into account the ideas from Carlos and Ramon.
>
> > > > Cheers,
> > > > Bernat
>
> > > > El dc 02 de 03 de 2011 a les 08:37 -0800, en/na David Lozano va
> > > > escriure:
> > > > > I would like to ask feedback about the possibility to add a new
> > plugin
> > > > > to the family. We would love to have any information/suggestion/need/
> > > > > requirement you can provide.
>
> > --
> > Bernat Foj Capell
> > gnuine
> >www.gnuine.com
> > C/ Pamplona, 96
> > Local 17
> > 22@ - 08018 Barcelona
>
> > Tel: +34.93.567.94.94
> > Fax: +34.93.567.94.95
>
> > --
> > Heu rebut aquest missatge perquè esteu subscrit al grup "ubiquo" de Grups
> > de Google.
> > Per publicar a aquest grup, envieu un correu electrònic a
> > ubiquo...@googlegroups.com.
> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a
> > ubiquo-gnuin...@googlegroups.com.
> > Per obtenir més opcions, visiteu aquest grup a
> >http://groups.google.com/group/ubiquo-gnuine?hl=ca.
>
> --
> Toni Reina Pérez
> are...@gnuine.com
>
Ramon Salvadó
The most important thing missing is the functional specification
(how things would work from the user point of view) we need to work on
it and add it to the current document.
There are other things I want to comment but they are minor. I will
come back to them later.
Regards
Ramon
2011/3/17 David Lozano <dlo...@gnuine.com>:
David Lozano
Hi,
Here the document updated with the functional specification and other
feeback:
http://ubiquo.lighthouseapp.com/projects/27683/tickets/484/a/971505/ubiquo_settings.pdf
Thank you,
David
On 17 mar, 14:22, Ramon Salvadó <rsalv...@gnuine.com> wrote:
> Good job,
>
> The most important thing missing is the functional specification
> (how things would work from the user point of view) we need to work on
> it and add it to the current document.
>
> There are other things I want to comment but they are minor. I will
> come back to them later.
>
> Regards
> Ramon
>
>
>
> > Hello,
> > Thanks for the feedback, I've just updated the specs
> > The name has been changed to ubiquo_settings as it seems that only
> > would used for 'dynamic' application settings.
>
>
> > ticket:http://ubiquo.lighthouseapp.com/projects/27683-ubiquo/tickets/484-ubi...
> > Comments are welcomed
>
> > Thanks!
>
> > --
> > David Lozano Romera
Bernat Foj Capell
About the screenshot, usually what we have done with settings is to have
an unique screen with all the settings directly editable there.
Now if we add tabs, this would be another level (I don't know how tabs
could be depicted, but ATM tabs can be left while we create a
centralized tab design). But anyway, I'd stay with the grouped-settings
approach, it looks more user-friendly to me than a listing.
Cheers,
Bernat
El dt 22 de 03 de 2011 a les 07:48 -0700, en/na David Lozano va
--
Bernat Foj Capell
bf...@gnuine.com
gnuine
Bernat Foj Capell
IMHO I prefer the direct edition, but I don't know if the other people
think the same. Any feedback?
Thanks,
Bernat
El dt 22 de 03 de 2011 a les 16:44 +0100, en/na dlozano va escriure:
> Hi Bernat,
> So that way the values will be editable directly on the grouped view or
> you will have to go to the an edit page?
> I thought that it might display too much information for only one page.
> Could be useful a expandable box or a lighwindow instead?
>
> Thanks,
> David
dlozano
Hi Bernat,
So that way the values will be editable directly on the grouped view or
you will have to go to the an edit page?
I thought that it might display too much information for only one page.
Could be useful a expandable box or a lighwindow instead?
Thanks,
David
On mar, 2011-03-22 at 15:57 +0100, Bernat Foj Capell wrote:
Ramon Salvadó
My 2c:
1) ubiquo_setting should provide an interface for plugins to
create/update/delete their settings and shoult not rely on them
knowing about ubiquo_settings internals. (this conflicts with the
selected approach in 3.2).
# This will only initialize these values if they don't already exist
in the database table.
# This interface could be internal and the public one could be a yml file.
# This will return a hash with the initialized values (the ones that
really changed in the db).
Ubiquo::Settings.with_context(:authentication).initialize({ :per_page
=> 10, :ssl = false})
Ubiquo::Settings.with_context(:authentication).initialize do |settings|
settings.per_page = 10
settings.ssl = true
end
This should make it easier to change the settings internals without
fear of breaking everything.
2) About the API for settings I think it would be cool integrate what
we alreay have in ubiquo_config in the settings API. For example:
Ubiquo::Settings.static.media[:aws_secret_key] = 'KJLL(()FYTRE%&E&%' #
Maybe not needed
Ubiquo::Settings[:email_from] = 'cus...@bar.com' # Default context core
Ubiquo::Settings.design[:sticky_widgets] = true
NOTE: Maybe at this point we could drop the static concept completely
since it would seem it isn't really needed if we do point 1. Ah! and
Settings should be a singleton.
3) About the user interface. If it is intended to be used by ubiquo
end users I think it's not friendly enough (I agree with Bernat) which
it's ok if it's developer oriented.
The settings UI needs to be shown in both superadmin and regular
ubiquo (Users | Roles | Settings | Activity).
In regular ubiquo we should only shown user related config options
and in superadmin we show everything. Obviusly from a code point of
view the UI should be the same.
We should use a grouped-setting approach, as Bernat pointed, Maybe
we could use vertical tabs in the sidebar with the default one being
core I think that would be a clean approach and it would be consistent
with what we plan to do with forms.
Regards
Ramon
P.D I think we need to discuss inheritance to get rid of it or to find
a simple or more appropiate solution.
2011/3/22 David Lozano <dlo...@gnuine.com>:
David Lozano
Hi,
The update: http://ubiquo.lighthouseapp.com/projects/27683/tickets/484/a/975475/ubiquo_settings.pdf
Thanks,
David
>
>
>
>
>
>
>
>
> > Hi,
>
> > Here the document updated with the functional specification and other
> > feeback:
David Lozano
Hi,
An update with some specs:
http://ubiquo.lighthouseapp.com/projects/27683/tickets/484/a/1013811/ubiquo_settings.pdf
Thanks,
David
On 24 mar, 11:12, David Lozano <dloz...@gnuine.com> wrote:
> Hi,
>
> The update:http://ubiquo.lighthouseapp.com/projects/27683/tickets/484/a/975475/u...
Ramon Salvadó
My thoughts:
1) I think we should probably design the code to support multiple
backends and not assume it will always be a database. Obviusly we only
need to support a database backend for now and this work may seem
irrelevant right now but it will make it easier to change to a
different backend storage (for performance reasons).
2) I dont like having the ubiquo prefix on plugin contexts, I assume
this is to avoid name conflicts with user defined contexts but right
now I don't see much use for those.
3) Some method name proposals for Settings:
self.overriding_enabled? -> self.overridable?
self.enable_overring -> self.overridable = true
self.add_setting -> self.add # Does the proper thing with a Setting
and with a Hash
self.load_from_db -> self.load_from_backend
self.option_nullable? -> self.nullable?
4) If we follow AR conventions shouldn't settings be called Setting?
Settings make more sense to me in this particular case.
5) New proposal for block definition:
Ubiquo::Settings(:design) do |setting|
setting.boolean :sticky_widgets, :value => true, possible_values =>
nil # Default options should be well thought.
end
6) Block definition in a plugin register
Ubiquo::Plugin.register(:design) do |setting|
setting.boolean :sticky_widgets, :value => true, possible_values =>
nil # Default options should be well thought.
end
7) Single definition and data retrieval
Ubiquo::Settings.design[:sticky_widgets] = true
Ubiquo::Settings.design[:sticky_widgets]
I would also provide another option for data retrieval something like this:
Ubiquo::Settings.sticky_widgets
And if we remove the Ubiquo prefix altogether (I am not sure about this):
Settings.sticky_widgets
I thinks this changes would make it more pleasant to use in application code.
Regards
Ramon
2011/4/14 David Lozano <dlo...@gnuine.com>:
dlozano
Thanks Ramon!
On vie, 2011-04-15 at 08:43 +0200, Ramon Salvadó wrote:
Hi David,
>
> My thoughts:
>
> 1) I think we should probably design the code to support multiple
> backends and not assume it will always be a database. Obviusly we only
> need to support a database backend for now and this work may seem
> irrelevant right now but it will make it easier to change to a
> different backend storage (for performance reasons).
>
>
This was, indeed, proposed and accepted. I should have reflected it in
the doc :|
2) I dont like having the ubiquo prefix on plugin contexts, I assume
> this is to avoid name conflicts with user defined contexts but right
> now I don't see much use for those.
>
>
3) Some method name proposals for Settings:
>
> self.overriding_enabled? -> self.overridable?
> self.enable_overring -> self.overridable = true
> self.add_setting -> self.add # Does the proper thing with a Setting
> and with a Hash
> self.load_from_db -> self.load_from_backend
> self.option_nullable? -> self.nullable?
>
Much better. All were long names to try to avoid collision, but the user
should have a explicit clear naming schema.
> 4) If we follow AR conventions shouldn't settings be called Setting?
> Settings make more sense to me in this particular case.
>
>
The naming was chosen to differenciate the model and the class that
actually handles all. The model for the database backend should better
be renamed.
5) New proposal for block definition:
>
> Ubiquo::Settings(:design) do |setting|
> setting.boolean :sticky_widgets, :value => true, possible_values =>
> nil # Default options should be well thought.
> end
>
> About the boolean call
The differences between setting types (validation mostly) were only
planned to be applied when the settings were defined on a backend. In
this case in a plugin definition, we should apply validation constraints
or give freedom to the developer?
6) Block definition in a plugin register
>
> Ubiquo::Plugin.register(:design) do |setting|
> setting.boolean :sticky_widgets, :value => true, possible_values =>
> nil # Default options should be well thought.
> end
>
> 7) Single definition and data retrieval
>
> Ubiquo::Settings.design[:sticky_widgets] = true
> Ubiquo::Settings.design[:sticky_widgets]
>
> I would also provide another option for data retrieval something like
this:
>
> Ubiquo::Settings.sticky_widgets
>
> And if we remove the Ubiquo prefix altogether (I am not sure about
this):
>
> Settings.sticky_widgets
>
So all this will be supported?
Ubiquo::Settings.context(:BASE)[:default_locale] = :en
Ubiquo::Settings[:default_locale] = :en
Ubiquo::Settings.default_locale = :en
Ubiquo::Settings.context(:design)[:sticky_widgets] = true
assert Ubiquo::Settings[:design][:sticky_widgets]
# We will look for the first value in all context with the desired key
# Also raise error if more than one?
Ubiquo::Settings.sticky_widgets = :en
# Unnecessary?
assert_equal {sticky_widget => {:value => true, :options =>{} },
Ubiquo::Settings.design
Thanks,
David
Ramon Salvadó
Answers below:
2011/4/15 dlozano <dlo...@gnuine.com>:
I would try be consitent here and always apply the constraints. Maybe
we could add a untyped type without constraints to make it explicit at
least.
>
> 6) Block definition in a plugin register
>>
>> Ubiquo::Plugin.register(:design) do |setting|
>> setting.boolean :sticky_widgets, :value => true, possible_values =>
>> nil # Default options should be well thought.
>> end
>>
>> 7) Single definition and data retrieval
>>
>> Ubiquo::Settings.design[:sticky_widgets] = true
>> Ubiquo::Settings.design[:sticky_widgets]
>>
>> I would also provide another option for data retrieval something like
> this:
>>
>> Ubiquo::Settings.sticky_widgets
>>
>> And if we remove the Ubiquo prefix altogether (I am not sure about
> this):
>>
>> Settings.sticky_widgets
>>
> So all this will be supported?
>
> Ubiquo::Settings.context(:BASE)[:default_locale] = :en
This one is only need for compatibility reasons right? I mean it would
be deprecated in future versions...
> Ubiquo::Settings[:default_locale] = :en
> Ubiquo::Settings.default_locale = :en
>
Yes those make sense. I see no problem implementing just one of the
options. I would just implement:
Settings[:default_locale]
Settings.design[:sticky_widgets]
Or
Settings.default_locale
Settings.design.sticky_widgets
> Ubiquo::Settings.context(:design)[:sticky_widgets] = true
> assert Ubiquo::Settings[:design][:sticky_widgets]
> # We will look for the first value in all context with the desired key
> # Also raise error if more than one?
> Ubiquo::Settings.sticky_widgets = :en
I understand this looks for sticky_widgets in the default context only.
Ubiquo::Settings.design.sticky_widgets
This would look inside the design context only (except if inheritable,
then it would look in the default context).
>
> # Unnecessary?
> assert_equal {sticky_widget => {:value => true, :options =>{} },
> Ubiquo::Settings.design
>
>
>
> Thanks,
> David
>