Robert,
Well, I bet you're getting tired of this thread! So just a few closing
remarks:
a) Nested Loops - Yup, they're not so common that we can't just fudge
about with a bit of embedded html.
b) Luggage - I may yet agree with you about the advantages of two neatly
packed bags!
c) An awkward DreamWeaver/php solution -
It seems I'm close to achieving what I set out, it may be functional,
but it's not particularly elegant,thats for sure. Here's how it goes :
For the Dreamweaver user:
- the files on the site targetted by urls are .php templates which remain fully
Dreamweaver editable/previewable and link-testable. All the html is in those
files. The designer can include any number of Dreamweaver library items and change
their names at any time as they like.
- the Dreamweaver library files must be synced with the server along with the .php
templates, style sheets etc. Provided the designers do that, all pages are
guaranteed to have the library code in the current master (server) copy,
which can be edited by any means. Designers have to watch out for master copies
changing either because of the activity of other designers or programmers of course.
For the php programmer:
- the main body of php code (queries etc.) is in a per page include,
i.e. the "template" reads the code instead of the code reading the template! (That's
so the designers can check the links are ok).
- the include of the code is added to the top of the designer's template in a
php tag.
- in the html of the template the progammer adds/checks tags for the php data and
control structures
i.e. for data <?= $myvar;?>
or <?php //?>Example of myvar<?php;print $myvar;?>.
for repeating or conditional blocks you need start and end tags
<?php if ....?> or <?php while ...?> at the start
and <?php };?> at the end of the block.
There are no restrictions on the php you can embed, you can have includes
of any depth, functions, whatever.
- you can also, if you want, add php to library items without restriction.
Noone of that seems to be too bad, but the one special and really horrid extra
on each page is to force the substitution of includes for library
items. It seems (but I haven't tested it fully), that the code to "top and tail "
the actual template html is this :
IMMEDIATELY PRIOR TO ACTUAL TEMPLATE HTML/PHP
eval(dream_sub(strrev(substr(strrev(substr(<<<PHPENDFILE
?>
TEMPLATE HTML/PHP
<HTML>
<HEAD>
etc.....
</HTML>
IMMEDIATELY AFTER ACTUAL TEMPLATE HTML/PHP
<!--
PHPENDFILE
,3)),5))));
//--><?php
?>
where dream_sub is something like this: -
function dream_sub($string)
{
return(preg_replace('/<!-- #BeginLibraryItem "([[:alpha:].\/]+)" -->.*?<!--
#EndLibraryItem -->/'
,'<?php eval(dream_sub(implode("",file("\\1"))));\?\>',$string);
}
(Beware, the regular expression is wrong, I'm still trying to get it to work,
ereg_replace was fine
but
too greedy so I had to switch to preg)
That's it. It's not too much code and it is the same every single time, but
ugly or what!
It could be a bit prettier, but as it's always going to be horrible, I'm tempted
to leave it looking horrible, so noone's under any illusions!
What we're actually doing is turning the whole of the template html/php into
a string via the "heredoc" but while fooling Dreamweaver that we closed the
php tags. We strip out the php/comment tags which fool Dreamweaver with a
strrev and substr's to save having to store the text and then fooling about,
(that could be changed). Then having picked up the template contents we substitute
any Dreamweaver library item tags by an include of whatever the library name was.
Just in case we have nested library items (I don't know if that's possible with
Dreamweaver), we make sure we recursively substitute any library items in the library
item files themselves as we bring them in. (That's why we have the
dream_sub/implode/file stuff
instead of a plain include).
I reckon this should work (when I get the b**** regular expression working!). It
should also
work reasonably well with any other html editors that respect php tags, and if they
have
library functionality it shouldn't be too hard to adapt dream_sub for an appropriate
effect.
At the end of the day, this all seems to be spoiling the Dreamweavers far too much.
I've even
gone back to calling the pages .php rather than leaving them extensionless, just so
that their
stupid desktops don't get too confused! So my urls are going to be uglier but I guess
it at
least means that php gets some credit on the sites!
Anyway, it's been very interesting to hear your ideas, and don't be surprised if I
give up and
switch to FastTemplate!
George
Robert V. Zwink wrote:
>
> 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 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...
> i.e.
> {STATE} is informative when viewing via Dreamweaver/browser
> <?= $state;> just turns into a "PHP" placeholder
> <?php //?>Washington<?php;print $state;?> appears as "Washington" in
> Dreamweaver/Browser
>
> This becomes even more attractive for text blocks e.g.
> <?php /*?>
> Washington is an absolutely great state
> that we should all visit at least 5 times per year.
> <?php*/; print $state_description;?>
>
> The idea is that instead of a variable name the designer gets a practical
> example of how the data may actually look, that simply disappears once it's
> evaluated by php.
>
> FINALLY, I really do agree with you that it would be nice to let Dreamweaver
> do all the work on library items, but I don't want to get locked into always
> depending on Dreamweaver to maintain the templates and their includes. It's
> much nicer in an emergency if I can just change the one include via any text
> editing tool and know the site will still work properly.
>
> Once again, thanks for some very interesting comments and advice,
>
> George
>
> Robert V. Zwink wrote:
> >
> > 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 example)
> >
> > ************ mytemplate.html ************
> > <HTML>
> > <BODY>
> > <TABLE>
> > <TITLE>HALLO</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 world of
> database
> > applications that almost never happens! You just don't show the same data
> > in the same format in more than one place or on more than one page. If
> you
> > do, it's usually an indicator that you've failed to structure your web
> pages
> > properly i.e. you should be reusing the page, not just bits of it.
> >
> > Robert V. Zwink wrote:
> > >
> > > 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]
--
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]
