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
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
> 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.
> 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.
- 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:
> > 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.
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
On Tue, Mar 8, 2011 at 8:14 AM, Bernat Foj Capell <b...@gnuine.com> wrote:
> - 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:
> > > 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.
> 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-gnuine@googlegroups.com. > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a > ubiquo-gnuine+unsubscribe@googlegroups.com. > Per obtenir més opcions, visiteu aquest grup a > http://groups.google.com/group/ubiquo-gnuine?hl=ca.
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.
> 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
> On Tue, Mar 8, 2011 at 8:14 AM, Bernat Foj Capell <b...@gnuine.com> wrote:
> > 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:
> > > > 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.
> > --
> > 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-gnuine@googlegroups.com.
> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a
> > ubiquo-gnuine+unsubscribe@googlegroups.com.
> > Per obtenir més opcions, visiteu aquest grup a
> >http://groups.google.com/group/ubiquo-gnuine?hl=ca.
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.
> 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.
> gnuine > www.gnuine.com > C/ Pamplona, 96 > Local 17 > 22@ - 08018 Barcelona
> Tel: +34.93.567.94.94 > Fax: +34.93.567.94.95
> On 10 mar, 14:51, Toni Reina <are...@gnuine.com> wrote: >> 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
>> On Tue, Mar 8, 2011 at 8:14 AM, Bernat Foj Capell <b...@gnuine.com> wrote:
>> > 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:
>> > > > 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.
>> > -- >> > 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-gnuine@googlegroups.com. >> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a >> > ubiquo-gnuine+unsubscribe@googlegroups.com. >> > Per obtenir més opcions, visiteu aquest grup a >> >http://groups.google.com/group/ubiquo-gnuine?hl=ca.
>> gnuinehttp://www.gnuine.com >> C/Pamplona 96, planta 2, porta 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-gnuine@googlegroups.com. > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuine+unsubscribe@googlegroups.com. > Per obtenir més opcions, visiteu aquest grup a http://groups.google.com/group/ubiquo-gnuine?hl=ca.
> 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.
> > 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.
> > On 10 mar, 14:51, Toni Reina <are...@gnuine.com> wrote:
> >> 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
> >> On Tue, Mar 8, 2011 at 8:14 AM, Bernat Foj Capell <b...@gnuine.com> wrote:
> >> > 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:
> >> > > > 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.
> >> > --
> >> > 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-gnuine@googlegroups.com.
> >> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a
> >> > ubiquo-gnuine+unsubscribe@googlegroups.com.
> >> > Per obtenir més opcions, visiteu aquest grup a
> >> >http://groups.google.com/group/ubiquo-gnuine?hl=ca.
> > --
> > 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-gnuine@googlegroups.com.
> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuine+unsubscribe@googlegroups.com.
> > Per obtenir més opcions, visiteu aquest grup ahttp://groups.google.com/group/ubiquo-gnuine?hl=ca.
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 escriure:
> 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.
> > > 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.
> > > On 10 mar, 14:51, Toni Reina <are...@gnuine.com> wrote: > > >> 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
> > >> On Tue, Mar 8, 2011 at 8:14 AM, Bernat Foj Capell <b...@gnuine.com> wrote:
> > >> > 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:
> > >> > > > 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.
> > >> > -- > > >> > 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-gnuine@googlegroups.com. > > >> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a > > >> > ubiquo-gnuine+unsubscribe@googlegroups.com. > > >> > Per obtenir més opcions, visiteu aquest grup a > > >> >http://groups.google.com/group/ubiquo-gnuine?hl=ca.
> > > -- > > > 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-gnuine@googlegroups.com. > > > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuine+unsubscribe@googlegroups.com. > > > Per obtenir més opcions, visiteu aquest grup ahttp://groups.google.com/group/ubiquo-gnuine?hl=ca.
> 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: > > Hi David,
> > 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 > > escriure: > > > Hi,
> > > 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
> > > > 2011/3/17 David Lozano <dloz...@gnuine.com>:
> > > > > 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.
> > > > > On 10 mar, 14:51, Toni Reina <are...@gnuine.com> wrote: > > > > >> 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
> > > > >> On Tue, Mar 8, 2011 at 8:14 AM, Bernat Foj Capell <b...@gnuine.com> wrote:
> > > > >> > 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:
> > > > >> > > > 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.
> > > > >> > -- > > > > >> > 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-gnuine@googlegroups.com. > > > > >> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a > > > > >> > ubiquo-gnuine+unsubscribe@googlegroups.com. > > > > >> > Per obtenir més opcions, visiteu aquest grup a > > > > >> >http://groups.google.com/group/ubiquo-gnuine?hl=ca.
> > > > > -- > > > > > 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-gnuine@googlegroups.com. > > > > > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuine+unsubscribe@googlegroups.com. > > > > > Per obtenir més opcions, visiteu aquest grup ahttp://groups.google.com/group/ubiquo-gnuine?hl=ca.
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:
> 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 > escriure: > > Hi,
> > 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
> > > 2011/3/17 David Lozano <dloz...@gnuine.com>:
> > > > 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.
> > > > On 10 mar, 14:51, Toni Reina <are...@gnuine.com> wrote: > > > >> 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
> > > >> On Tue, Mar 8, 2011 at 8:14 AM, Bernat Foj Capell <b...@gnuine.com> wrote:
> > > >> > 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:
> > > >> > > > 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.
> > > >> > -- > > > >> > 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-gnuine@googlegroups.com. > > > >> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a > > > >> > ubiquo-gnuine+unsubscribe@googlegroups.com. > > > >> > Per obtenir més opcions, visiteu aquest grup a > > > >> >http://groups.google.com/group/ubiquo-gnuine?hl=ca.
> > > > -- > > > > 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-gnuine@googlegroups.com. > > > > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuine+unsubscribe@googlegroups.com. > > > > Per obtenir més opcions, visiteu aquest grup ahttp://groups.google.com/group/ubiquo-gnuine?hl=ca.
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:
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.
> 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.
>> > 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.
>> > On 10 mar, 14:51, Toni Reina <are...@gnuine.com> wrote: >> >> 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
>> >> On Tue, Mar 8, 2011 at 8:14 AM, Bernat Foj Capell <b...@gnuine.com> wrote:
>> >> > 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:
>> >> > > > 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.
>> >> > -- >> >> > 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-gnuine@googlegroups.com. >> >> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a >> >> > ubiquo-gnuine+unsubscribe@googlegroups.com. >> >> > Per obtenir més opcions, visiteu aquest grup a >> >> >http://groups.google.com/group/ubiquo-gnuine?hl=ca.
>> > -- >> > 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-gnuine@googlegroups.com. >> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuine+unsubscribe@googlegroups.com. >> > Per obtenir més opcions, visiteu aquest grup ahttp://groups.google.com/group/ubiquo-gnuine?hl=ca.
> -- > 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-gnuine@googlegroups.com. > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuine+unsubscribe@googlegroups.com. > Per obtenir més opcions, visiteu aquest grup a http://groups.google.com/group/ubiquo-gnuine?hl=ca.
> 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:
> 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.
> > 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.
> >> > 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.
> >> > On 10 mar, 14:51, Toni Reina <are...@gnuine.com> wrote:
> >> >> 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
> >> >> On Tue, Mar 8, 2011 at 8:14 AM, Bernat Foj Capell <b...@gnuine.com> wrote:
> >> >> > 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:
> >> >> > > > 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.
> >> >> > --
> >> >> > 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-gnuine@googlegroups.com.
> >> >> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a
> >> >> > ubiquo-gnuine+unsubscribe@googlegroups.com.
> >> >> > Per obtenir més opcions, visiteu aquest grup a
> >> >> >http://groups.google.com/group/ubiquo-gnuine?hl=ca.
> >> > --
> >> > 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-gnuine@googlegroups.com.
> >> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuine+unsubscribe@googlegroups.com.
> >> > Per obtenir més opcions, visiteu aquest grup ahttp://groups.google.com/group/ubiquo-gnuine?hl=ca.
> > --
> > 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-gnuine@googlegroups.com.
> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuine+unsubscribe@googlegroups.com.
> > Per obtenir més opcions, visiteu aquest grup ahttp://groups.google.com/group/ubiquo-gnuine?hl=ca.
> On 23 mar, 09:22, Ramon Salvadó <rsalv...@gnuine.com> wrote:
> > Hi,
> > 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:
> > 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.
> > > 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
> > >> 2011/3/17 David Lozano <dloz...@gnuine.com>:
> > >> > 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.
> > >> > On 10 mar, 14:51, Toni Reina <are...@gnuine.com> wrote:
> > >> >> 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
> > >> >> On Tue, Mar 8, 2011 at 8:14 AM, Bernat Foj Capell <b...@gnuine.com> wrote:
> > >> >> > 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:
> > >> >> > > > 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.
> > >> >> > --
> > >> >> > 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-gnuine@googlegroups.com.
> > >> >> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a
> > >> >> > ubiquo-gnuine+unsubscribe@googlegroups.com.
> > >> >> > Per obtenir més opcions, visiteu aquest grup a
> > >> >> >http://groups.google.com/group/ubiquo-gnuine?hl=ca.
> > >> > --
> > >> > 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-gnuine@googlegroups.com.
> > >> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuine+unsubscribe@googlegroups.com.
> > >> > Per obtenir més opcions, visiteu aquest grup ahttp://groups.google.com/group/ubiquo-gnuine?hl=ca.
> > > --
> > > 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-gnuine@googlegroups.com.
> > > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuine+unsubscribe@googlegroups.com.
> > > Per obtenir més opcions, visiteu aquest grup ahttp://groups.google.com/group/ubiquo-gnuine?hl=ca.
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
>> On 23 mar, 09:22, Ramon Salvadó <rsalv...@gnuine.com> wrote:
>> > Hi,
>> > 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:
>> > 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.
>> > > 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
>> > >> 2011/3/17 David Lozano <dloz...@gnuine.com>:
>> > >> > 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.
>> > >> > On 10 mar, 14:51, Toni Reina <are...@gnuine.com> wrote: >> > >> >> 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
>> > >> >> On Tue, Mar 8, 2011 at 8:14 AM, Bernat Foj Capell <b...@gnuine.com> wrote:
>> > >> >> > 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:
>> > >> >> > > > 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.
>> > >> >> > -- >> > >> >> > 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-gnuine@googlegroups.com. >> > >> >> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a >> > >> >> > ubiquo-gnuine+unsubscribe@googlegroups.com. >> > >> >> > Per obtenir més opcions, visiteu aquest grup a >> > >> >> >http://groups.google.com/group/ubiquo-gnuine?hl=ca.
>> > >> > -- >> > >> > 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-gnuine@googlegroups.com. >> > >> > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuine+unsubscribe@googlegroups.com. >> > >> > Per
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?
> Ubiquo::Plugin.register(:design) do |setting| > setting.boolean :sticky_widgets, :value => true, possible_values => > nil # Default options should be well thought. > end
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
> 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?
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.
>> Ubiquo::Plugin.register(:design) do |setting| >> setting.boolean :sticky_widgets, :value => true, possible_values => >> nil # Default options should be well thought. >> end
> 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).
> -- > 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-gnuine@googlegroups.com. > Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuine+unsubscribe@googlegroups.com. > Per obtenir més opcions, visiteu aquest grup a http://groups.google.com/group/ubiquo-gnuine?hl=ca.
