Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#16 2008-05-27 23:29:53
- uli
- Moderator
- From: Cologne
- Registered: 2006-08-15
- Posts: 4,319
Re: Central storage for site-wide constants: Helpful?
Interesting to read where this has grown in the meantime!
Will it be also possible to use variable names already created by txp code/plugins? If so:
- Is there a list of var names anywhere?
- How can I display the currently used ones and their contents?
In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links
Offline
Re: Central storage for site-wide constants: Helpful?
Uli, insert <pre><txp:php>print_r($GLOBALS);</txp:php></pre> somewhere in your template.
Offline
Re: Central storage for site-wide constants: Helpful?
Commited as change set 2899.
uli wrote:
How can I display the currently used ones and their contents?
<txp:variable name="humtata" value='<txp:php>global $site_slogan; echo $site_slogan;</txp:php>' />;Last edited by wet (2008-05-28 04:39:34)
Offline
Re: Central storage for site-wide constants: Helpful?
wet, your fingers are inspired…
A sci-fi feature request:
Imagine…
Imagine a future functionality (a plug-in?) on the admin side… that looks (parses) for declared <txp:variable name="varname" value="" /> on top of templates and then, somewhere in the admin interface (probably in a tab we want to make accessible for our clients… or not), it renders (automagically and on-the-fly) little form, made from a label (txp:variable name value) and a text input field (prefilled with txp:variable value value) for each txp:variable for every variable in every template.
Then, using that form, we/our-clients can rewrite the value of any variable on any template (that means, we set a new value, hit “Submit”, then TXP magic dust goes to the template, looks for the corresponding txp:variable name="name" tag and rewrites it with the new value for value.
Some ideas about this:
- no need for storing the variable name/value on the database
- no need to give access to template tab to our clients if, for some reason, we/they need to change the value for a variable.
- we will be able to create some on-the-fly mechanisms for controlling template logic, and so, the HTML output
Example:
<txp:variable name="closed_for_vacation" value="no" />
<txp:variable name="display_banner" value="yes" />
// ...
// ...
<txp:if_variable name="closed_for_vacation" value="yes">
We are closed for vacations. Come back later.
<txp:else />
It's open. We are here.
</txp:if_variable>
//...
//...
<txp:if_variable name="display_banner" value="yes">
Super mega banner.
<txp:else />
No banner here.
</txp:if_variable>Again, for those two declared variables, there is a magic parser that looks for txp:variable and creates on the fly the two label/text input fields for changing the current value to a new one.
Client changes the value, hits submit, the value is replaced on the tag (on the template).
Then, clients will be able to control the chunks of conditional code, in other words, of the output, in a new way.
Am… I… missing… something?
Last edited by maniqui (2008-05-28 05:43:16)
Offline
Re: Central storage for site-wide constants: Helpful?
no need for storing the variable name on the database
Well, the variables are inherently stored in the database (via forms and pages). They just lack defined records.
I think it would be easier to modify variables from an admin form if they were stored in a txp_variables table. Users can define form-modifiable ones through the admin, as in your example, or they can use them in templates like the current implementation (“inline”). The inline ones won’t be modifiable via the admin.
So closed_for_vacation would be defined and edited in an admin form, but <txp:variable name="tmp" val="foo"/> in a page wouldn’t be modifiable through the admin.
Last edited by jm (2008-05-28 05:59:11)
Offline
Re: Central storage for site-wide constants: Helpful?
maniqui wrote:
Am… I… missing… something?
Frankly, this is a hmm… awkward… concept. I wouldn’t want to count the support threads and bug fixes stemming from such an implementation. Databases are made to handle name/value pairs quite reasonably.
It’s no big deal to code a plugin which retrieves values for <txp:variable /> from a table and let the user enter values in a backend tab. Maybe I’ll do one if the need arises.
Offline
#22 2008-05-28 09:41:45
- uli
- Moderator
- From: Cologne
- Registered: 2006-08-15
- Posts: 4,319
Re: Central storage for site-wide constants: Helpful?
Thanks, jm.
Robert, sorry, I’m not a coder, thus the php contained in the value seems contradicting/senseless to me, especially the use of “echo” as a value. [edit: to make myself more clear: I think I understand what the php alone does, what does it as a value in txp:variable?] What would your example do? Set the contents of “humtata” to the stored value of the site’s slogan?
I have no clue yet of what can be achieved by <txp:variable />, nevertheless I’m seeing exciting possibilities in using <txp:if_variable />.
Last edited by uli (2008-05-28 09:49:16)
In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links
Offline
Re: Central storage for site-wide constants: Helpful?
uli wrote:
Set the contents of “humtata” to the stored value of the site’s slogan?
Yes.
Offline
#24 2008-05-28 10:38:29
- uli
- Moderator
- From: Cologne
- Registered: 2006-08-15
- Posts: 4,319
Re: Central storage for site-wide constants: Helpful?
Ah, yup! (Seems I learn.) Thanks.
In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links
Offline
Re: Central storage for site-wide constants: Helpful?
wet wrote:
Frankly, this is a hmm… awkward… concept. I wouldn’t want to count the support threads and bug fixes stemming from such an implementation. Databases are made to handle name/value pairs quite reasonably.
Ah, ok.
I thought the idea was to not leave traces on the database, and that made me think this awkward idea about a created-on-the-fly manager for variable values.
Last edited by maniqui (2008-05-28 15:39:01)
Offline
Re: Central storage for site-wide constants: Helpful?
Related but off topic…
Parsing css and inserting site-wide constants would be awesomely powerful. I imagine that parsing css slow things down quite a bit, but if you use some kind of css-caching ala rvm_css this would be alleviated after the initial build of a site.
Colors, margins, paddings floats, even entire methods could be modularized this way…
Thoughts?
Offline
Re: Central storage for site-wide constants: Helpful?
rvm_css does static caching, because CSS is exactly that: static. If you parse CSS it’s no longer static. The only way to find the correct CSS would be to parse it and that has to happen when fetching the CSS.
Offline
Re: Central storage for site-wide constants: Helpful?
But it could do a little parsing during the ‘save’ event. Endless possibilities ;-)
Offline
Re: Central storage for site-wide constants: Helpful?
Yep, I had pictured it the way Wet described it. When you save the css it parses some nice little variable-ish constants. Then it is served up as static.
Offline
Re: Central storage for site-wide constants: Helpful?
Shaun Inman has already done all the hard thinking.
Offline