Page 1 of 4
levelsensitive navigation - 0.4 available
Posted: Mon 12. Sep 2005, 11:46
by usta
Updates, readme, yadda-yadda
v 0.4 ist verfügbar – wenn du updatest, füge den bestehenden Tags auf jeden fall ein ":" an (ohne "). Mehr steht in der readme.
v 0.4 is available – if you update, please without fail add a ":" (without "s) to existing tags. What’s new? Please view the readme.
- ich habe eine Demo online:
there’s a demo online:
- Demo
wer den tag will, bekommt ihn als:
get the zip (including instructions):
- ZIP download (v0.4)
oder als
or view the source-code:
- Quellcode
ratlos? Selbstverständlich gibt es eine
you’re in a quandary? Therefore we’ve got the
- readme
ein Schema:
a scheme:
- go!
please note pico's hint.
{NAV_LIST_SETLEVEL:back:0 :0 :1 :1:id } – erklärt/ explained:
- :back name for upper level (blank for auto)
- :0 show upper level link (1: yes, 0:no)
- :0 set wich level to display (>= 0)
- :1 autohide? (1: yes, 0:no)
- :1 preserve background? (1: yes, 0:no)
- :id set css-id (anything, default is levelsensitive)
{NAV_TABLE_SETLEVEL :0 :1}
- :0 set wich level to display (>= 0)
- :1 autohide? (1: yes - recommended, 0:no)
features
- da muss er hin:
- copy the file into:
- der tag in seiner ganzen schönheit (obwohl eine tiefer gelegene ebene aktiv ist, verbleibt die 2. ebene als angezeigt):
- here we go (although a lower level is activated, still level no 2 is displayed):
- die tabelle schaltet sich dynamisch zu:
- the table appears, if a specific level is reached:
- man kann hintergrundplatz reservieren:
- one can preserve space for background:
- muss man aber nicht:
- but one don’t has to:
- show upper level: {NAV_LIST_SETLEVEL1:0:1:1}
- auto show upper level: {NAV_LIST_SETLEVEL::1:0:1:1}
- hide upper level: {NAV_LIST_SETLEVEL0:0:1:1}
Posted: Mon 12. Sep 2005, 12:01
by pico
Hi
great Work
just a Comment from me - maybe you add it to your Docu
for use of this you must set
Code: Select all
$phpwcms["allow_ext_init"] = 1; //allow including of custom external scripts at frontend initialization
$phpwcms["allow_ext_render"] = 1; //allow including of custom external scripts at frontend rendering
in ../config/phpwcms/conf.inc.php
Posted: Mon 12. Sep 2005, 13:14
by usta
pico wrote:
for use of this you must set
Code: Select all
$phpwcms["allow_ext_init"] = 1;
$phpwcms["allow_ext_render"] = 1;
in ../config/phpwcms/conf.inc.php
Ta! - i updated the readme, and added a link for this hint.
Posted: Mon 12. Sep 2005, 16:44
by rtilghman
Hey, nice work, looks great. Just wondering what the major differences are between this and the normal "nav_list" replacement tag? I read the readme but I'm still a little lacking in information. Not that I question the value of this new RT, just because I want to know exactly what the advantages are so I can decide whether it will provide me with more options (I use nav_list for local nav now).
For example, nav_list will already show contextual navigation (i.e., the subnav for a particular nav item when that nav item is selected), so whats the difference with this sitelevel one? From what I can see this new RT allows you to specify a specific level at which the navigation "shows up"... and otherwise its hidden? Is the advantage the ability to define fewer templates for use among a variety of areas of your site?
I currently have a separate primary and secondary navigation bar. Something like:
__________________
1.1 | 2.1 | 3.1
HEADER
1.1.1/2.1.1/3.1.1, etc.
The secondary navigation is contextual, but because it exists separately I have to use separate templates for each of the primary pathways.... i.e., 1.1 has an Area template with an RT with its subnav, 2.1 has another Area template, etc. Would this RT allow me, "technically", to use one template for all the area pages? Basically if I used this RT for the subnav would it detect the active area and present the correct navigation?
There are other reasons I have separate templates (namely diferent images/headers/colors), but the ability to have at least a single tag for navigation would be a big gain.
Best,
Rick
Posted: Wed 14. Sep 2005, 09:54
by usta
rtilghman wrote:Just wondering what the major differences are between this and the normal "nav_list" replacement tag?
nav_list_top only displays the first level - constantly
NAV_ROW:CURRENT and NAV_LIST_CURRENT are displaying the current level only - dynamicly
my tag constantly displays a non-current level, wich is not the first level.
and yes: it's a one-template-fits-all-tag
Posted: Wed 14. Sep 2005, 16:45
by rtilghman
Yes, but "nav_list" does that. You can specify a specific level to take navigation from using the ID for a given location. For example, the following is a replacement tag I use on a page in my site:
{NAV_LIST:14:localnav}
This tag is called in a txt content part and placed in a RT location at the top of the right column. It creates the following:
<ul class="localnav0">
<li><a href="index.php?careersmgmt">Management</a></li>
<li><a href="index.php?careersue">User Experience</a></li>
<li><a href="index.php?careerspm">Project Management</a></li>
<li><a href="index.php?careerstech">Technology</a></li>
</ul>
If there were subareas you would see those as well. Like I said, just trying to pin down exactly whats new with this RT. I like some of what appear to be the more adaptive features of this RT, just not exactly clear on the workings from the example and what the advantages are.
Thanks,
Rick
Posted: Thu 15. Sep 2005, 12:03
by usta
{NAV_LIST:14:localnav}
i don't use ID's, because ID's are likely to change.
my tag is not meant to rival the ID-version.
... as may best please you!
Posted: Thu 15. Sep 2005, 14:39
by StudioZ
usta wrote:
i don't use ID's, because ID's are likely to change.
Usta: Regarding ID's, I may be wrong... but this is not how I understand it.
I think that ID's are the most stable and absolute unique identifiers for your categories, pages, and pages' content parts. They will never change. Even if you move a category or a page or a content part, it will still keep it's unique ID.
Please someone, correct me if I am wrong
Posted: Thu 15. Sep 2005, 16:59
by usta
StudioZ wrote:Even if you move a category or a page or a content part, it will still keep it's unique ID.
thus, you'll move the point, your navi starts at. or rather imagine, what will happen, if you delete a section...
Posted: Mon 19. Sep 2005, 18:04
by rtilghman
Actually, that's not really an accurate assessment of the situation, and I don't think the difference you site supports your argument.
First IDs don't change. The only way they actually would change is if I went in, deleted a location, and recreated it with another location. Point blank I shouldn't be doing this; the locations and hierarchy I created initially should have been properly thought out and extensible.
Second "Alias" is, for the most part, no more stable or reliable than "ID" as a means of driving navigation or RTs. Yes, if I delete an article or a level that I rely on my navigation would fail to function. However, I wouldn't ever have navigation triggered by an arbitrary level, so the only level or article I could delete would be central to my entire site.
Finally, you seem to assume that changing any targeted navigation I use in my templates is difficult. Even on my current site, which uses 14 templates (yeah, don't ask, its a long story) it wouldn't take more than 10-15 minutes or so to go in and change the proper section of each one (since its identical).
As I said previously, I'm not questioning the value of your script as much as I'm trying to pull out the specific advantages it provides me. While I'm still foggy, I can see the value of a script that can always display the navigation from a given level down, regardless of the "pathway" the template is called within. Just one more step on my road to a single template website.
Best,
Rick
Posted: Mon 19. Sep 2005, 21:20
by Timo S.
Hi Usta! Hat sich ja viel getan hier =) werds morgen mal antesten!
Off-Topic: war jetzt 1,5 Wochen ausgenockt, mir hat's die Hauptplatte(250gb) gecrasht... *ohman! ich kann nur jedem raten: backuped was das Zeuch hält... meine Datein sind zu 90% übern jordan, keines der üblichen Programme scheint da noch was retten zu können... hmpf und das war ne 4 monate alte maxtor SATA... sämtliche Kundendaten (Photoshop / Freehand / Flash etc. ) der letzten 3 jahre futsch. Naja bin wohl selbst schuld. =( mal sehn ob ich mir die kosten ans bein binde das teil prof. öffnen und recovern zu lassen *hmpf! macht also nicht den fahler ohne backups zu fahren!!
Posted: Wed 21. Sep 2005, 19:12
by Timo S.
Hi Usta!
Habs getestet und für Klasse empfunden! Genau das, was ich brauchte! Herzlichen Dank, dass Du uns das Teil hier zur Verfügung stellst!
Great Job! THX!
Posted: Wed 21. Sep 2005, 20:07
by usta
wohoo! naja, arbeite gerade an einer dhtml-version, mit vorschau, usw... wird aber noch ein gaaanzes stück dauern.
@ rtilghman: well, i need some time, to make up my mind, cause i'm quite stressed, and explaining such difficult things in a foreign language gives me a hard time extra...
so, i'd say: perhaps you want to give it a try and see, what it does, and to what extent it's capable to ease your chore.
Posted: Mon 26. Sep 2005, 19:05
by Willinger
Soll ich hier jetzt dt. oder en. reden??
Well, ...
First of all. That is great stuff right there. Just one question:
Will there be or is there a version that does the same but uses unordered list (<ul>) instead of tables or a simple mixture of text and spacer graphics?
Especially regarding usability and -equally important- semanics <ul> would be great.
The basic RT-features WCMS offers rely on tables and this mixture mentioned above which unfortunately means I have to rule out these features for my web projects.
Posted: Wed 28. Sep 2005, 14:59
by usta
the row is <ul>-based, the <table> is acting up as well.
what do you fancy with "usability and -equally important- semanics"?? and which features will be "ruled out"? and why?