Re: Variables

0 views
Skip to first unread message

Jo

unread,
Jun 16, 2010, 7:17:49 AM6/16/10
to Sailfish-Project
First run through, adding a column to modvars and user vars column -
xar_type varchar 8 to hold short or long form of variable type (eg
integer, string, boolean, array etc). Updates to xarMod.php and
xarVar.php as appropriate.

Issues perhaps requiring comment/discussion:
- function signatures are not backward compatible now. We can change
if required?
- we don't really need a xar_type on the user var table given it
should be the same as the parent mod var?
- user vars are retrieved and cached indepdendent of mod var - so
perhaps we do need the xar_type on user var table?
- cached vars - how do we handle the xar_type attribute? Any
preference for syntax/saving to cache?
- config vars and session vars are stored serialized - do we want
(cast) type column on those as well?
- removed theme var related code

Next run through requires update of all xarModSetVar with the (cast)
type - defaults to string at the moment.

Final run through I'll start conoslidating/cleaning code for the vars.

We can revisit any of the above as needed. Let me know if any specific
area above is required to be optimized/running as a priority.

John Cox

unread,
Jun 16, 2010, 7:26:59 AM6/16/10
to sailfish...@googlegroups.com
On Wed, Jun 16, 2010 at 7:17 AM, Jo <joj...@gmail.com> wrote:
First run through, adding a column to modvars and user vars column  -
xar_type varchar 8 to hold short or long form of variable type (eg
integer, string, boolean, array etc).  Updates to xarMod.php and
xarVar.php as appropriate.

Issues perhaps requiring comment/discussion:
 - function signatures are not backward compatible now. We can change
if required?

I'm not worried about backwards compatibility.  I'll convert the modules that we need when the time comes, as there are a ton of things that won't work as is;)

 
 - we don't really need a xar_type on the user var table given it
should be the same as the parent mod var?


I wouldn't think.  Those vars we can call with an extra parameter of the user id.

 
 - user vars are retrieved and cached indepdendent of mod var - so
perhaps we do need the xar_type on user var table?

See above, unless I misunderstand.
 
 - cached vars - how do we handle the xar_type attribute? Any
preference for syntax/saving to cache?

Nope, up to you.
 
 - config vars and session vars are stored serialized - do we want
(cast) type column on those as well?

Yes, I would think so.  Should all vars be serialized to match?

 
 - removed theme var related code

Yup.  On that topic, you may have to delete your cache as I deleted the themes module last night and moved the CSS handling to the base module.  

 

Next run through requires update of all xarModSetVar with the (cast)
type - defaults to string at the moment.

kk

 

Final run through I'll start conoslidating/cleaning code for the vars.

:)  It's fun tearing stuff apart isn't it:)

 

We can revisit any of the above as needed. Let me know if any specific
area above is required to be optimized/running as a priority.

Nope, I have plenty to work on, and don't worry about committing broken code into the repo, if we can install good, if not, I can work around it:)

Reply all
Reply to author
Forward
0 new messages