[development] low hanging fruit for Drupal 6: variable defaults

[John Vandervort]

RE: namespaces.

  variable_get('var_name')
  variable_get('var_name', 'namespace_name')

I think both should be valid.  The "" namespace would be for legacy modules
or those who
don't want namespace.  The second would be preferred and allow uniqueness
and loading of the entire
namespace in a single db call.

I just don't think variable name stomping or 'sufficiently large' variable
names are a good thing:)



On 5/3/07, Larry Garfield <larry at garfieldtech.com> wrote:
>
>
> +1 to centralized defaults.  I don't know from localization, so I'll leave
> it to Gabor to decide what's best for that.
>
> The "variable registry" hook seems consistent with what Drupal 6 is
> doing.  We have a menu callback registry (hook_menu), a forms registry
> (hook_forms), we now have a theme registry (hook_theme), why not a variable
> registry (hook_variables)? :-)  I'm open to either that or mandated
> variable_set() in .install.  I think the registry would be a bit easier for
> development (easier to add/change quickly), while mandated variable_set()
> would mean we don't need to add another hook to each module (less code++).
>
> I'm not wild about the namespace concept, until I see a code sample of how
> I'd use it.  Would that replace the second
> parameter?  variable_get('system', 'site_name')?  Remember that modules call
> variables across the module-line all the time, so that needs to be kept as
> simple as possible.
>
> As long as we're mucking about in the variable system, the cache system
> recently introduced a "serialized" flag to specify if a given value needs to
> be serialized or not.  (I believe the default was object/array = serialize
> else don't bother.)  That saves the unserialization time on a string or
> int.  Given that the variable table is loaded completely on a page load, I
> think the same thing could work here to reduce the amount of deserialization
> required.  I dare say half of the stuff stored there, probably more, is just
> ints and strings that don't need to be serialized.  (And it would make
> manually setting clean URLs off easier, a common support request. <g>)  I'm
> not sure how that impacts the registry/install question, but consider that a
> feature request while you're at it.
>
> Hm, here's another use case I just thought of...  Do we have cases where
> the default from variable_get() is itself dynamic, such as the return value
> from another function?  If so, is that rare enough that we can say "just use
> NULL there and throw in your own if statement"?
>
> --Larry Garfield
>
> On Thu, 3 May 2007 08:15:40 -0700, "John Vandervort" <
> jvandervort at gmail.com> wrote:
> > Nice.  I hadn't read adrian's thread before.  If only I'd searched on
> > 'relm'
> > :)
> >
> > So if we change the variable table to (system.install):
> >
> >       db_query("CREATE TABLE {variable} (
> >         namespace varchar(128) NOT NULL default ''
> >         name varchar(128) NOT NULL default '',
> >         value longtext NOT NULL,
> >         language varchar(12) NOT NULL default '',
> >         PRIMARY KEY (namespace, name, language)
> >       ) /*!40100 DEFAULT CHARACTER SET UTF8 */ ");
> >
> > We'd be halfway there.
> >
> > a patch to variable_get, set, del, and init... in bootstrap.inc and we'd
> > maintain full backward compatibility
> > with the current system, but allow namespace uniqueness and a helper
> > function for mass loading...
> >
> >
> >
> > On 5/3/07, Moshe Weitzman <weitzman at tejasa.com> wrote:
> >>
> >> >  - we can save extra typing and value passing on variable_get calls
> >> >  - we have a hook to reuse when we need a list of variables
> >> >    to present for localization
> >> >
> >> > adds pluses over just using constants.
> >> >
> >> > Sure, only using constants for default variable values could be make
> >> > variable usage better, but I think a hook do more just by being a
> >> > central place and not a set of unrelated constants.
> >>
> >> i'd like to see this centralized in a hook too. we'll be one step
> closer
> >> to
> >> the hierarchy that adrian proposed long ago:
> >> http://lists.drupal.org/archives/development/2006-06/msg00309.html
> >>
> >
> >
> >
> > --
> > -> JV
> >
> >
>
>


-- 
-> JV
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070503/4470cd4e/attachment-0001.htm