TBS combined with a site build with Namo Webeditor

I have build a site with Namo (looks like Dreamweaver). Now I want to merge PHP in several pages. This meens that the Namo-build HTML becomes a template. TBS is started within a new php-file. Then from the PHP-file it builds the HTML out of the template. But then: I use the navigationbanners on the HTML pages, so I can navigate through the entire site. But how can I return to the page or pages that were originally made by TBS? The page wihich is called form the site is different from the merged page, because PHP is not loaded again for the same page. How can I solve this problem?

You see: I'm not really a wizzkid on the subject. But perhaps someone can help me a little further or give me an example of site which works in a simular way?

Hi Jurrien,

>page wihich is called form the site is different from the
> merged page, because PHP is not loaded again for the same page.

I have difficulties to understand your problem.
Could you give an example?

Presume: I have a mini-site: "start.html", "next1.html" and "next2.html". In a separate file "PHP-start.php" I 've put the following:
<?php
include_once('tbs_class.php');
$TBS = new clsTinyButStrong ;
$TBS->LoadTemplate('start.html') ;
$rand = "border=1" ;
$kop = "This is the head." ;
$alinea = "Hello, everybody, this is the message, which I want to write to you all." ;
$voet = "Bottom of the artikel" ;
$list = array($kop,"\n",$alinea,"\n",$voet) ;
$TBS->MergeBlock('blk',$list) ;
$TBS->Show() ;
?>

next I put the following in "start.html":
<table align="center">
   <tr>
      <td>[blk.val;block=tr]</td>
   </tr>
</table>

The "next1" and "next2.html" are linked through a normal referencelinks. There are no TBS fields on these pages. (What if there were???)

Now, I start the template through "PHP-start,php" and my start-page is build correctly. If I then move through the link to the next pages it also workes. But if I return through one of the next pages to the startpage, the TBS is not loaded and there is just some empty TBS blok-code.

The problem is, that the TBS-system is not loaded backwards when I return to the page which was build before from the PHp file. Should there not be some code in the template to make sure that the TBS-system is properly loaded when returning to the build-page?

Perhaps I'm really dum, but I really don't know how to solve this problem. i hope you can do somthing for me. I've build the example in Namo (clean HTML), so I can send you the PHP/HTML as a ZIP to you.

The links on pages "next1.html" and "next2.html" must point on "PHP-start.php" and not on "start.html".
"start.html" is the template, that is not the page you want to show to visitors.

Yes, I understand. But TBS is highly promoted with the possibillity to combine with a WYSIWYG editor like Dreamweaver. And Namo is a "dreamweaver-like" editor (better, of course....). And when the template is build within Namo the links through banners and buttons are standard pointing toward the files within the project.  So, if I want to build the site correctly, I have to adjust the links so they point at the PHP-files. In this case, I make, infact, a parallel page tree system in PHP. And I also have to write the templates with the "PHP" links. That meens I can never test the templates dry. This makes it more complex.

That's why I asked for a possiblity to build a small portion of PHP-code in the template, so the parser is aware of the fact that it is called from a template. To onlu thing it has to do is call the TBS system for the var-fields in the template. It is not neccesary to build a new HTML out of the template again. A kind of software-switch if you know what I mean.

If a car is running, but it jumpes out of the gear. then it is not neccesary to start the engine again: just put the gear back in.

I hope you can replay again to this message, because if a sollution is not possible, then I can not make use of TBS, unfortunatly. But then then TBS has also to remove the sentence that is is specially handy for WYSIWYG-editors, because it isn't.

Hi,

I think I understand your need. You'd like to switch between real mode and design mode from you Html Editor, including navigation through pages. If you are in real mode, links points on dynamic pages (PHP) and if you are in design mode, links points on templates pages (HTML).

That would be very nice but I believe this is impossible for any HTML editor and any dynamic page system (PHP, ASP, ColdFusion, ... even Javascript). Let me explain why.

What you ask is possible only if you have structured you web application with "one dynamic page" = "one template". But this structure is restrictive and quite rare. See portals web pages or other forum applications: the index.php page does many different screens. It is also often useful to have sub-template for header or footer for example. The HTML editor is not able to display sub-template if it doesn't know the language (PHP, ASP, TBS,...).

If you look at Dynamic Web pages system integrated into the HTML Editor (such as Dreamweaver+ColdFusion or FrontPage+ASP) they can't do what you describe.

If you what very strongly your switch feature, you can code a switch variable into you PHP scripts, that will display not merged templates or merged templates as you ask. This is possible and easy, but the switch is not available from the HTML Editor.

I maintain that TBS is especially handy for Wysiwyg Html Editor because you can design a TBS template fully from a Wysiwyg Html Editor (By the way, TBS is the only one to do that). That does not mean full application relations from the Wysiwyg Html Editor.

I think you are right about the problem I have. In fact: when I want to use Namo as a template generator, then I have to drop the linkreferences between the pages in the tree? I have to make static links instead and point them toward the corresponding PHP-pages, is that correct?

But ... and this crosses my mind: isn't than not better to put the normal PHP-code directly in the HTML which is build within Namo c.s? Because Namo builds in fact its own templates. The only thing is, that we wanted to seperate the PHP-code from the HTML, and that is not working anymore.

Do I see that correct? Or am I to short around the corner?

If your Web Editor supports site's map representation, then is only for static Html links. It won't be able to display real links made from any dynamic system. For example, if you have coded some dynamic link in Javascript, then you WEb Editor can't display the links.

Yes your links have to point on php page (only if the target is a dynamic page of course). This is a client side restriction.
If the current page is a static page, then you have to code:
<a href="my_dynamic.php">Click here</a>
But if the current page is a dynamic page, you can use variables or system tags. For example:
<a href="[sys.script_name]">Click here</a>
  or
<a href="[var.tagert1]">Click here</a>


>isn't than not better to put the normal PHP-code
>directly in the HTML which is build within Namo c.s?

What is Name cs ?
PHP+HTML page are dynamic pages with static parts. You have to change the extension into .php or you script won't be executed and the code will be shown to users. The links inside the static parts (the HTML parts) must point the same way as above: to a page php is the target is a dynamic page, to an html page if the target is a static page.
Links in the dynamic parts (php parts) can’t be displayed neither.

Namo templates are template for static pages (That's the same for other Web Editor). You can use them for TBS templates if you what.

I hope that's not too confusing.
(but all this is logical)

I think I have the solution. If I am right, then I can build a site in Namo like I always do, but I give the pages the extension "PHP". That doesn't matter because Namo can handle that. But now I am sure that the connections are correct and testable.
Then, when I am finished with the design thing, I transfer the entire Namo site into another location called "templates" (doesn't matter).
Then in de root directory I make the right TBS files and I let the file call each "php" file from the template directory. The trick is, that in the root-dir every TBS-PHP-files has the same name as the ones in the templatedirectory.
Now TBS turns the template-php into a new PHP file with the same name as the templates. So, when the navigation is pushed, then it points toward the correct PHP-file, which is, in this case, not in the templatedir but in the root. The file doesn't know it is fooled around.
I have tested this with tree files (index, next1 and next2) and everyting works fine.
The only ting to keep in mind is: when I don't need a TBS-PHP file to start the generation of a new one (because there is no dynamics neccesary), I have to copy the template file in the root, so the file can be found when I move through the site.

Thank you for your help, perhaps this solution is to keep in mind for other programmers who work with Namo, Dreamweaver and so on. (Namo c.s. means: Namo and other look-a-likes. It's Dutch, I guess?)

eeuh, waarom draai je niet gewoon een webserver op je eigen pc, dan test je daar live, dan weet je ook meteen of je php en tbs codes goed werken (wat vaak niet zo is) ben je meteen van het hele gedoe af

En de mogelijheid om met wysiwyg editors paginas te bewerken is per pagina verhaal ;)

Trouwens, om bestanden met de zelfde naam aan te houden is een zeer slechte oplossing. (dat moet je maar van me aannemen, dit is mijn werk) Je moet juist gecentraliseerde code maken, en jij maakt nu een soort duaal systeem, wat een hoop extra werk met zich mee brengt, ik wil best wel eens kijken naar wat je aan het maken bent en er mee helpen, mn emailadres staat hierbij, je moet alleen de SP AM er uit halen

Translation:

Well, why don't you just run your own webserver on your own pc, then you can test it in an actual environment, and you will also see directly if php and tbs codes are correct (which mostly isn't the case right away) save you the hasle of using duplicate file names everywhere

And about the editabilty in wysiwyg editors of the templates only goes on a page to page basis.

By the way, keeping files the way you do with duplicate filenames would be a very bad solution. (I suppose you have to take my word for it, I make a living out of programming) I think you should make a smart and centralized system, but you are now talking about making some sort of a parralel file system which brings a lot of maintenance and checking along. I'd be glad to see through your project, and give some pointers where I can, my emailaddress is at the top, just remove SP AM....