Re: [PHP] php includes === Dreamweaver library items
: loop2 --
!-- END DYNAMIC BLOCK: loop1 --
I can assign values and get the predicted result, but if I try to use the
fastTemplate method clear_dynamic(loop2) I do not get the predicted
result. The above situation is rather uncommon, and I work around it by
including HTML code into the php page, and assigning the result to a
fasttemplate variable. This special consideration works fine for the few
pages that need the above nested loop, and the problem only appears if I
need to clear() a nested loop, which is another rare thing. A good point
though, but relatively rare in my experience. Even following my process for
handling nested loops in php using fasttemplate, it is likely less
complicated than attempting the same loop without fasttemplate.
b) Extra Luggage
Extra luggage, maybe, but would your prefer to stuff all your clothes into
one suitcase, or organize them nicely into two? To further elaborate on the
analogy, it sure would be a lot easier to travel with companion using two
suitcases. Using a templating system, like FastTemplate, saves countless
hours in a redesign, especially if all your doing is redesigning the HTML.
The designers I work with are on the extreme end of the print design world,
they need to see exactly what the page will look like. The fasttemplate
{VARIABLES} have never been an issue.
c) Implications of php4 output buffering control
If you do not use CachedFastTemplate, then I would certainly look into using
the buffered output for caching. Aside from cachinc, I have no further
experience with output buffering.
d) Dreaweaver library files/php includes
This indeed will remain an awkward arrangement. Possible? Yes, of course,
most things are, but awkward indeed.
e) Making variable place holders more useful to designers
This is a neat idea. If end up setting up php up pages to process the page,
then echo variables, this sounds like a great idea.
FINALLY)
If you need up update the html pages from command line or basic text editor,
you still can. Dreamweaver's library items remain consist across all of the
applied pages, I just do a find on all open documents with EditPad, and the
site is updated the same way Dreamweaver would have updated the pages.
Robert V. Zwink
http://www.zwink.net/daid.php
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of George Whiffen
Sent: Thursday, September 06, 2001 1:20 PM
To: Robert V. Zwink
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP] php includes === Dreamweaver library items
Robert,
Your time and trouble in going through the issues are much appreciated, and
I'm starting to warm to the idea of FastTemplate. It seems DYNAMIC BLOCK is
the answer
to the itty bitty little html file problem, but I'm still not entirely
happy..
a) Nested Loops
I notice the warnings about unpredictable results with nested DYNAMIC
BLOCKs.
Does that mean I can't have two levels of detail e.g. a list
of invoices and their detail lines (if any) on the same page?
b) Extra Luggage
I have a strong preference for using as few tools as possible. This is why
I like php so much and why I don't like Perl. With php 99% of the
functionality
is built-in to the the core and you don't have to worry about picking up
extra utilities. I can't see the case for FastTemplate is overwhelming,
given
that php is ALREADY a templating language. Apart from an extra level of
indirection that allows for cleaner tags in the html, I can't see that it
adds
that much. On the other hand it's clearly less powerful than raw php.
c) Implications of php4 output buffering control
I wonder if the new facilities for processing output buffers in php4 have
an impact on the best approach for templating. Now that you have full
control
over the php output buffer, doesn't that reduce the importance of templating
systems such as FastTemplate whichpre-process output before it gets to
php's output buffer? I have the feeling that if you were/are designing
a templating system from scratch for php4, you could get a lot more
functionality
for less work now e.g. it would be easy to allow full embedding of php, by
just
carrying out the template parse after the first round of php processing
rather
than before.
d) Dreaweaver library files/php includes
Having tried the .lbi/php include trick i.e. use Dreamweaver library files
as server includes, it does work, but not brilliantly. Funnily enough, my
main problem was that Dreamweaver insists on library items consisting of
complete blocks so my header and footer each had to split in two to
draw out the side columns from the top and bottom sections.
e) Making variable place holders more useful to designers
The other unpleasantness I found with Dreamweaver is that php tags don't
look
so nice as variable names as the variable place holders. However I think I
may have an even more attractive alternative than a cute variable name
Re: [PHP] php includes === Dreamweaver library items
://www.powerspec.com/support/support_archive.html?selection=4611
Here is an example of the parsed output, notice the file names?
http://www.powerspec.com/support/support_archive.phtml?selection=4611
View the source and you will see where Dreamweaver keeps notes of where
library items should go.
The
problem seems to be to make sure they don't show up in the saved
Dreamweaver html file as well as it's saved library item.
The problem you describe is really a feature, if used properly this
feature can pretty handy. I don't believe that Dreamweaver's Library
items are meant to be directly included into php pages. You are supposed
to allow Dreamweaver to update all the pages affected by the library item
after you make a change to the library item. Its one of the reasons to use
Dreamweaver. Its seems possible to write a regex to remove the library item
and replace with a php include(), but this is really what FastTemplate was
made to do in the first place, so you've reinvented the wheel.
Also another reason to consider Template (IMHO) are the programmers who
support them, Sascha Schumann wrote the article I referred you to, Andrei
Zmievski wrote Smarty (another templating system for php). phplib contains
a templating system, and I'm sure there are countless others. Templates
seem to be adopted by experieced programmers more often than not. I haven't
even mentioned the advantages of CachedFastTemplate which is reason alone to
use templates.
If you decide to try it out, I'm happy to relay my experiences.
Robert V. Zwink
http://www.zwink.net/daid.php
-Original Message-
From: George Whiffen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 05, 2001 2:34 PM
To: [EMAIL PROTECTED]; Robert V. Zwink
Subject: Re: [PHP] php includes === Dreamweaver library items
Robert,
Thanks for the suggestions, but...
a) I do want to do this and I do think I can.
The big problem is not the templating, php is pretty damn good at that
already.
It's handling the header/footer html which appears on every page.
On the one hand we only want one master copy so there's only one
thing to fix if it's wrong, on the other hand we want the designer's
tools (Dreamweaver in this case), to show the page they're designing
with those headers/footers included while they work locally on their server.
I still think this can be done with Dreamweaver's library items. They seem
to be
held as separate files with little snippets of html, just as we'd
hold them on the server, so with a little discipline or fancy ftp
synchronisation we can make sure they are up to date. The problem seems
to be to make sure they don't show up in the saved Dreamweaver html file as
well
as it's saved library item.
b) I looked at FastTemplate and I'm pretty sure I don't want
to use it.
The main difference from a pure php approache seems to be that instead
of embedding real live php in the template (and then hiding it
from the designers), instead you embed your own invented tags that
you then separately translate into the results of some php via tpl
methods.
The disadvantage is that you seem to have to create lots
of itty bitty little .tpl files for every part of the page which
is either repeated or conditional and bunches of other structure
which doesn't do anything to help productivity or maintainability.
I would much rather include the looping/conditional php in the template
itself,
safely tucked away in a php tag e.g. (using the FastTemplate example)
mytemplate.html
HTML
BODY
TABLE
TITLEHALLO/TITLE
?php
// Start looping through files
while($filename = readdir($handle))
{
$filesize = filesize($filename);
?
TR
TD?= $filename?/TD
TD?= $filesize?/TD
/TR
?php
// End of loop through files
}
?
/TABLE
/BODY
/HEAD
etc.
myphpprogram
Then the master php just has :
//standard stuff
$handle = opendir(...);
//error checking
include(mytemplate.html)
close($handle);
The template can then include any number of loops and conditionals all in
the
same full previewable/editable html page. It's not going to be a perfect
copy of the final page i.e. each repeating section only appears once and
conditionals always appear, but that's impossible anyway until you actually
execute the page on the server.
But compared to the FastTemplate approach this is less code, less files,
less things to go wrong, same amount of coordination with the designers,
more educative for the designers (some might even get curious and look at
the php!), and it does mean the designers get a whole page to work
on/preview.
I guess FastTemplate may improve reusability of the html formats
by splitting the html into separate chunks. That might matter for system
admin/software engineering type applications where you might list the same
kind of data in the same format more than once. But in my
RE: [PHP] php includes === Dreamweaver library items
George Whiffen,
a) Nested Loops
One problem that I see is that if I have nested loops:
!-- BEGIN DYNAMIC BLOCK: loop1 --
{LOOP1_VARIABLE}
!-- BEGIN DYNAMIC BLOCK: loop2 --
{LOOP2_VARIABLE}
!-- END DYNAMIC BLOCK: loop2 --
!-- END DYNAMIC BLOCK: loop1 --
I can assign values and get the predicted result, but if I try to use the
fastTemplate method clear_dynamic(loop2) I do not get the predicted
result. The above situation is rather uncommon, and I work around it by
including HTML code into the php page, and assigning the result to a
fasttemplate variable. This special consideration works fine for the few
pages that need the above nested loop, and the problem only appears if I
need to clear() a nested loop, which is another rare thing. A good point
though, but relatively rare in my experience. Even following my process for
handling nested loops in php using fasttemplate, it is likely less
complicated than attempting the same loop without fasttemplate.
b) Extra Luggage
Extra luggage, maybe, but would your prefer to stuff all your clothes into
one suitcase, or organize them nicely into two? To further elaborate on the
analogy, it sure would be a lot easier to travel with companion using two
suitcases. Using a templating system, like FastTemplate, saves countless
hours in a redesign, especially if all your doing is redesigning the HTML.
The designers I work with are on the extreme end of the print design world,
they need to see exactly what the page will look like. The fasttemplate
{VARIABLES} have never been an issue.
c) Implications of php4 output buffering control
If you do not use CachedFastTemplate, then I would certainly look into using
the buffered output for caching. Aside from cachinc, I have no further
experience with output buffering.
d) Dreaweaver library files/php includes
This indeed will remain an awkward arrangement. Possible? Yes, of course,
most things are, but awkward indeed.
e) Making variable place holders more useful to designers
This is a neat idea. If end up setting up php up pages to process the page,
then echo variables, this sounds like a great idea.
FINALLY)
If you need up update the html pages from command line or basic text editor,
you still can. Dreamweaver's library items remain consist across all of the
applied pages, I just do a find on all open documents with EditPad, and the
site is updated the same way Dreamweaver would have updated the pages.
Robert V. Zwink
http://www.zwink.net/daid.php
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of George Whiffen
Sent: Thursday, September 06, 2001 1:20 PM
To: Robert V. Zwink
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP] php includes === Dreamweaver library items
Robert,
Your time and trouble in going through the issues are much appreciated, and
I'm starting to warm to the idea of FastTemplate. It seems DYNAMIC BLOCK is
the answer
to the itty bitty little html file problem, but I'm still not entirely
happy..
a) Nested Loops
I notice the warnings about unpredictable results with nested DYNAMIC
BLOCKs.
Does that mean I can't have two levels of detail e.g. a list
of invoices and their detail lines (if any) on the same page?
b) Extra Luggage
I have a strong preference for using as few tools as possible. This is why
I like php so much and why I don't like Perl. With php 99% of the
functionality
is built-in to the the core and you don't have to worry about picking up
extra utilities. I can't see the case for FastTemplate is overwhelming,
given
that php is ALREADY a templating language. Apart from an extra level of
indirection that allows for cleaner tags in the html, I can't see that it
adds
that much. On the other hand it's clearly less powerful than raw php.
c) Implications of php4 output buffering control
I wonder if the new facilities for processing output buffers in php4 have
an impact on the best approach for templating. Now that you have full
control
over the php output buffer, doesn't that reduce the importance of templating
systems such as FastTemplate whichpre-process output before it gets to
php's output buffer? I have the feeling that if you were/are designing
a templating system from scratch for php4, you could get a lot more
functionality
for less work now e.g. it would be easy to allow full embedding of php, by
just
carrying out the template parse after the first round of php processing
rather
than before.
d) Dreaweaver library files/php includes
Having tried the .lbi/php include trick i.e. use Dreamweaver library files
as server includes, it does work, but not brilliantly. Funnily enough, my
main problem was that Dreamweaver insists on library items consisting of
complete blocks so my header and footer each had to split in two to
draw out the side columns from the top and bottom sections.
e) Making variable place holders more useful to designers
The other unpleasantness I found with Dreamweaver is that php tags don't
look
so
RE: [PHP] php includes === Dreamweaver library items
I dont' think you can do this, or that you would want to do this. Library items in Dreamweaver (as I understand it) are snippets of HTML that Dreamweaver marks as updatable accross the entire site. They are not included into the HTML, dreamweaver keeps track of where they need to go, then updates the entire HTML page. The html page does not include the library item, Dreamweaver handles updating the pages the library item applies. If you want to make your life easier familiarize the php developer(s) with FastTemplate. Check out: http://www.phpbuilder.com/columns/sascha19990316.php3 for more information. I hope this helps. Robert Zwink http://www.zwink.net/daid.php -Original Message- From: George Whiffen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 10:40 AM To: [EMAIL PROTECTED] Subject: [PHP] php includes === Dreamweaver library items Hi, Has anyone experience of using Dreamweaver library item files (.lbi)s as php includes? We've got a standard header and footer to go across all pages on a site with the navigation etc. We want both the designers, (using Dreamweaver), and the php programmers to have access to these includes, so that the Dreamweavers can view the pages automatically with the headers/footers shown, and the programmers can still maintain the pages and includes without Dreamweaver. I don't fully understand how Dreamweaver library files work, so I guess my questions are : a) Can you use a url for a Dreamweaver libary file rather than using a local file so we can all share a single master copy? b) Can we tell Dreamweaver to include the libary file's html when previewing but exclude it when saving, so we don't end up with the library code twice, once embedded by Dreamweaver on the save and once included by php at execution? (I insist on the live page using the master version as I'm not prepared to trust the Dreamweavers to rebuild the pages when the library files change!) I guess I've got workarounds if the answers to these prove negative. For a) I can bully the Dreamweavers into keeping the master/local copies in step, and for b) I guess I can get the php to strip out the Dreamweaver copy of the library code at execution with a little bit of spoofing of Dreamweaver about where php starts and ends i.e. something like ?php turn_into_an_include(ENDLIBRARY ? dreamweaver library item tags and text !-- ENDLIBRARY ); //--?php ? where turn_into_an_include is a function which just finds the library file name in the passed string of library code and includes it from the appropriate server directory. Of course, this is a bit clumsy, any better suggestions? Many thanks, George ? c) In the worst case I guess, we can live with local and master copies of library files and remind the Dreamweavers to always update the master when they make changes get the php code to strip out the embedded library file html at execution time and replace it with an appropriate include statement of the server copy. I've got an idea how to do this by as anyone else tried this? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] php includes === Dreamweaver library items
George,
You do not need to have multiple tiny template files. We create a website
in Dreamweaver using builtin library items. This website has many pages,
sharing the same header and footer library item. Within the html page we
use only two template constructs:
{VARIABLE_NAME}
and:
!-- BEGIN DYNAMIC BLOCK: block_name --
!-- END DYNAMIC BLOCK: block_name --
that's it. Nothing more. Our naming convention consists of filename.html
contains formatting and {VARIABLES}, filename.phtml contains template code
to suck-in the template, replace the {VARIABLES} with information, and spit
it back out.
If we need to update all the headers or footers, we update the header or
footer library item in Dreamweaver, and all the corresponding pages are
updated. The header and footer file may be single files somewhere, but
regardless dreamweaver updates every file that needs to be updated and the
site reflects the changes.
We have worked on a broad range of sites, and I have worked on quite a few
independently without dreamweaver, and this seems like the most efficient
setup for designers that are familiar using Dreamweaver. I personally don't
care for Dreamweaver, but if I am designing a site on my own, I still use
FastTemplate. The only difference is that using FastTemplate without
Dreamweaver benefits from a separate header and footer HTML file.
This scenario probably is better demonstrated than explained. Regardless it
works well for us, and has proven advantageous.
Here is an example of a template:
http://www.powerspec.com/support/support_archive.html?selection=4611
Here is an example of the parsed output, notice the file names?
http://www.powerspec.com/support/support_archive.phtml?selection=4611
View the source and you will see where Dreamweaver keeps notes of where
library items should go.
The
problem seems to be to make sure they don't show up in the saved
Dreamweaver html file as well as it's saved library item.
The problem you describe is really a feature, if used properly this
feature can pretty handy. I don't believe that Dreamweaver's Library
items are meant to be directly included into php pages. You are supposed
to allow Dreamweaver to update all the pages affected by the library item
after you make a change to the library item. Its one of the reasons to use
Dreamweaver. Its seems possible to write a regex to remove the library item
and replace with a php include(), but this is really what FastTemplate was
made to do in the first place, so you've reinvented the wheel.
Also another reason to consider Template (IMHO) are the programmers who
support them, Sascha Schumann wrote the article I referred you to, Andrei
Zmievski wrote Smarty (another templating system for php). phplib contains
a templating system, and I'm sure there are countless others. Templates
seem to be adopted by experieced programmers more often than not. I haven't
even mentioned the advantages of CachedFastTemplate which is reason alone to
use templates.
If you decide to try it out, I'm happy to relay my experiences.
Robert V. Zwink
http://www.zwink.net/daid.php
-Original Message-
From: George Whiffen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 05, 2001 2:34 PM
To: [EMAIL PROTECTED]; Robert V. Zwink
Subject: Re: [PHP] php includes === Dreamweaver library items
Robert,
Thanks for the suggestions, but...
a) I do want to do this and I do think I can.
The big problem is not the templating, php is pretty damn good at that
already.
It's handling the header/footer html which appears on every page.
On the one hand we only want one master copy so there's only one
thing to fix if it's wrong, on the other hand we want the designer's
tools (Dreamweaver in this case), to show the page they're designing
with those headers/footers included while they work locally on their server.
I still think this can be done with Dreamweaver's library items. They seem
to be
held as separate files with little snippets of html, just as we'd
hold them on the server, so with a little discipline or fancy ftp
synchronisation we can make sure they are up to date. The problem seems
to be to make sure they don't show up in the saved Dreamweaver html file as
well
as it's saved library item.
b) I looked at FastTemplate and I'm pretty sure I don't want
to use it.
The main difference from a pure php approache seems to be that instead
of embedding real live php in the template (and then hiding it
from the designers), instead you embed your own invented tags that
you then separately translate into the results of some php via tpl
methods.
The disadvantage is that you seem to have to create lots
of itty bitty little .tpl files for every part of the page which
is either repeated or conditional and bunches of other structure
which doesn't do anything to help productivity or maintainability.
I would much rather include the looping/conditional php in the template
itself,
safely tucked away in a php tag e.g. (using the FastTemplate
