Xarigami

Projects

xarigami core

display
news
resources
dev notes
tracker
discuss

theme vars in xarigami core Dan May 28, 2008 04:52 AM

This sounds like something i've wished for before - although I was thinking about some kind of strange hybrid module+theme combination. Obviously, this path is better and provides the exact same functionality.

Do we need some use cases?

#

xarigami core Jo Jul 6, 2008 05:35 PM

Any ideas and use cases you might have throw them up. we can sort through what may and may not be relevant for themevars.

#

auto form complete nuisance Jo Oct 1, 2008 09:23 AM

Doesn't it bug you when you're editing a role and the form autocompletes but you did't noticed 'till you get a bad data error due to only one password entered? Worse, what if you don't notice the autocompleted user display name is not what it should be.

Thanks to Chris in irc today for reminding me what a nuisance it can be. Issue logged http://xarigami.com/contrails/display/xgami/230

#

Hook override horrors Chris Oct 2, 2008 02:19 PM

Jo, I'm giving this some thought and trying to better understand all the problems and underlying causes. Could you expand a little on the problems you see? It's quite possible I've missed some implications, so it'd bee good to see your thoughts.

Also, meant to add this, posted some thoughts earlier (no solutions, just a ramble) http://crispcreations.co.uk/forums/hook-overrides-and-xaraya-t81

#

Re: Hook override horrors Jo Oct 4, 2008 09:30 AM

Hi Chris
Thanks for your post here. I thought I'd publish the var, vars and more vars article i had in progress when you commented here. I hope that gives you an idea of some of the problems I've encountered although again the post was fairly general so if you want specifics please ask away.

My major concern is with end users - as in xaraya site admins or devs. Although I can cope with some of the sideeffects from hook overrides for example, I believe for many end users there could be annoying experiences with hook overrides and time wasted fixing the problems they could (not always) cause. There is always some debris left behind in the database when hook overrides are used that can complicate future 'clean' module reinstalls. Thus i'm not keen on doing formal releases of modules with hook itemtype overrides until we solve these issues.

I was initially looking at the itemvars in 2x but as mentioned in the article, they don't solve the problems i want to addresss and they would still exist in 2x.

I think use cases - ways in which we want to use the different types of variables helps us determine the way ahead. After all it's all about useability imho for devs and site admins alike.

If you have ideas or comments, please .. Smile

#

Re(1): Hook override horrors Chris Oct 4, 2008 05:25 PM

Thanks jo, I'd already read and begun to digest the vars article before you posted this Smile very helpful.

I'm trying to put together a use case, putting it into words is another matter.

Anyway, the way I'm seeing it, is, we need to be able to specify module vars by itemtype, by item, and indeed, by hook module. I know that's a simplistic way of putting it, and maybe not the best solution, but just pondering how, for example, this might fit

xarModGetVar('modname', 'varname', 'itemtype', 'itemid', 'hookmod')

We then have per user (via xarModGetUserVar), per module, per itemtype, per item, and per hookmod settings wrapped up in a single - not unfamiliar - consistent call. Not to mention, that all important separation between module itemtype and hooks we don't have at the moment.

I know, would make for a potentially huge module vars table, but seems like a small price for a big gain.

Anyway, too simplistic? To many overheads? Wrong end of stick? lol, I don't know, just thinking out loud there really, look forward to your thoughts though...

#

Re(2): Hook override horrors Jo Oct 5, 2008 09:04 AM

Thanks for your ideas. Did you have any specific use cases you were thinking of, for example with the per item and peritemtype variables?

I think i would retain the mod user var table for the user vars, as potentially there could be a fall back on any type of module, or itemtype (theme?) var and a separate table seems sensible. I guess i'm still looking for use cases here apart from the ones we already have at the moment. As for item vars apart from these I still need examples - in 2x there are some although the use cases could be handled by normal modvars.

Also - how to handle management and use of the vars in terms of priority of use - eg fall back. Right now for example, if mod user var is not set it falls back to the default, but if set it will always be used. Removing these can be a problem, or at least it is not addressed for most cases in xaraya when used.

As an example, see the moduservar for 'user theme' - in xarigami core we had to go to some trouble just to ensure the admin could reset these if they decided to turn off user theme choice (see the modifyconfig options in Themes in the xarigami demo). If you turn off user theme choice it doesn't automatically remove the moduser var or prevent it from being used. What do you think should happen here ?

I have a few ideas i'm turning over in my head at the moment and will post when i get them to some level of basic organization Razz

#

Re(3): Hook override horrors Chris Oct 5, 2008 05:55 PM

Thanks jo Smile

The per item vars came up as a result of my recent work with BBCode/Smilies and HTML modules. There's an FR outstanding asking for an option to disable said transforms per item. An item var could be used for that, only needs transforms to look for it when transforming. (I realise this can be done by extending the module/itemtype via dd, but that's so clunky)

Itemtype vars, my only real want for these is the less than perfect situation we have now when it comes to setting them, and subsequently trying to remove them - as your themes case proves - incidentally, I've experienced similar with comments module when reverting to no hook module over-rides, with the settings still used.

I'm thinking maybe xarModSet... var functions should accept an extra parameter telling them to reset related vars, which we could then pass in appropriate places, like modify/update config functions. eg xarModSetVar('modname', 'varname', 'newval', 'default') would reset all user vars to that setting in one hit.

Some q's I have about existing function, as I don't purport to know all the functions, but can't recall seeing these...

Do we have a function to delete all user vars in one go for a particular module var?
Do user vars get deleted when we delete the module var?
What happens with module vars such as ('modname', 'settings.'.$itemtype) (cfr cats, articles etc), do they ever get deleted, other than when a module's removed?

Why do theme vars not have a theme user vars equivalent?

Hehe, more q's than a's I guess...

#

Re(4): Hook override horrors Jo Oct 5, 2008 11:46 PM

Re per item vars, I guess the use case you give, if i'm right eg like in articles, is not so common, and probably better done by dd eg a checkbox (i don't think it's necessarily clunky). I probably wouldn't make core changes for that use case but i may have misinterpretted. Out of interest, why would you need to turn on and off HTML/smilies that way on a per item basis?

Itemtype vars - I'm still thinking on these. There are lots of use cases but the core implementation needs some thought. It maybe they should exist with some apis to handle them or perhaps could be implemented in some totally different way. I think the usage on these would be more common than itemvars but maybe i haven't thought it through enough yet.

We have some functions to delete user vars but not in one go. They don't get deleted when we delete the module var; and other vars as you mentioned ('settings.'.$itemtype) only get removed when a module is removed unless you remove them specifically. But then again they are mod vars so treated the same way.

Theme vars are 'existant' in that there are some apis available etc and table - possibly a hangover from postnuke - but have never been used in xaraya. I've done some posts on the current admin GUI that we're adding here to handle these, and why I think there might be a case for using them in xaraya. However again, like the other vars, their standalone status as a var type needs to be reviewed, and rules for usage and so on (thus a pause in that development until all the var types are reviewed and necessary core code put in place). Before I'd ask why theme vars do not have a user var equivalent, I'd pehaps like to define what theme vars are and how they can be used (if at all) in xaraya might be useful first. My main want for using theme vars is to improve theme portability so we can have more distributable themes, independent of site content. At the same time allow some site customization in the GUI (See related earlier articles/posts on theme vars on this site for background).

Time for a new subthread Smile

#

Re(5): Hook override horrors Chris Oct 13, 2008 03:17 AM

Thanks Jo, sorry it's taken me so long to get back to this one, been a little busy around here :/

Right then, the itemvars, and example I gave, came from a specific usecase for the forums module I'm working on. A feature of other forum apps is the ability to disable smilies/html/bbcode on a per post/topic basis. It's an outstanding FR - see Bug 5771 - and has also been requested by users in my mini-beta for CrispBB. I agree it can be done with DD but I'm always reluctant as this inevitably opens up the possibility of the property(ies) being inadvertently deleted. I realise also that I could add fields to cater for this (indeed, that's my current intention), but that's a very specific fix, whereas the availability of itemvars would open up the possibility to introduce similar functionality in other modules.

There may also be other cases where hook modules may want to have specific settings for a specific item, and this would open up more possibilities in that direction too - eg, disable/close comments for a single article. It comes down to being able to add specific settings on per item basis, more granularity.

The itemtype vars, I do feel need some separation from the module vars, and I like the idea of some APIs to handle them as such. As you observe, the usage would be, or in some cases, already is (hook modules etc), more widespread. The current management to my mind isn't adequate to effectively deal with them. Whether that means another table to go with a new set of API functions, or current functions extended, I know, is up in the air. I have no idea of the implications either way, so your thoughts on the possible approaches would be much appreciated there.

The situation with user vars IMO needs to be addressed, they really should be removed along with the module var, if only to prevent their future inclusion if a var is re-instated. The same applies to the situation with modvars like ('settings.'.$itemtype) - although that I would imagine can be addressed with the introduction of itemtype vars.

Although I was aware of the theme vars, I'd never actually entertained them, as I had no idea of their function until I did some code reading following your vars,vars,vars post :@) I see some potential for using theme vars in terms of providing admin/user customisations that don't require template editing, but haven't yet worked out how that might work in context. I did look up the earlier posts on theme vars, but I couldn't figure out what you've actually done to make use of them, or indeed how they might fit in - heh, guess you're right about that sub thread.

Ok, rambled long enough, I'll leave that with you and look forward to the reply Smile

#

the itemvars, and example I gave, came from a specific usecase for the forums module I'm working on.

I guess I'd probably approach the example of an on/off switch per post for smilies etc a little differently, probably as some serialized set of options per post kept in a dedicated field in the post table. It's something that is associated tightly with the post itself and required on post display so seems to me to fit there better than adding itemvars, but that's just my approach.

I haven't quite got the usecases together yet for itemvars and can't seem to make one at this level, although on an object level, i can see an itemvar might related to an itemtype in it's relationship to the object. Somehow i keep coming back to itemtypes here.

In regard to the theme vars, i delayed further work on these until we cemented the variable handling in place. I did start a 'working document' on what I propose to do in relation to variables but forgot to publish it at the time. It should now be viewable at http://xarigami.com/devnote/xaraya_variable_refactor or will be soon if it isn't.

I want to get this right, but also another reason for putting of this work is that things are really getting away from the main core xaraya. If i start implementing these proposed changes, then it will make it difficult to maintain compatibility of modules with upstream core Xaraya. Right now my modules are generally the same bar some minor changes, and the need to double check on xaraya core in addition to xarigami core. These changes would make it very difficult timewise to maintain upstream xaraya and xarigami code versions for modules.

Anyway, keep an eye on the working document with proposed changes. If you have any further suggestions please ... the more feedback the better we can make the final product, and hopefully more useable.

#

The serialised array in a dedicated field is exactly the approach I've taken for the per post/topic options as it happens Jo Smile

"I haven't quite got the usecases together yet for itemvars and can't seem to make one at this level, although on an object level, i can see an itemvar might related to an itemtype in it's relationship to the object. Somehow i keep coming back to itemtypes here."
Same problem, and same end result for me as far as usecase goes. Maybe the addition of the itemtype column you're proposing would suffice, it's certainly a step in the right direction and something which could do with being present in Xaraya's core too. Coupled with proper functions that complement the existing ones for module vars I think it will prove invaluable in the long run.

With regards to the refactor, modvars > uservars. A function to reset the uservars to use the modvar value would be useful - having said that, if the uservars get deleted with a modvar - as proposed, it would be possible to reset by delete/re-create modvar I guess?

...

meant to add, if there's anything I can do to help, you know where I am Smile

#

Where can I get xarigami core? manosucias Oct 18, 2008 11:21 PM

I can't see any download link to the code. Is it only for suscriptors? how can I suscribe?

#

Re: Where can I get xarigami core? Jo Oct 19, 2008 12:00 AM

Thanks for your interest. We are keen to have people using and testing the code so we can improve it and also push any pertinent changes back to the upstream xaraya code.

To date, the xarigami core has been mainly for our clients. Due to requests, we have put in a place a build system and will be offering snapshots to anyone that wants it. If you are registered on site then you will be notified as soon as the builds are available. Please contact me directly if you would like to access the code prior to this.


#

Re(1): Where can I get xarigami core? manosucias Oct 19, 2008 12:10 AM

Thanks Jo for your quick feedback. I'm interested to play around with the snapshots as Xarigami's code improvements looks so interesting, but I can wait to the "official" release.

#