User defined Template Variables to be used in pages & blocks
Brought to you by:
ytztech
Menu
▾
▴
#17 User defined Template Variables to be used in pages & blocks
1) Would be fine to be able to define admin's own
template Variables in pages & blocks.
New variables could be added on Content Editor admin
interface.
It would be useful for some reusable elements like:
static links, date, html colors, company name, info, etc...
Then could be inserted through the Page Editor or the
Block Editor, or the suggested Template Editor (using
<!-- variable name --> template tag style).
2) As for the used <!-- ... --> style template tag: it
is very good, but would be useful to make the template
tag delimiters changeable by the admin in FreeWPS
config. The reason is, that if some users are moving
from another CMS to FreeWPS, they likely uses different
template tag styles, like <% ... %>, or { ... }, or %%
... %%, etc...
The configurable template tag delimiters would really
help other users to minimize the number of changes,
they need to do on their templates.
Thanks,
Webmaster33
Logged In: YES
user_id=132281
Furthermore, Template Variable tags should have 2 types:
Global and Local
Global tags should be available sitewide, on every page & block.
Local tags should be available in current entity and below,
based on Local tag hierarchy.
Local tag hierarchy should be the following:
1) Category assigned pages (page group):
Local tags assigned to a Category, should be available on
all Pages assigned to the Category, and on the Blocks
assigned to the pages in the Category.
2) Individual page:
Local tags assigned to a Page, should be available on that
page and on the blocks assigned to that page.
3) Block
Local tags assigned to a Block, should be available on that
Block only.
The Global and Local Template Variable tags should be
possible to add, edit, delete on the specific Admin page,
like category, page or block edit pages.
These features would make FreeWPS a very flexible system.
Thanks,
Webmaster33
Logged In: YES
user_id=483336
Anyone can define their own template variables. There are
two methods available now in v1.3b1 and more will be
available in the near future.
1. Any additional blocksides that are defined show up as "<!--
BLOCKSIDECONTENT-->", where "blockside" represents the
side name.
2. Any other defined template tags can be filled at runtime
using the FUNCTION custom_createpage() in the STYLE.PHP
file. Some PHP coding and SQL knowledge may be needed to
make this bit work, but it does work. I know of at least one
professional website that uses this method to randomize the
display of a background image with every page load, pulling
an image name from an SQL table and replacing a custom tag
(I think the tag is <!--BGIMAGE-->) with the file name.
As to your second point, I chose the use of HTML comments
for the sole purpose of making the design process as easy as
possible for those with no CGI experience. This may be a
minor point, but that's a pretty significant plus in favor of
FreeWPS over other systems. A simple find-and-replace can
fix most of those templates (although, why would someone
use %% as a beginning and ending delimiter).
I haven't given up your suggestion, but I would like to get
more feedback before dedicating resources to it. And your
additional comment just confuses me. The template tags are
only for replacement at runtime. If you want to juggle blocks
between pages (where some blocks only appear on certain
pages), that feature is available in the v2.0 demo, as well as
per-page templates, so that each page could have a different
template (if you choose). This feature will expand in the final
2.0 release to include all pages in a category as well.
Logged In: YES
user_id=483336
Request from another RFE:
A Context based help about available template tags (at
bottom of current editor page) would be fine on Page
Editor, on Block Editor, and on the suggested Template
Editor. It would show those Global and Local template
tags, which are actually available for a specific page
or block.
Logged In: YES
user_id=132281
>A simple find-and-replace can
>fix most of those templates (although, why would someone
>use %% as a beginning and ending delimiter).
Personally I prefer & use the ASP like template tags:
<%command parameter%>
And I would not want to change to other style, due to
compatibility things (with other templating system).
>And your additional comment just confuses me.
Sorry that I confused you.
However I think the suggestions are clear:
1) Definable variables (it exists in some way as you pointed
out)
2) Admin Configurable template tag delimiters (should be an
easy modification)
3) Hierarchical Variable system to make complex websites
very flexible.
Just imagine if you need to define, edit i.e. 300 global
variables within the same page/form. Very difficult.
That's why the Global & Local variables was introduced.
Global variable is available everywhere.
Each Local variable should be available at the entity where
it is used and levels below. Local variables can be set in 3
levels.
- Category based Local variable is available on all pages &
blocks assigned to a category.
- Page based Local variable is available on the page we
edit, and the blocks assigned to that page
- Block level Local variable is available only in that one
block.
Is it really confusing?
The logic follows the logic what most website use. Websites
usually have Categories (in other word: page groups), Pages,
Content Blocks on the websites.
Yes, they further have Sides (top, bottom, left, right,
body, etc.), but in case of variable usage, I did not see
the reason to limit a variable usage to a Side.
Best regrads,
Webmaster33
Logged In: YES
user_id=483336
I guess I just don't see the purpose of the global vs. local
thing. Why would I want 300 tags in a page? The system can
handle it and PHP does a fantastic job with strings (see my
post @ php.net comparing array_search to strstr), but would
each page really end up with 300+ template tags? Are you
describing the page template files or some other module to
allow this? The concept of breadcrumbs is ingenious and
useful, and that idea will become an add-on at some point,
but I'm not sure where the multiple-tags-thing applies.
As to the configurable tag delimiters, yes the change would
be easy. However, most website designer are very
comfortable with HTML comments...hence the choice. Maybe
the configurable tags can be an advanced option that can be
enabled, but not by default. Does that sound close enough?
Logged In: YES
user_id=132281
>Maybe the configurable tags can be an advanced option that
>can be enabled, but not by default. Does that sound close
>enough?
That's exactly I suggested. Sounds fine, of course.
>I just don't see the purpose of the global vs. local thing.
>Why would I want 300 tags in a page?
No. Misunderstood me. Not 300 in a page, but 300 sitewide.
300 was just an example number of tags, which number of tags
& variables could be used on a big website. And editing so
much variables on the same page would be difficult & confusing.
Instead, if variables are placed into a hierarchy, then only
those variables are listed to edit for a specific entity
(category, page, block), which belongs to it as Local variable.
Your solutions are fine for small sites, but IMO would fail
for big sites. Just imagine a site with hundreds of pages
and hundreds of categories. How easily can you manage it?
Also there are variables, which I don't want to make
available as global variable, since it belongs to a specific
page. Think how variables behave in different blocks in PHP
or Perl. My suggestion is similar.
Later,
Webmaster33
Logged In: YES
user_id=483336
The template tags are now able to be updated. The tag
delimiters can be modified in the Website Configuration
module, under the "Modify Tag Delimiters" option on the
Navigation menu.
The common template "tags" will have to be a project for
further down the road. I haven't integrated it into my
roadmap, so that should become more solid this week.
Logged In: YES
user_id=483336
The first part of this request has been accepted, although
it's not set to appear until v2.2. The tags will become
available in the editor and will be administered in the
Website Configuration.