Re: [PHP] Smarty Tips and Techniques

[Virgilio Quilario]

> Hi Virgil,
>
> After your last post here, I looked at your site, then the Smarty site.
> That was what triggered this question. Templates are a black art to me.
> I don't even know where to begin to understand them. Every reference I
> have looked at so far assumes that I already understand the MVC pattern,
> which is also one of the dark arts.
>
> Let me put it simply. I can't grok OO. I tried to do OOP for several
> years, but it simply does not make any sense to me. As a direct result,
> I don't understand the concept nor application of patterns. So how do I
> figure out how to use templates without having to absorb those first?
> Can I learn enough this way to determine if a site can be converted from
> the current state (PHP and XHTML spaghetti) into templates and begin
> that transformation?
>
> Thank you,
>
> Bob McConnell
>

HI Bob,

Smarty templates are just html files with placholders or variables and
simple constructs.
This was made to allow web designers to work on a page without having
to know PHP programming.
Smarty is not an MVC.
It is just a class that provides all the necessary functions to
replace variables and execute constructs in html page.
You just create an instance, set necessary config, do your PHP stuff,
assign values to template variables, and finally display.
It's just a matter of understanding how its functions or methods work.
You don't have to learn OOP and it is not about OOP or MVC.
It is just a convenient placeholder of functions necessary to run
smarty templates.

Spaghetti style programming can be very hard and really time consuming
to follow and convert.
Just take one step at a time.

Maybe I could write a tutorial for this.
Just need to find some spaghetti code for the  example.

Regards,
Virgil
http://www.jampmark.com

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Tips and Techniques

[Thodoris]

From: Bastien Koert
  

On Thu, Mar 19, 2009 at 11:06 AM, Bob McConnell  wrote:

From: Virgilio Quilario
>> That looks nice, but how do I get to the point where I can


understand
  

>> how to use it?
>>
>> I have also looked at the Smarty site


, but
  

>> their documents assume significant experience in building and


using
  

>> templates.
>>
>> Where can I find guidance or tutorials on how to do all of


this,
  

>> starting with only a rudimentary knowledge of HTML and PHP.


It would
  

be
>> best if they also focused on procedural rather than object


oriented
  

>> code.
>
>
> When I started learning smarty, I spent most of my time doing


research
  

> and that's really tiresome and it is so hard to find examples.
> Experimented a lot and listed those what's possible, then


applied them
  

> to my projects.
>
> Now to make them handy I posted them to my site so i can have


a look
  

> whenever and wherever.
>



http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting-
  

tips-and-techniques-to-make-templates-smarter.html


 
  

>
> As a first step, maybe you should see the crash course at


smarty
  

> http://www.smarty.net/crashcourse.php

Hi Virgil,

After your last post here, I looked at your site, then the


Smarty site.
  

That was what triggered this question. Templates are a black art


to me.
  

I don't even know where to begin to understand them. Every


reference I
  

have looked at so far assumes that I already understand the MVC


pattern,
  

which is also one of the dark arts.

Let me put it simply. I can't grok OO. I tried to do OOP for


several
  

years, but it simply does not make any sense to me. As a direct


result,
  

I don't understand the concept nor application of patterns. So


how do I
  

figure out how to use templates without having to absorb those


first?
  

Can I learn enough this way to determine if a site can be


converted from
  

the current state (PHP and XHTML spaghetti) into templates and


begin
  

that transformation?

Bob,
 
You really would need to learn those concepts first OOP / MVC. There


is
  

 a learning curve, but you really don't need OOP to be able to do an


MVC
  
 style application, but it does make the code neater. 
 
One of the books that really helped me grok OOP is Head First


OOP...another
  
is Martin Fowlers Patterns of Enterprise Architecture. 


The MVC pattern is explained well in a number of places, but worth
 checking out are both the cakephp framework site and the codeingniter


site.
  
 
You'll find that there are people from both camps here, pure OOP and


other
  

just as happy with procedural coding styles. Many use both, using


objects
  

to handle common tasks like DB interaction or filesystem processes.



Yes, I have to deal with both camps here as well. Of five developers
doing PHP at the moment, two are primarily using OOP. But I spent 3.5
years as part of a team developing MS-Windows services in C++. After all
that time, I was only able to write basic functions for others to
convert into methods or classes. I could eventually find my way around
in some of those classes, but it seemed that every time I figured out
what was where, somebody "refactored" a major component and I had to
start all over again. All I saw was a lot of unnecessary overhead and
obfuscation which made little sense in the long run and slowed down both
the development and the application. The result was a handful of DLLs
that are shared between several products, and each time anything is
changed in one of them, every product needs to be retested to make sure
nothing got broke and some have to be recertified for PCI-DSS as well.

So you are telling me that I can forget about trying to use templates.
Since I can not understand OOP, there is no chance I will be able to use
them.

Just knowing that will probably save me several weeks of frustration.

Thank you,

Bob McConnell

  


Well think of the positive side that you don't need to write in OOP in 
order to use Smarty. Think it just like a class used for displaying the 
output (simply put).


At least I've been doing this for some time now (the non-OOP part).

I have a feeling that someone coming from the procedural way of 
programming would have problems probably with the templates instead of 
the development part.


--
Thodoris

RE: [PHP] Smarty Tips and Techniques

[Robert Cummings]

On Thu, 2009-03-19 at 22:54 -0400, Bob McConnell wrote:
> From: Robert Cummings
> >On Thu, 2009-03-19 at 12:14 -0400, Bob McConnell wrote:
> >> From: Bastien Koert
> >> > On Thu, Mar 19, 2009 at 11:06 AM, Bob McConnell 
> wrote:
> >> > 
> >> >  From: Virgilio Quilario
> 
> Most discussion clipped for brevity
> 
> > // OOP
> > 
> > class DbFireman extends DbPerson
> > {
> > private $fireman;
> > 
> > function DbPerson( $id )
> > {
> > parent::__constructor( $id );
> > $this->fireman = load_stuff_for_fireman_from_db();
> > }
> > 
> > function getStationId()
> > {
> > return $this->fireman['stationId'];
> > }
> > 
> > function setName( $name )
> > {
> > $this->fireman['stationId'] = $stationId;
> > }
> > }
> > 
> > $fireman = new DbFireman( 1234 );
> > $fireman->setStationId( 'Bob' );
> > echo $fireman->getStationId();
> > 
> > ?>
> > 
> > So as you can see they're almost identical except that the OOP version
> > of fireman didn't need to redeclare functions. True you could have
> > skipped doing that if you just used the person functions, but then you
> > may introduce onconsistencies. Additionally, the class version ensures
> > that the methods applied are those bleong to the concept of "fireman"
> > whereas passing data structures around can easily get confusing,
> > especially if you choose to allow the person functions to be applied
> to
> > the fireman. Going futher, using OOP let's you do all sorts of generic
> 
> Hi Rob,
> 
> Unfortunately, you still don't understand the problem I have. While it
> takes a while to puzzle out the details, I don't have any trouble
> reading, understanding or debugging code like this, even though you
> skipped completely over several major components (*). I have even
> modified existing methods and made minor adjustments to classes, _once
> they have been written_.
> 
> What I can't do is take a problem description and turn it into classes
> that will actually solve the problem. I can usually turn it into
> procedures relatively quickly. I can and have built real-time,
> multi-tasking and multi-threaded applications on a variety of kernels
> and operating systems with no significant trouble. I have written device
> drivers, interrupt service routines, message queues and I/O buffering
> routines without spending a lot of time thinking about them.

Aaah, you're stuck in procedural mode. In my first year of university
they taught us both C and Smalltalk in different courses and during the
same semester (same semester for me anyways). As such, I didn't form a
bias. Unfortunately they taught us scheme the following year and while I
understand scheme, I have less of a liking for it :)

> But defining objects and then figuring out how to create and use them
> completely escapes me. My mind simply won't map a problem into objects,
> it only sees procedures. Even when I look at classes, they resolve only
> as loose groupings of functions and variables, not as unified
> components.

And what is a library to you? And a library for which each function
requires on being passed a specific structure type? The structure is
merely the object, and the library routines are the methods. if you can
see libraries and structures, then you can see classes and methods.

> If anyone knows how to fix that, please tell me. In the meantime, in my
> continuing effort to eschew obfuscation, I will stick with procedural
> programming.

It's not for people to tell you how to fix it... it for you to unwire
your head and learn it yourself :)


> (*) For example, "$this->" suggests you have added an array of pointers.
> Some are pointers to functions (aka methods) others are pointers to
> variables (aka members). [--SNIPPITY--]
> 
> You also failed to explain what "new" does, or "parent::__constructor".
> What is the relationship between a class and an object? [--SNIPPITY--]

I wasn't teaching your OOP, I was showing that OOP and procedural are
merely different representations of the same thing, and that the
representations aren't all that different.

>  I get frustrated
> because of the extra overhead required to instantiate an object with its
> members before they can be referenced,

If you've done C programming then you know you have to instantiate a
pointer to a structure before you should access any of it's members.
Whether you zero out the memory or actually assign values... you are
still instantiating.

>  instead of simply being able to
> use them at any time from anywhere in my code. Likewise, having to pass
> a pointer for one object to another object before the second can call
> the first is also counter-intuitive. They're all part of the same
> application, why doesn't the compiler take care of those details like it
> should?

I'm not sure what you mean in the above.

> Obviously, I don't expect answers for these questions, but hopefully
> this will give you a better understanding of the greater issues
> involved. This is a

Re: [PHP] Smarty Tips and Techniques

[Bipin Upadhyay]

Bob McConnell wrote:

[SNIPPED]



the fireman. Going futher, using OOP let's you do all sorts of generic



Hi Rob,

Unfortunately, you still don't understand the problem I have. While it
takes a while to puzzle out the details, I don't have any trouble
reading, understanding or debugging code like this, even though you
skipped completely over several major components (*). I have even
modified existing methods and made minor adjustments to classes, _once
they have been written_.

What I can't do is take a problem description and turn it into classes
that will actually solve the problem. I can usually turn it into
procedures relatively quickly. I can and have built real-time,
multi-tasking and multi-threaded applications on a variety of kernels
and operating systems with no significant trouble. I have written device
drivers, interrupt service routines, message queues and I/O buffering
routines without spending a lot of time thinking about them.

But defining objects and then figuring out how to create and use them
completely escapes me. My mind simply won't map a problem into objects,
it only sees procedures. Even when I look at classes, they resolve only
as loose groupings of functions and variables, not as unified
components.

If anyone knows how to fix that, please tell me. In the meantime, in my
continuing effort to eschew obfuscation, I will stick with procedural
programming.

Bob McConnell

(*) For example, "$this->" suggests you have added an array of pointers.
Some are pointers to functions (aka methods) others are pointers to
variables (aka members). But there is no indication where this array
came from, what it means, nor how it affects the code structure. From
experience I know that "$this->" is not always needed, but the C++ rules
for when it is or isn't are neither clear nor consistent. There are no
declarations nor assignments for it. It simply adds another level of
obfuscated dereferencing that needs to be done in my head to understand
what is going on.

You also failed to explain what "new" does, or "parent::__constructor".
What is the relationship between a class and an object? I get frustrated
because of the extra overhead required to instantiate an object with its
members before they can be referenced, instead of simply being able to
use them at any time from anywhere in my code. Likewise, having to pass
a pointer for one object to another object before the second can call
the first is also counter-intuitive. They're all part of the same
application, why doesn't the compiler take care of those details like it
should?

  

Bob,

One of the best books that can help attain a practical understanding of 
OOP is "Head First Java". Please do not be eluded by "Java" in the title.
I'd sincerely encourage you to borrow "Head First Java" from someone, 
and then buy "Head First Object Oriented Analysis & Design".


You'll find answer to most of the questions raised by you, and in pretty 
interesting ways.

Obviously, I don't expect answers for these questions, but hopefully
this will give you a better understanding of the greater issues
involved. This is a far cry from the Fortran IV I was taught in college
40 years ago. B.M.

  

--
Regards,
Bipin Upadhyay.
http://projectbee.org/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Tips and Techniques

[Michael A. Peters]

Bob McConnell wrote:



But defining objects and then figuring out how to create and use them
completely escapes me. My mind simply won't map a problem into objects,
it only sees procedures. Even when I look at classes, they resolve only
as loose groupings of functions and variables, not as unified
components.

If anyone knows how to fix that, please tell me. In the meantime, in my
continuing effort to eschew obfuscation, I will stick with procedural
programming.


As an experienced programmer, please don't laugh too hard at my 
functions within my class - but maybe this will help you:


http://www.clfsrpm.net/xss/cspfilter_class.phps

Other than little piddly stuff (that is just as easily done as a 
function, first class I wrote.


A simplified example of it's usage -

http://www.clfsrpm.net/xss/index.phps

What it does is operate on a DOMDocument object.

I'm not really that fond of OO programming either, but in this case it 
made more sense to view the document to be filtered as objects (xml 
DOMDocument objects) because it made what the filter does much easier to 
program.


Since I was to be operated on object it made sense (to me anyway) to do 
it as a class instead of procedure functions.


However you will notice that all the class really is - is a bunch of 
variable definitions (some public, some private) and procedural 
functions. It's just that they operate only within the scope of the 
DOMDocument object they are told to operate on.


One thing to note - if a function has the same name as the class, it is 
a constructor and will be run when a new instance of the class is 
initiated and it MUST be a public function (why I don't understand, I'd 
prefer it if I could make it private yet still called when a new 
instance of a class is created).


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Smarty Tips and Techniques

[Bob McConnell]

From: Robert Cummings
>On Thu, 2009-03-19 at 12:14 -0400, Bob McConnell wrote:
>> From: Bastien Koert
>> > On Thu, Mar 19, 2009 at 11:06 AM, Bob McConnell 
wrote:
>> > 
>> >From: Virgilio Quilario

Most discussion clipped for brevity

> // OOP
> 
> class DbFireman extends DbPerson
> {
> private $fireman;
> 
> function DbPerson( $id )
> {
> parent::__constructor( $id );
> $this->fireman = load_stuff_for_fireman_from_db();
> }
> 
> function getStationId()
> {
> return $this->fireman['stationId'];
> }
> 
> function setName( $name )
> {
> $this->fireman['stationId'] = $stationId;
> }
> }
> 
> $fireman = new DbFireman( 1234 );
> $fireman->setStationId( 'Bob' );
> echo $fireman->getStationId();
> 
> ?>
> 
> So as you can see they're almost identical except that the OOP version
> of fireman didn't need to redeclare functions. True you could have
> skipped doing that if you just used the person functions, but then you
> may introduce onconsistencies. Additionally, the class version ensures
> that the methods applied are those bleong to the concept of "fireman"
> whereas passing data structures around can easily get confusing,
> especially if you choose to allow the person functions to be applied
to
> the fireman. Going futher, using OOP let's you do all sorts of generic

Hi Rob,

Unfortunately, you still don't understand the problem I have. While it
takes a while to puzzle out the details, I don't have any trouble
reading, understanding or debugging code like this, even though you
skipped completely over several major components (*). I have even
modified existing methods and made minor adjustments to classes, _once
they have been written_.

What I can't do is take a problem description and turn it into classes
that will actually solve the problem. I can usually turn it into
procedures relatively quickly. I can and have built real-time,
multi-tasking and multi-threaded applications on a variety of kernels
and operating systems with no significant trouble. I have written device
drivers, interrupt service routines, message queues and I/O buffering
routines without spending a lot of time thinking about them.

But defining objects and then figuring out how to create and use them
completely escapes me. My mind simply won't map a problem into objects,
it only sees procedures. Even when I look at classes, they resolve only
as loose groupings of functions and variables, not as unified
components.

If anyone knows how to fix that, please tell me. In the meantime, in my
continuing effort to eschew obfuscation, I will stick with procedural
programming.

Bob McConnell

(*) For example, "$this->" suggests you have added an array of pointers.
Some are pointers to functions (aka methods) others are pointers to
variables (aka members). But there is no indication where this array
came from, what it means, nor how it affects the code structure. From
experience I know that "$this->" is not always needed, but the C++ rules
for when it is or isn't are neither clear nor consistent. There are no
declarations nor assignments for it. It simply adds another level of
obfuscated dereferencing that needs to be done in my head to understand
what is going on.

You also failed to explain what "new" does, or "parent::__constructor".
What is the relationship between a class and an object? I get frustrated
because of the extra overhead required to instantiate an object with its
members before they can be referenced, instead of simply being able to
use them at any time from anywhere in my code. Likewise, having to pass
a pointer for one object to another object before the second can call
the first is also counter-intuitive. They're all part of the same
application, why doesn't the compiler take care of those details like it
should?

Obviously, I don't expect answers for these questions, but hopefully
this will give you a better understanding of the greater issues
involved. This is a far cry from the Fortran IV I was taught in college
40 years ago. B.M.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Tips and Techniques

[Michael A. Peters]

Robert Cummings wrote:

On Thu, 2009-03-19 at 18:05 -0700, Michael A. Peters wrote:

Robert Cummings wrote:

On Thu, 2009-03-19 at 16:27 -0700, Michael A. Peters wrote:

Marc Christopher Hall wrote:

The following comment is not intended to be helpful

*smacks head on desk repeatedly...*


This comment is..

I would hazard to say that if you are unwilling or unable to grasp OOP, MVCs
and any decent framework that is necessary then maybe stepping back and
tackling only things you can grasp.
To be honest - one of the problems is that documentation that tries to 
explain these concepts is often severely lacking, using extremely poor 
analogies, and only make sense to people who already have an 
understanding of the concept.


For example -

A car is a good real-world example of MVC. With a car you have two 
views: the interior and the exterior. Both take input from the 
controller: the driver. The brakes, steering wheel and other controls 
represent the model: they take input from the controller (driver) and 
hand them off to the views (interior/exterior) for presentation.


That's from a web page that is suppose to explain MVC.

I bet if you took 50 people who didn't have a clue as to what MVC is - 
maybe 1 or 2 of them would after reading that.


Documentation and howto's, just like code, really need to go through 
real world testing to see if they make sense to people not already 
familiar with the topic.


Unfortunately that rarely happens.

I think you have it back asswards. People need to go through real world
development or innane examples and then someone needs ot tell them where
they went wrong. That's how it worked in university. We got an example
like the one above, then we were expected to apply the principle. Those
who undertood it right away got great marks on their assignment, those
who took a little longer didn't... but if they kept at it... till they
figured it out... they got a good mark on the exam. I don't understand
defeatism. Suck it up! There's a zillion examples on the web. Study
many, learn the generalism.
The problem is I can make a car analogy out of any type of programming 
design method.


And some people can make a programming design method out of a car
analogy. Your point? Analogies are learning aids, not magic.

Most of those who got it right away and got great marks did so NOT 
because of what they learned from the example, but because of what they 
already knew before they signed up for the class.


You can't generalize that statement though. Many students don't know it
before they enter the class. And for those that did... they probably
learnt it from a trivial unrealistic example also.

Thus, when the teacher sees some of his students understanding the 
concept, he becomes smug and arrogant and thinks he did something right 
and those who didn't get it have something wrong with them. The reality 
is he can't teach worth shit and those who understood it did so before 
they took his class, hence he didn't teach them anything.


Once again, you can't generalize that statement. A bad experience with
one teacher can hardly convey a trait to all teachers.

Cheers,
Rob.


I'm not talking about a bad experience with a teacher.
I'm talking about the use of vague analogies that can be applied to 
anything and really only get the point across to someone already 
familiar with the concept.


It's a real problem in documentation, partly because the review, if any 
is done prior to publishing, is by someone else who already has at least 
a vague understanding of the concept.


IBM Developer documentation and Apple developer documentation (IMHO) 
tend to be better about this than most, but even with them it still is a 
real problem.


-=-

Speaking of Car Analogies - in my auto shop class way back when, they 
used a horse and buggy analogy to show that front wheel drive was 
better, because horses pull a cart, they don't push it.


I then asked where the power in a horse comes from - it's hind legs or 
it's front legs. The instructor was silent for a minute, then responded 
"I never thought about that, but you are absolutely right"


That's a serious problem with analogies, they always have serious 
problems that you can only ignore if you already understand the concept 
being portrayed by the analogy, and that's why I personally hate them. 
They seem to be quite popular, however, which is a shame.


Just document what the freakin' thing is - analogies just add confusion.

In the case of front wheel drive, the issue actually is engine location 
- not any horse and buggy crap. With front engines, power is lost down 
the long drive train to the rear wheels.


I bet the "automobile" concept of the a MVC has flaws just as big. A car 
isn't a MVC, it's a freakin' car, and other than the on-board computer 
that adds complexity and increases repair cost, programming method isn't 
part of the design.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.ne

Re: [PHP] Smarty Tips and Techniques

[Robert Cummings]

On Thu, 2009-03-19 at 18:05 -0700, Michael A. Peters wrote:
> Robert Cummings wrote:
> > On Thu, 2009-03-19 at 16:27 -0700, Michael A. Peters wrote:
> >> Marc Christopher Hall wrote:
> >>> The following comment is not intended to be helpful
> >>>
> >>> *smacks head on desk repeatedly...*
> >>>
> >>>
> >>> This comment is..
> >>>
> >>> I would hazard to say that if you are unwilling or unable to grasp OOP, 
> >>> MVCs
> >>> and any decent framework that is necessary then maybe stepping back and
> >>> tackling only things you can grasp.
> >> To be honest - one of the problems is that documentation that tries to 
> >> explain these concepts is often severely lacking, using extremely poor 
> >> analogies, and only make sense to people who already have an 
> >> understanding of the concept.
> >>
> >> For example -
> >>
> >> A car is a good real-world example of MVC. With a car you have two 
> >> views: the interior and the exterior. Both take input from the 
> >> controller: the driver. The brakes, steering wheel and other controls 
> >> represent the model: they take input from the controller (driver) and 
> >> hand them off to the views (interior/exterior) for presentation.
> >>
> >> That's from a web page that is suppose to explain MVC.
> >>
> >> I bet if you took 50 people who didn't have a clue as to what MVC is - 
> >> maybe 1 or 2 of them would after reading that.
> >>
> >> Documentation and howto's, just like code, really need to go through 
> >> real world testing to see if they make sense to people not already 
> >> familiar with the topic.
> >>
> >> Unfortunately that rarely happens.
> > 
> > I think you have it back asswards. People need to go through real world
> > development or innane examples and then someone needs ot tell them where
> > they went wrong. That's how it worked in university. We got an example
> > like the one above, then we were expected to apply the principle. Those
> > who undertood it right away got great marks on their assignment, those
> > who took a little longer didn't... but if they kept at it... till they
> > figured it out... they got a good mark on the exam. I don't understand
> > defeatism. Suck it up! There's a zillion examples on the web. Study
> > many, learn the generalism.
> 
> The problem is I can make a car analogy out of any type of programming 
> design method.

And some people can make a programming design method out of a car
analogy. Your point? Analogies are learning aids, not magic.

> Most of those who got it right away and got great marks did so NOT 
> because of what they learned from the example, but because of what they 
> already knew before they signed up for the class.

You can't generalize that statement though. Many students don't know it
before they enter the class. And for those that did... they probably
learnt it from a trivial unrealistic example also.

> Thus, when the teacher sees some of his students understanding the 
> concept, he becomes smug and arrogant and thinks he did something right 
> and those who didn't get it have something wrong with them. The reality 
> is he can't teach worth shit and those who understood it did so before 
> they took his class, hence he didn't teach them anything.

Once again, you can't generalize that statement. A bad experience with
one teacher can hardly convey a trait to all teachers.

Cheers,
Rob.
-- 
http://www.interjinn.com
Application and Templating Framework for PHP


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Tips and Techniques

[Michael A. Peters]

Robert Cummings wrote:

On Thu, 2009-03-19 at 16:27 -0700, Michael A. Peters wrote:

Marc Christopher Hall wrote:

The following comment is not intended to be helpful

*smacks head on desk repeatedly...*


This comment is..

I would hazard to say that if you are unwilling or unable to grasp OOP, MVCs
and any decent framework that is necessary then maybe stepping back and
tackling only things you can grasp.
To be honest - one of the problems is that documentation that tries to 
explain these concepts is often severely lacking, using extremely poor 
analogies, and only make sense to people who already have an 
understanding of the concept.


For example -

A car is a good real-world example of MVC. With a car you have two 
views: the interior and the exterior. Both take input from the 
controller: the driver. The brakes, steering wheel and other controls 
represent the model: they take input from the controller (driver) and 
hand them off to the views (interior/exterior) for presentation.


That's from a web page that is suppose to explain MVC.

I bet if you took 50 people who didn't have a clue as to what MVC is - 
maybe 1 or 2 of them would after reading that.


Documentation and howto's, just like code, really need to go through 
real world testing to see if they make sense to people not already 
familiar with the topic.


Unfortunately that rarely happens.


I think you have it back asswards. People need to go through real world
development or innane examples and then someone needs ot tell them where
they went wrong. That's how it worked in university. We got an example
like the one above, then we were expected to apply the principle. Those
who undertood it right away got great marks on their assignment, those
who took a little longer didn't... but if they kept at it... till they
figured it out... they got a good mark on the exam. I don't understand
defeatism. Suck it up! There's a zillion examples on the web. Study
many, learn the generalism.


The problem is I can make a car analogy out of any type of programming 
design method.


Most of those who got it right away and got great marks did so NOT 
because of what they learned from the example, but because of what they 
already knew before they signed up for the class.


Thus, when the teacher sees some of his students understanding the 
concept, he becomes smug and arrogant and thinks he did something right 
and those who didn't get it have something wrong with them. The reality 
is he can't teach worth shit and those who understood it did so before 
they took his class, hence he didn't teach them anything.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Tips and Techniques

[Robert Cummings]

On Thu, 2009-03-19 at 16:27 -0700, Michael A. Peters wrote:
> Marc Christopher Hall wrote:
> > The following comment is not intended to be helpful
> > 
> > *smacks head on desk repeatedly...*
> > 
> > 
> > This comment is..
> > 
> > I would hazard to say that if you are unwilling or unable to grasp OOP, MVCs
> > and any decent framework that is necessary then maybe stepping back and
> > tackling only things you can grasp.
> 
> To be honest - one of the problems is that documentation that tries to 
> explain these concepts is often severely lacking, using extremely poor 
> analogies, and only make sense to people who already have an 
> understanding of the concept.
> 
> For example -
> 
> A car is a good real-world example of MVC. With a car you have two 
> views: the interior and the exterior. Both take input from the 
> controller: the driver. The brakes, steering wheel and other controls 
> represent the model: they take input from the controller (driver) and 
> hand them off to the views (interior/exterior) for presentation.
> 
> That's from a web page that is suppose to explain MVC.
> 
> I bet if you took 50 people who didn't have a clue as to what MVC is - 
> maybe 1 or 2 of them would after reading that.
> 
> Documentation and howto's, just like code, really need to go through 
> real world testing to see if they make sense to people not already 
> familiar with the topic.
> 
> Unfortunately that rarely happens.

I think you have it back asswards. People need to go through real world
development or innane examples and then someone needs ot tell them where
they went wrong. That's how it worked in university. We got an example
like the one above, then we were expected to apply the principle. Those
who undertood it right away got great marks on their assignment, those
who took a little longer didn't... but if they kept at it... till they
figured it out... they got a good mark on the exam. I don't understand
defeatism. Suck it up! There's a zillion examples on the web. Study
many, learn the generalism.

Cheers,
Rob.
-- 
http://www.interjinn.com
Application and Templating Framework for PHP


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Tips and Techniques

[Michael A. Peters]

Marc Christopher Hall wrote:

The following comment is not intended to be helpful

*smacks head on desk repeatedly...*


This comment is..

I would hazard to say that if you are unwilling or unable to grasp OOP, MVCs
and any decent framework that is necessary then maybe stepping back and
tackling only things you can grasp.


To be honest - one of the problems is that documentation that tries to 
explain these concepts is often severely lacking, using extremely poor 
analogies, and only make sense to people who already have an 
understanding of the concept.


For example -

A car is a good real-world example of MVC. With a car you have two 
views: the interior and the exterior. Both take input from the 
controller: the driver. The brakes, steering wheel and other controls 
represent the model: they take input from the controller (driver) and 
hand them off to the views (interior/exterior) for presentation.


That's from a web page that is suppose to explain MVC.

I bet if you took 50 people who didn't have a clue as to what MVC is - 
maybe 1 or 2 of them would after reading that.


Documentation and howto's, just like code, really need to go through 
real world testing to see if they make sense to people not already 
familiar with the topic.


Unfortunately that rarely happens.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Smarty Tips and Techniques

[Bob McConnell]

From: Bastien Koert
> Just 162 files? I don't mean to sound condescending but if the code
> is that much trouble, chuck it out and start over.

Not going to happen. There are too many other tasks in the backlog that
are more important and will bring in real money as opposed to just
making the developers' lives easier. In addition, the current
application has already passed the PCI Level 1 audit, has been deployed
and is now handling a thousand transactions per day. If I can slip the
changes in piecemeal with those other tasks, fine, but starting over is
not even an option.

All three products combined are processing more than 10K transactions
per day. That spells success as far as management is concerned. With a
long list of client requested enhancements already assembled, code
maintenance issues are not even open for discussion.

Bob McConnell

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Tips and Techniques

[Bastien Koert]

On Thu, Mar 19, 2009 at 12:36 PM, Bob McConnell  wrote:

> From: Shawn McKenzie
>  > Bob McConnell wrote:
> >> From: Virgilio Quilario
>  That looks nice, but how do I get to the point where I can
> understand
>  how to use it?
> 
>  I have also looked at the Smarty site , but
>  their documents assume significant experience in building and using
>  templates.
> 
>  Where can I find guidance or tutorials on how to do all of this,
>  starting with only a rudimentary knowledge of HTML and PHP. It
> would
> >> be
>  best if they also focused on procedural rather than object oriented
>  code.
> >>>
> >>> When I started learning smarty, I spent most of my time doing
> research
> >>> and that's really tiresome and it is so hard to find examples.
> >>> Experimented a lot and listed those what's possible, then applied
> them
> >>> to my projects.
> >>>
> >>> Now to make them handy I posted them to my site so i can have a look
> >>> whenever and wherever.
> >>>
> >>
> http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting-
> >> tips-and-techniques-to-make-templates-smarter.html
> >>> As a first step, maybe you should see the crash course at smarty
> >>> http://www.smarty.net/crashcourse.php
> >>
> >> Hi Virgil,
> >>
> >> After your last post here, I looked at your site, then the Smarty
> site.
> >> That was what triggered this question. Templates are a black art to
> me.
> >> I don't even know where to begin to understand them. Every reference
> I
> >> have looked at so far assumes that I already understand the MVC
> pattern,
> >> which is also one of the dark arts.
> >>
> >> Let me put it simply. I can't grok OO. I tried to do OOP for several
> >> years, but it simply does not make any sense to me. As a direct
> result,
> >> I don't understand the concept nor application of patterns. So how do
> I
> >> figure out how to use templates without having to absorb those first?
> >> Can I learn enough this way to determine if a site can be converted
> from
> >> the current state (PHP and XHTML spaghetti) into templates and begin
> >> that transformation?
> >
> > You don't need OOP to use templates.  Smarty is OOP. but there are
> some
> > lighter faster template solutions, as well as just creating your own
> > templates  that you either parse and replace vars in or just use PHP
> > code.  As long as you keep the PHP in your templates display oriented
> > and not business/app logic based then it should be a nice solution.
> >
> > You might also look at a framework (codeignitor, cakephp) and go
> through
> > their tutorial, though these are undoubtedly MVC/OOP, it may make more
> > sense once you start building something with it.
>
> Well, I installed CodeIgniter on one of my home servers last night, but
> have not yet started through the manual. That will be an interesting
> experiment. I am hoping to create a simple recipe management system
> there, similar to ReciPants, but in PHP.
>
> At work the problem is more basic; 162 files of interleaved database
> access, business logic and presentation, all written by a civil
> engineering student with no software training at all. He has moved on,
> but five of us working on three products are now dealing with the mess
> he left behind.
>
> Thank you,
>
> Bob McConnell
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Just 162 files? I don't mean to sound condescending but if the code is that
much trouble, chuck it out and start over. Build it properly by separating
out the db interaction stuff ( and there are great patterns to use there as
well like Active Record or work with an ORM layer like propel or doctrine ).
Then separate out the presentation layer, and define a transport to that
layer from the business logic layer. I like XML for this, passing it to XSLT
for client side transformations into html. Then the DB passes to the
business layer, which does its stuff and then passes the results to the
presentation layer. And the same in reverse, the presentation layer never
talks to the db layer directly.

Creating that separation should make the whole maintenance issue better.
Parts that need to be shared can be copied across to the other applications
so that each app lives in isolation. If that is not possible, the consider
breaking the shared bits into smaller pieces to limit the exposure to
potential issues when you have to make changes. PCI is a pain in the ass and
the rules that govern that make things very difficult, though I can see why
it all needs to be there.

The application I support (classic ASP) comprises 149 Mb of code in some
1500 + files scattered across some 50+ folders each with their own db access
code. Nightmare isn't the word for it. It uses some 160+ DB tables as well.
Rebuilding it is a task that I am looking forward to and am definitely using
the MVC pattern with OOP to some extent. I am looking at codeig

RE: [PHP] Smarty Tips and Techniques

[Robert Cummings]

On Thu, 2009-03-19 at 12:14 -0400, Bob McConnell wrote:
> From: Bastien Koert
> > On Thu, Mar 19, 2009 at 11:06 AM, Bob McConnell  wrote:
> > 
> > From: Virgilio Quilario
> > >> That looks nice, but how do I get to the point where I can
> understand
> > >> how to use it?
> > >>
> > >> I have also looked at the Smarty site
> , but
> > >> their documents assume significant experience in building and
> using
> > >> templates.
> > >>
> > >> Where can I find guidance or tutorials on how to do all of
> this,
> > >> starting with only a rudimentary knowledge of HTML and PHP.
> It would
> > be
> > >> best if they also focused on procedural rather than object
> oriented
> > >> code.
> > >
> > >
> > > When I started learning smarty, I spent most of my time doing
> research
> > > and that's really tiresome and it is so hard to find examples.
> > > Experimented a lot and listed those what's possible, then
> applied them
> > > to my projects.
> > >
> > > Now to make them handy I posted them to my site so i can have
> a look
> > > whenever and wherever.
> > >
> >
> http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting-
> > tips-and-techniques-to-make-templates-smarter.html
>  -tips-and-techniques-to-make-templates-smarter.html> 
> > >
> > > As a first step, maybe you should see the crash course at
> smarty
> > > http://www.smarty.net/crashcourse.php
> > 
> > Hi Virgil,
> > 
> > After your last post here, I looked at your site, then the
> Smarty site.
> > That was what triggered this question. Templates are a black art
> to me.
> > I don't even know where to begin to understand them. Every
> reference I
> > have looked at so far assumes that I already understand the MVC
> pattern,
> > which is also one of the dark arts.
> > 
> > Let me put it simply. I can't grok OO. I tried to do OOP for
> several
> > years, but it simply does not make any sense to me. As a direct
> result,
> > I don't understand the concept nor application of patterns. So
> how do I
> > figure out how to use templates without having to absorb those
> first?
> > Can I learn enough this way to determine if a site can be
> converted from
> > the current state (PHP and XHTML spaghetti) into templates and
> begin
> > that transformation?
> > 
> > Bob,
> >  
> > You really would need to learn those concepts first OOP / MVC. There
> is
> >  a learning curve, but you really don't need OOP to be able to do an
> MVC
> >  style application, but it does make the code neater. 
> >  
> > One of the books that really helped me grok OOP is Head First
> OOP...another
> > is Martin Fowlers Patterns of Enterprise Architecture. 
> > 
> > The MVC pattern is explained well in a number of places, but worth
> >  checking out are both the cakephp framework site and the codeingniter
> site.
> >  
> > You'll find that there are people from both camps here, pure OOP and
> other
> > just as happy with procedural coding styles. Many use both, using
> objects
> > to handle common tasks like DB interaction or filesystem processes.
> 
> Yes, I have to deal with both camps here as well. Of five developers
> doing PHP at the moment, two are primarily using OOP. But I spent 3.5
> years as part of a team developing MS-Windows services in C++. After all
> that time, I was only able to write basic functions for others to
> convert into methods or classes. I could eventually find my way around
> in some of those classes, but it seemed that every time I figured out
> what was where, somebody "refactored" a major component and I had to
> start all over again. All I saw was a lot of unnecessary overhead and
> obfuscation which made little sense in the long run and slowed down both
> the development and the application. The result was a handful of DLLs
> that are shared between several products, and each time anything is
> changed in one of them, every product needs to be retested to make sure
> nothing got broke and some have to be recertified for PCI-DSS as well.
> 
> So you are telling me that I can forget about trying to use templates.
> Since I can not understand OOP, there is no chance I will be able to use
> them.
> 
> Just knowing that will probably save me several weeks of frustration.

OOP for those having trouble:



name;
}

function setName( $name )
{
$this->name = $name;
}
}

$person = new DbPerson( 1234 );
$person->setName( 'Bob' );
echo $person->getName();

?>

So from the above you can see that the two translate quite cleanly
between one another. We merely change passing the structure to function
to a case of calling the functions on the structure itself. Now, where
does OOP make more sense?



fireman = load_stuff_for_fireman_from_db();
}

function getStationId()

Re: [PHP] Smarty Tips and Techniques

[Shawn McKenzie]

Bob McConnell wrote:
> From: Virgilio Quilario
>>> That looks nice, but how do I get to the point where I can understand
>>> how to use it?
>>>
>>> I have also looked at the Smarty site , but
>>> their documents assume significant experience in building and using
>>> templates.
>>>
>>> Where can I find guidance or tutorials on how to do all of this,
>>> starting with only a rudimentary knowledge of HTML and PHP. It would
> be
>>> best if they also focused on procedural rather than object oriented
>>> code.
>>
>> When I started learning smarty, I spent most of my time doing research
>> and that's really tiresome and it is so hard to find examples.
>> Experimented a lot and listed those what's possible, then applied them
>> to my projects.
>>
>> Now to make them handy I posted them to my site so i can have a look
>> whenever and wherever.
>>
> http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting-
> tips-and-techniques-to-make-templates-smarter.html
>> As a first step, maybe you should see the crash course at smarty
>> http://www.smarty.net/crashcourse.php
> 
> Hi Virgil,
> 
> After your last post here, I looked at your site, then the Smarty site.
> That was what triggered this question. Templates are a black art to me.
> I don't even know where to begin to understand them. Every reference I
> have looked at so far assumes that I already understand the MVC pattern,
> which is also one of the dark arts.
> 
> Let me put it simply. I can't grok OO. I tried to do OOP for several
> years, but it simply does not make any sense to me. As a direct result,
> I don't understand the concept nor application of patterns. So how do I
> figure out how to use templates without having to absorb those first?
> Can I learn enough this way to determine if a site can be converted from
> the current state (PHP and XHTML spaghetti) into templates and begin
> that transformation?
> 
> Thank you,
> 
> Bob McConnell

You don't need OOP to use templates.  Smarty is OOP. but there are some
lighter faster template solutions, as well as just creating your own
templates  that you either parse and replace vars in or just use PHP
code.  As long as you keep the PHP in your templates display oriented
and not business/app logic based then it should be a nice solution.

You might also look at a framework (codeignitor, cakephp) and go through
their tutorial, though these are undoubtedly MVC/OOP, it may make more
sense once you start building something with it.

-- 
Thanks!
-Shawn
http://www.spidean.com

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Smarty Tips and Techniques

[Bob McConnell]

From: Shawn McKenzie
> Bob McConnell wrote:
>> From: Virgilio Quilario
 That looks nice, but how do I get to the point where I can
understand
 how to use it?

 I have also looked at the Smarty site , but
 their documents assume significant experience in building and using
 templates.

 Where can I find guidance or tutorials on how to do all of this,
 starting with only a rudimentary knowledge of HTML and PHP. It
would
>> be
 best if they also focused on procedural rather than object oriented
 code.
>>>
>>> When I started learning smarty, I spent most of my time doing
research
>>> and that's really tiresome and it is so hard to find examples.
>>> Experimented a lot and listed those what's possible, then applied
them
>>> to my projects.
>>>
>>> Now to make them handy I posted them to my site so i can have a look
>>> whenever and wherever.
>>>
>>
http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting-
>> tips-and-techniques-to-make-templates-smarter.html
>>> As a first step, maybe you should see the crash course at smarty
>>> http://www.smarty.net/crashcourse.php
>> 
>> Hi Virgil,
>> 
>> After your last post here, I looked at your site, then the Smarty
site.
>> That was what triggered this question. Templates are a black art to
me.
>> I don't even know where to begin to understand them. Every reference
I
>> have looked at so far assumes that I already understand the MVC
pattern,
>> which is also one of the dark arts.
>> 
>> Let me put it simply. I can't grok OO. I tried to do OOP for several
>> years, but it simply does not make any sense to me. As a direct
result,
>> I don't understand the concept nor application of patterns. So how do
I
>> figure out how to use templates without having to absorb those first?
>> Can I learn enough this way to determine if a site can be converted
from
>> the current state (PHP and XHTML spaghetti) into templates and begin
>> that transformation?
> 
> You don't need OOP to use templates.  Smarty is OOP. but there are
some
> lighter faster template solutions, as well as just creating your own
> templates  that you either parse and replace vars in or just use PHP
> code.  As long as you keep the PHP in your templates display oriented
> and not business/app logic based then it should be a nice solution.
> 
> You might also look at a framework (codeignitor, cakephp) and go
through
> their tutorial, though these are undoubtedly MVC/OOP, it may make more
> sense once you start building something with it.

Well, I installed CodeIgniter on one of my home servers last night, but
have not yet started through the manual. That will be an interesting
experiment. I am hoping to create a simple recipe management system
there, similar to ReciPants, but in PHP.

At work the problem is more basic; 162 files of interleaved database
access, business logic and presentation, all written by a civil
engineering student with no software training at all. He has moved on,
but five of us working on three products are now dealing with the mess
he left behind.

Thank you,

Bob McConnell

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Smarty Tips and Techniques

[Bob McConnell]

From: Bastien Koert
> On Thu, Mar 19, 2009 at 11:06 AM, Bob McConnell  wrote:
> 
>   From: Virgilio Quilario
>   >> That looks nice, but how do I get to the point where I can
understand
>   >> how to use it?
>   >>
>   >> I have also looked at the Smarty site
, but
>   >> their documents assume significant experience in building and
using
>   >> templates.
>   >>
>   >> Where can I find guidance or tutorials on how to do all of
this,
>   >> starting with only a rudimentary knowledge of HTML and PHP.
It would
>   be
>   >> best if they also focused on procedural rather than object
oriented
>   >> code.
>   >
>   >
>   > When I started learning smarty, I spent most of my time doing
research
>   > and that's really tiresome and it is so hard to find examples.
>   > Experimented a lot and listed those what's possible, then
applied them
>   > to my projects.
>   >
>   > Now to make them handy I posted them to my site so i can have
a look
>   > whenever and wherever.
>   >
>
http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting-
>   tips-and-techniques-to-make-templates-smarter.html
 
>   >
>   > As a first step, maybe you should see the crash course at
smarty
>   > http://www.smarty.net/crashcourse.php
>   
>   Hi Virgil,
>   
>   After your last post here, I looked at your site, then the
Smarty site.
>   That was what triggered this question. Templates are a black art
to me.
>   I don't even know where to begin to understand them. Every
reference I
>   have looked at so far assumes that I already understand the MVC
pattern,
>   which is also one of the dark arts.
>   
>   Let me put it simply. I can't grok OO. I tried to do OOP for
several
>   years, but it simply does not make any sense to me. As a direct
result,
>   I don't understand the concept nor application of patterns. So
how do I
>   figure out how to use templates without having to absorb those
first?
>   Can I learn enough this way to determine if a site can be
converted from
>   the current state (PHP and XHTML spaghetti) into templates and
begin
>   that transformation?
> 
> Bob,
>  
> You really would need to learn those concepts first OOP / MVC. There
is
>  a learning curve, but you really don't need OOP to be able to do an
MVC
>  style application, but it does make the code neater. 
>  
> One of the books that really helped me grok OOP is Head First
OOP...another
> is Martin Fowlers Patterns of Enterprise Architecture. 
> 
> The MVC pattern is explained well in a number of places, but worth
>  checking out are both the cakephp framework site and the codeingniter
site.
>  
> You'll find that there are people from both camps here, pure OOP and
other
> just as happy with procedural coding styles. Many use both, using
objects
> to handle common tasks like DB interaction or filesystem processes.

Yes, I have to deal with both camps here as well. Of five developers
doing PHP at the moment, two are primarily using OOP. But I spent 3.5
years as part of a team developing MS-Windows services in C++. After all
that time, I was only able to write basic functions for others to
convert into methods or classes. I could eventually find my way around
in some of those classes, but it seemed that every time I figured out
what was where, somebody "refactored" a major component and I had to
start all over again. All I saw was a lot of unnecessary overhead and
obfuscation which made little sense in the long run and slowed down both
the development and the application. The result was a handful of DLLs
that are shared between several products, and each time anything is
changed in one of them, every product needs to be retested to make sure
nothing got broke and some have to be recertified for PCI-DSS as well.

So you are telling me that I can forget about trying to use templates.
Since I can not understand OOP, there is no chance I will be able to use
them.

Just knowing that will probably save me several weeks of frustration.

Thank you,

Bob McConnell

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Smarty Tips and Techniques

[Marc Christopher Hall]

The following comment is not intended to be helpful

*smacks head on desk repeatedly...*


This comment is..

I would hazard to say that if you are unwilling or unable to grasp OOP, MVCs
and any decent framework that is necessary then maybe stepping back and
tackling only things you can grasp. I do not mean to come across
condescending and I apologize if I have anyway; however, I do not see an
alternative solution for you. Stick to what you are comfortable with and
think about outsourcing the OOP to someone you can trust to write decent
code.





-Original Message-
From: Bob McConnell [mailto:r...@cbord.com] 
Sent: Thursday, March 19, 2009 11:06 AM
To: Virgilio Quilario
Cc: php-general@lists.php.net
Subject: RE: [PHP] Smarty Tips and Techniques

From: Virgilio Quilario
>> That looks nice, but how do I get to the point where I can understand
>> how to use it?
>>
>> I have also looked at the Smarty site <http://www.smarty.net/>, but
>> their documents assume significant experience in building and using
>> templates.
>>
>> Where can I find guidance or tutorials on how to do all of this,
>> starting with only a rudimentary knowledge of HTML and PHP. It would
be
>> best if they also focused on procedural rather than object oriented
>> code.
> 
> 
> When I started learning smarty, I spent most of my time doing research
> and that's really tiresome and it is so hard to find examples.
> Experimented a lot and listed those what's possible, then applied them
> to my projects.
> 
> Now to make them handy I posted them to my site so i can have a look
> whenever and wherever.
>
http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting-
tips-and-techniques-to-make-templates-smarter.html
> 
> As a first step, maybe you should see the crash course at smarty
> http://www.smarty.net/crashcourse.php

Hi Virgil,

After your last post here, I looked at your site, then the Smarty site.
That was what triggered this question. Templates are a black art to me.
I don't even know where to begin to understand them. Every reference I
have looked at so far assumes that I already understand the MVC pattern,
which is also one of the dark arts.

Let me put it simply. I can't grok OO. I tried to do OOP for several
years, but it simply does not make any sense to me. As a direct result,
I don't understand the concept nor application of patterns. So how do I
figure out how to use templates without having to absorb those first?
Can I learn enough this way to determine if a site can be converted from
the current state (PHP and XHTML spaghetti) into templates and begin
that transformation?

Thank you,

Bob McConnell

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


__ Information from ESET Smart Security, version of virus signature
database 3948 (20090319) __

The message was checked by ESET Smart Security.

http://www.eset.com


 

__ Information from ESET Smart Security, version of virus signature
database 3948 (20090319) __

The message was checked by ESET Smart Security.

http://www.eset.com
 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Tips and Techniques

[Bastien Koert]

On Thu, Mar 19, 2009 at 11:06 AM, Bob McConnell  wrote:

> From: Virgilio Quilario
> >> That looks nice, but how do I get to the point where I can understand
> >> how to use it?
> >>
> >> I have also looked at the Smarty site , but
> >> their documents assume significant experience in building and using
> >> templates.
> >>
> >> Where can I find guidance or tutorials on how to do all of this,
> >> starting with only a rudimentary knowledge of HTML and PHP. It would
> be
> >> best if they also focused on procedural rather than object oriented
> >> code.
> >
> >
> > When I started learning smarty, I spent most of my time doing research
> > and that's really tiresome and it is so hard to find examples.
> > Experimented a lot and listed those what's possible, then applied them
> > to my projects.
> >
> > Now to make them handy I posted them to my site so i can have a look
> > whenever and wherever.
> >
> http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting-
> tips-and-techniques-to-make-templates-smarter.html
> >
> > As a first step, maybe you should see the crash course at smarty
> > http://www.smarty.net/crashcourse.php
>
> Hi Virgil,
>
> After your last post here, I looked at your site, then the Smarty site.
> That was what triggered this question. Templates are a black art to me.
> I don't even know where to begin to understand them. Every reference I
> have looked at so far assumes that I already understand the MVC pattern,
> which is also one of the dark arts.
>
> Let me put it simply. I can't grok OO. I tried to do OOP for several
> years, but it simply does not make any sense to me. As a direct result,
> I don't understand the concept nor application of patterns. So how do I
> figure out how to use templates without having to absorb those first?
> Can I learn enough this way to determine if a site can be converted from
> the current state (PHP and XHTML spaghetti) into templates and begin
> that transformation?
>
> Thank you,
>
> Bob McConnell
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Bob,

You really would need to learn those concepts first OOP / MVC. There is a
learning curve, but you really don't need OOP to be able to do an MVC style
application, but it does make the code neater.

One of the books that really helped me grok OOP is Head First OOP...another
is Martin Fowlers Patterns of Enterprise Architecture.

The MVC pattern is explained well in a number of places, but worth checking
out are both the cakephp framework site and the codeingniter site.

You'll find that there are people from both camps here, pure OOP and other
just as happy with procedural coding styles. Many use both, using objects to
handle common tasks like DB interaction or filesystem processes.

-- 

Bastien

Cat, the other other white meat

RE: [PHP] Smarty Tips and Techniques

[Bob McConnell]

From: Virgilio Quilario
>> That looks nice, but how do I get to the point where I can understand
>> how to use it?
>>
>> I have also looked at the Smarty site , but
>> their documents assume significant experience in building and using
>> templates.
>>
>> Where can I find guidance or tutorials on how to do all of this,
>> starting with only a rudimentary knowledge of HTML and PHP. It would
be
>> best if they also focused on procedural rather than object oriented
>> code.
> 
> 
> When I started learning smarty, I spent most of my time doing research
> and that's really tiresome and it is so hard to find examples.
> Experimented a lot and listed those what's possible, then applied them
> to my projects.
> 
> Now to make them handy I posted them to my site so i can have a look
> whenever and wherever.
>
http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting-
tips-and-techniques-to-make-templates-smarter.html
> 
> As a first step, maybe you should see the crash course at smarty
> http://www.smarty.net/crashcourse.php

Hi Virgil,

After your last post here, I looked at your site, then the Smarty site.
That was what triggered this question. Templates are a black art to me.
I don't even know where to begin to understand them. Every reference I
have looked at so far assumes that I already understand the MVC pattern,
which is also one of the dark arts.

Let me put it simply. I can't grok OO. I tried to do OOP for several
years, but it simply does not make any sense to me. As a direct result,
I don't understand the concept nor application of patterns. So how do I
figure out how to use templates without having to absorb those first?
Can I learn enough this way to determine if a site can be converted from
the current state (PHP and XHTML spaghetti) into templates and begin
that transformation?

Thank you,

Bob McConnell

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Tips and Techniques

[Virgilio Quilario]

> That looks nice, but how do I get to the point where I can understand
> how to use it?
>
> I have also looked at the Smarty site , but
> their documents assume significant experience in building and using
> templates.
>
> Where can I find guidance or tutorials on how to do all of this,
> starting with only a rudimentary knowledge of HTML and PHP. It would be
> best if they also focused on procedural rather than object oriented
> code.
>
> Bob McConnell
>

When I started learning smarty, I spent most of my time doing research
and that's really tiresome and it is so hard to find examples.
Experimented a lot and listed those what's possible, then applied them
to my projects.

Now to make them handy I posted them to my site so i can have a look
whenever and wherever.
http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting-tips-and-techniques-to-make-templates-smarter.html

As a first step, maybe you should see the crash course at smarty
http://www.smarty.net/crashcourse.php

Virgil
http://www.jampmark.com

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Tips and Techniques

[Thodoris]

That looks nice, but how do I get to the point where I can understand
how to use it?

I have also looked at the Smarty site , but
their documents assume significant experience in building and using
templates.

Where can I find guidance or tutorials on how to do all of this,
starting with only a rudimentary knowledge of HTML and PHP. It would be
best if they also focused on procedural rather than object oriented
code.

Bob McConnell

-Original Message-
From: Virgilio Quilario [mailto:virgilio.quila...@gmail.com] 
Sent: Wednesday, March 18, 2009 10:36 AM

To: php-general@lists.php.net
Subject: [PHP] Smarty Tips and Techniques

Hi list,

Just wanna share my collection of Smarty scripting tips and techniques.
Smarty is a template engine for PHP that you can use to separate data
and logic from web design.
This way programmers can work on the php scripts and designers can
work on the templates for the same web site.

Here is the link:
http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting-
tips-and-techniques-to-make-templates-smarter.html

Hope you find it useful.

Virgil

  


I have stared using smarty myself in a recent project I am still making 
and I'll have to say that it has its virtues.


Look at a simple example in the smarty's site and use the manual for any 
questions. You will probably find some stuff by googling.


The templates (simply put) are actually html-like that has some php 
variables inside you may assign before displaying the actual template.

This way you customize the template to output what you need.

Above that you may start using the statements to automatically build 
forms, tables etc


I like the fact that there is a cache and that the templates get 
"compiled" which make them faster to process.


Nevertheless you need time to get familiar with the smarty way of 
thinking as with all frameworks and template engines you need to use.


--
Thodoris


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Smarty Tips and Techniques

[Bob McConnell]

That looks nice, but how do I get to the point where I can understand
how to use it?

I have also looked at the Smarty site , but
their documents assume significant experience in building and using
templates.

Where can I find guidance or tutorials on how to do all of this,
starting with only a rudimentary knowledge of HTML and PHP. It would be
best if they also focused on procedural rather than object oriented
code.

Bob McConnell

-Original Message-
From: Virgilio Quilario [mailto:virgilio.quila...@gmail.com] 
Sent: Wednesday, March 18, 2009 10:36 AM
To: php-general@lists.php.net
Subject: [PHP] Smarty Tips and Techniques

Hi list,

Just wanna share my collection of Smarty scripting tips and techniques.
Smarty is a template engine for PHP that you can use to separate data
and logic from web design.
This way programmers can work on the php scripts and designers can
work on the templates for the same web site.

Here is the link:
http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting-
tips-and-techniques-to-make-templates-smarter.html

Hope you find it useful.

Virgil

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Question

[Stut]

Shahrzad wrote:

IRIran.netHi,
I want to replace a php variable with a javascript variable inside 

Re: [PHP] Smarty template for parent-child form

[Chad Robinson]

Man-wai Chang wrote:
> Is there a template that presents a parent-child
> forms, for example, an invoice object which has a header(invoice no,
> date, customer code, invoice total) and multiple items (item no, item
> name, quantity, price, amount)?
>   
Go to http://smarty.php.net/manual/en/language.function.foreach.php

What you do is assign the items to an array called, say, items. Then you
use "foreach" in the template to iterate the array, just like you would
in PHP itself. Example 7-8 (Contacts) is pretty close to what you're doing.

Regards,
Chad

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Website down?

[Martin Marques]

On Tue, 27 Mar 2007, Mario Guenterberg wrote:


Hi...

I try to connect in the last hours and the results are timeouts.


Excelent connection here.

--
 21:50:04 up 2 days,  9:07,  0 users,  load average: 0.92, 0.37, 0.18
-
Lic. Martín Marqués |   SELECT 'mmarques' ||
Centro de Telemática|   '@' || 'unl.edu.ar';
Universidad Nacional|   DBA, Programador,
del Litoral |   Administrador
-
-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] [Smarty]How smarty name its combiled file?

[Edward Kay]

How about sending this to the Smarty list?
http://smarty.php.net/resources.php?category=7

Edward

> -Original Message-
> From: John.H [mailto:[EMAIL PROTECTED]
> Sent: 23 November 2006 11:55
> To: php-general
> Subject: [PHP] [Smarty]How smarty name its combiled file?
> 
> 
> It just like "%%58^588^588C8934%%second.html.php".
> How does this filename be created?
> 
> 

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty error

[John Nichel]

Nirmalya Lahiri wrote:

Dear all,
  I wrote this script using Smarty template,which gives a syntax error ..
 
 syntax error: unrecognized tag:  (Smarty_Compiler.class.php, line 436)
 
 
 I wrote a javascript block in template file,where I use '{'. This '{' acctually shows the problem. How can I solve this problem?




http://smarty.php.net/resources.php?category=7

--
John C. Nichel IV
Programmer/System Admin (ÜberGeek)
Dot Com Holdings of Buffalo
716.856.9675
[EMAIL PROTECTED]

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty error

[Nirmalya Lahiri]

Dear all,
  I solved the problem using {literal}{/literal} tag. Thanks every one, who 
gives me tips to solve the error.
 
 --Nirmalya
 

Nirmalya Lahiri <[EMAIL PROTECTED]> wrote: Dear all,
  I wrote this script using Smarty template,which gives a syntax error ..
 
 syntax error: unrecognized tag:  (Smarty_Compiler.class.php, line 436)
 
 
 I wrote a javascript block in template file,where I use '{'. This '{' 
acctually shows the problem. How can I solve this problem?
 
 --Nirmalya Lahiri
 
  
-
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ 
countries) for 2¢/min or less.


-
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.

Re: [PHP] Smarty Templates?

[Jochem Maas]

starting a new topic by replying to an existing thread is
bad form - we know how much work it is to click on the 'new mail'
button and fill in an address but please make the effort (it's in your
interest as well!).

with regard to Smarty why not try searching for existing writing on the subject?

e.g. http://www.google.com/search?q=pros+and+cons+of+Smarty+template+engine

as to opinion :: the only one that counts is yours - just make sure
you take the time to form it based on something more than 3rd hand waffle :-)

here is my waffle:

PRO:
1. well maintained/developed
2. decent coders involved
3. large/active userbase
4. helpful mailing list
5. lots of docs
6. lots of 'extension' (big word for 'user contributed stuff')
7. proven in production
8. free (as in cost)

CON:
1. overkill for some projects
2. enforces/emphasises/favors a particular design workflow/strategy
3. caching/compile funcrtionality is unclear (I can't figure out how
   to implement it in 'complex' datadriven applications - like for 
instance
   the frontend to a custom webshop system)
4. ability to use php objects in the templates is restricted somwhat
  (much more relevant to usage with php5 objects - e.g. dereferenced 
object method syntax)


now go and read the web, download Smarty and make yuour own mind up.


R. Van Tassel wrote:

I'm contemplating using Smarty Templates for a website and was wondering
what opinions on them, pro or con, may be.

Thanks in advance for all your help.

-Roy



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: PHP & smarty - nested queries and arrays

[mikespook]

Warning: Smarty error: unable to read resource: "welcome/Object.tpl" in
/usr/local/lib/php/Smarty/Smarty.class.php on line 1088

You should check your Smarty`s template_dir. Put the templates into the 
template_dir, then the Smarty will find them.

Like this:

$smarty = new Smarty();
$smarty->template_dir = '/home/mike/tpl/';
$smarty->display('test.tpl');

You should put the file 'test.tpl' into dir '/home/mike/tpl'.

"Amanda Hemmerich" <[EMAIL PROTECTED]> 
??:[EMAIL PROTECTED]
> Hello!
>
> I'm using PHP and Smarty to try to build an array of arrays using the 
> results from nested queries.  I am just learning about nested arrays, and 
> I'm not sure what I'm doing wrong.
>
> I am hoping someone can give me a hint as to what I am doing wrong.  I 
> looked on php.net, but still couldn't figure it out.
>
> If I remove the PHP foreach loop, it works fine, except, of course, no sub 
> projects show up.   The error must be in there, but I'm just not seeing 
> it.
>
> I get the following error with the code below:
> Warning: Smarty error: unable to read resource: "welcome/Object.tpl" 
> in /usr/local/lib/php/Smarty/Smarty.class.php on line 1088
>   PHP STUFF
> $query ="SELECT * FROM projects WHERE parent_project_id is NULL OR 
> parent_project_id = ''";
>
> $projects = $db->getAssoc($query, DB_FETCHMODE_ASSOC);
>
> foreach ($projects as $key => $project) {
>  $query ="SELECT * FROM projects WHERE parent_project_id = 
> $projects[$key]['project_id']";
>  $sub = $db->getAssoc($query, DB_FETCHMODE_ASSOC);
>  $projects[$key]['subs'] = $sub;
> }
> $tpl->assign('projects', $projects);
>   SMARTY STUFF
> {foreach from=$projects item='entry'}
>{$entry.short_name}
>
>{foreach from=$entry.subs item='sub'}
>{$sub.short_name}
>{foreachelse}
>No subs for this project
>{/foreach}
>
> {foreachelse}
>No projects found
> {/foreach}
>
> Can anyone point me in the right direction?
>
> Thanks,
> Amanda 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: PHP & smarty - nested queries and arrays

[Matthew Weier O'Phinney]

* Amanda Hemmerich <[EMAIL PROTECTED]>:
> I'm using PHP and Smarty to try to build an array of arrays using the 
> results from nested queries.  I am just learning about nested arrays, 
> and I'm not sure what I'm doing wrong.
>  
> I am hoping someone can give me a hint as to what I am doing wrong.  I 
> looked on php.net, but still couldn't figure it out.
>  
> If I remove the PHP foreach loop, it works fine, except, of course, no 
> sub projects show up.   The error must be in there, but I'm just not 
> seeing it.
>  
> I get the following error with the code below:
>  
> Warning: Smarty error: unable to read resource: "welcome/Object.tpl" in 
> /usr/local/lib/php/Smarty/Smarty.class.php on line 1088

Actually, this error indicates it either cannot find or open the
template file. make sure you have a 'welcome' directory in your
templates directory, and an Object.tpl file within -- and that they have
permissions such that the web server can open them.

-- 
Matthew Weier O'Phinney
Zend Certified Engineer
http://weierophinney.net/matthew/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SMarty and commercial php (a little 0t)

[M Saleh EG]

I'd recommand you to use the HTML_TEMPLATE_IT. It's a PEAR class for 
templating; I've personaly worked on it for building skinnable applications 
in which users and admins can change the look of the pages. Bottom line, 
it's a PEAR library/extension so no hastle since most of the hosts include 
it in their PHP installations. This template does alot of handy jobs such as 
nested blocks templating and rendering. However, it does not have the bells 
and the whistles of Smarty. Simply it does the job, it's efficient, and very 
elegant since your HTML templates would have only 2 extra stuff. One which 
is the HTML style comments to define and close blocks and the, Two which is 
the variable names to be placed whithin curly braces. So templating does not 
realy have a language in IT it's just a ditributed method of writing HTML 
and feeding data which forms another Tier in your application not another 
Application by itself.
 Benefits you'll get by using this PEAR library/extension is that you 
wouldnt need to tutor the designers on how to use a procedural markup 
templating language hence more flexibility and shorter learning curve. And 
plus it does not need no configuration and you could write your own nice 
wrapper classes to do special things for you, such as rendering pages 
templates, or blockwise template files with predefined variable to be 
inserted in the template files simple as that. e.g. you could write a 
function or a class method to route template files and then only pass them 
an array and the function would do the whole thing from rendering to 
displaying. especialy if you use the Web Standards and Semantic Design 
skinning would mean only switching CSSs and slight changes in your 
structural markup(template files).
 Note: If by any change your ISP/Host does not have the PEAR package 
installed you could just put it in a directory and simply append it to your
include_dir directive so that you could include/require the class file (only 
1 file is the whole package) directly w/o routing to its location.
 I'd honestly never implement Smarty for an application I'd work alone on 
and then give it up to designers I'd use Smarty while working with team 
mates of the same range of understanding of the Web Dev/ Design in a team 
environment for better performance and that's only if the application 
screens are more than 100 and the administration. 
 HTH.
 M.Saleh.E.G
97150-4779817

Re: [PHP] SMarty and commercial php (a little 0t)

[Rory Browne]

> Yep, left myself quite open there...should have been more specific.
> I will not write a templating library myself because there are so many
> out there,
> it would be a learning experience of course but other than that I think it
> would be
> rarely needed.
> I meant bundling it along with the rest of the scripts, (which would add
> around 500kb to the
> size) and then giving instructions on how to do a basic configuration for
> smarty.
I've never done it personally, but if this is for one specific client,
isn't 500k pretty much insignificant? If it's a problem though,
perhaps you could use a smaller template system, that maybe required
less configuration. Having that said, I've never used Smarty so I
don't know what configuration is involved. Perhaps an auto-config
script could be made?

> 
> 
> 
> > > Searching google I found this very nice place discussing PHP templating
> > (you
> > > might also want to read up on how many there are!)
> > > http://www.sitepoint.com/forums/showthread.php?t=123769&page=1&pp=25
> > > but no discussion of including any of these with commercial software for
> > the
> > > client to setup and their results.
> >
> > Smarty is licensed under the LGPL.
> > I've never read the LGPL, but
> > TTBOMK that means you can use it in commercial/propriatory software,
> > which I'm
> > assuming is what you're refering to.
> 
> Nope, sorry, I should have been more specific here too.
> I meant what I said above...nobody has discussed what experience they have
> had if they
> bundled smarty along with their scripts and then told the client how to
> configure smarty
> or if the clients had any problem configuring smarty etc.
> 
> Cheers,
> Ryan
> 
> 
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 5/20/2005
> 
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SMarty and commercial php (a little 0t)

[Ryan A]

Hey,

> > I was wondering if its a good idea to template via smarty and include
> smarty
> > with my code?
> > also instructions to setup smarty when setting up the application i
> made?
>
> Good idea compared to what? Compared to a different templating
> library, compared to writing your own templating library, or compared
> to having them download/install smarty themselves as a dependency?

Yep, left myself quite open there...should have been more specific.
I will not write a templating library myself because there are so many
out there,
it would be a learning experience of course but other than that I think it
would be
rarely needed.
I meant bundling it along with the rest of the scripts, (which would add
around 500kb to the
size) and then giving instructions on how to do a basic configuration for
smarty.



> > Searching google I found this very nice place discussing PHP templating
> (you
> > might also want to read up on how many there are!)
> > http://www.sitepoint.com/forums/showthread.php?t=123769&page=1&pp=25
> > but no discussion of including any of these with commercial software for
> the
> > client to setup and their results.
>
> Smarty is licensed under the LGPL.
> I've never read the LGPL, but
> TTBOMK that means you can use it in commercial/propriatory software,
> which I'm
> assuming is what you're refering to.

Nope, sorry, I should have been more specific here too.
I meant what I said above...nobody has discussed what experience they have
had if they
bundled smarty along with their scripts and then told the client how to
configure smarty
or if the clients had any problem configuring smarty etc.

Cheers,
Ryan



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 5/20/2005

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SMarty and commercial php (a little 0t)

[Rory Browne]

> I was wondering if its a good idea to template via smarty and include smarty
> with my code?
> also instructions to setup smarty when setting up the application i made?

Good idea compared to what? Compared to a different templating
library, compared to writing your own templating library, or compared
to having them download/install smarty themselves as a dependency?


> Searching google I found this very nice place discussing PHP templating (you
> might also want to read up on how many there are!)
> http://www.sitepoint.com/forums/showthread.php?t=123769&page=1&pp=25
> but no discussion of including any of these with commercial software for the
> client to setup and their results.

Smarty is licensed under the LGPL. I've never read the LGPL, but
TTBOMK that means you can use it in commercial/propriatory software,
which I'm assuming is what you're refering to.

> 
> Thanks,
> Ryan
> 
> 
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 5/20/2005
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty and db

[John Holmes]

Amanda Hemmerich wrote:
ANyway, I need to change the code so that, when there are no row returned
by the database, a message is displayed saying, "There are no events
scheduled." or what have you.
[snip]
(in the PHP page)
$events = $db->getAll($sql_events, DB_FETCHMODE_ASSOC);
$tpl->assign("events",$events);
(in the template page)
{section name=id loop=$events}


{$events[id].type}: {$events[id].date|date_format:"%B
%e, %Y"}, {$events[id].speaker}
{$events[id].title}


{/section}
{section name="id" loop=$events}
...
{sectionelse}
No results
{/section}
--
John Holmes
php|architect - The magazine for PHP professionals - http://www.phparch.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty and db

[Justin Patrin]

On Tue, 3 Aug 2004 14:21:45 -0500 (EST), Amanda Hemmerich
<[EMAIL PROTECTED]> wrote:
> Ok, I am starting a new job and learning a new person's code, and trying
> to learn Smarty at the same time.
> 
> This question is so basic, but I have no idea where to look for an answer.
> 
> ANyway, I need to change the code so that, when there are no row returned
> by the database, a message is displayed saying, "There are no events
> scheduled." or what have you.
> 
> Now, the way I would have done this before using smarty would be to check
> the number of records, and if there were none, I would display the
> message, otherwise, I would loop through and display the results,
> 
> However, I know one of the points of smarty is to keep code out of the
> presentation layer, so I don't want to go into the template and add an if
> statement in there.
> 
> Any help directing me to an example or whatever would be helpful.
> 
> Here is what is going on right now in the code:
> 
> (in the PHP page)
> $events = $db->getAll($sql_events, DB_FETCHMODE_ASSOC);
> $tpl->assign("events",$events);
> 
> (in the template page)
> {section name=id loop=$events}
> 
> 
> {$events[id].type}:  href="{$url_prefix}/community/events/?id={$events[id].id}">{$events[id].date|date_format:"%B
> %e, %Y"}, {$events[id].speaker}
> {$events[id].title}
> 
> 
> {/section}
> 

My solution to this would be to change the template. IMHO it's a
"view" funciton to display something different when there is no data.

However, if you're averse to that, I would suggest using a different template.

-- 
DB_DataObject_FormBuilder - The database at your fingertips
http://pear.php.net/package/DB_DataObject_FormBuilder

paperCrane --Justin Patrin--

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty and db

[John Nichel]

On Tuesday 03 August 2004 15:21, Amanda Hemmerich offered up the following 
tid-bit of information :
> Ok, I am starting a new job and learning a new person's code, and trying
> to learn Smarty at the same time.
>
> This question is so basic, but I have no idea where to look for an
> answer.
>
> ANyway, I need to change the code so that, when there are no row returned
> by the database, a message is displayed saying, "There are no events
> scheduled." or what have you.
>
> Now, the way I would have done this before using smarty would be to check
> the number of records, and if there were none, I would display the
> message, otherwise, I would loop through and display the results,
>
> However, I know one of the points of smarty is to keep code out of the
> presentation layer, so I don't want to go into the template and add an if
> statement in there.
>
> Any help directing me to an example or whatever would be helpful.
>
> Here is what is going on right now in the code:
>
> (in the PHP page)
> $events = $db->getAll($sql_events, DB_FETCHMODE_ASSOC);
> $tpl->assign("events",$events);
>
> (in the template page)
> {section name=id loop=$events}
> 
> 
> {$events[id].type}:  href="{$url_prefix}/community/events/?id={$events[id].id}">{$events[id].d
>ate|date_format:"%B %e, %Y"}, {$events[id].speaker}
> {$events[id].title}
> 
> 
> {/section}
>
> Thanks,
> Amanda

According to this page 
http://smarty.php.net/manual/en/language.function.if.php you should be able 
to do something like.

{ if is_array ( $events ) }
do smarty stuff
{ /if }

-- 
John C. Nichel
ÜberGeek
KegWorks.com
716.856.9675
[EMAIL PROTECTED]

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[pete M]

Curt Zirzow wrote:
:0
* ^Subject: Re: smarty 
/dev/null

Curt


agreed

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Curt Zirzow]

:0
* ^Subject: Re: smarty 
/dev/null

Curt
-- 
"I used to think I was indecisive, but now I'm not so sure."

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Chris de Vidal]

Vicente Werner said:
> mmm some points:
>
> 1st. Clarity. It's much more clear to me to take a look at a template and
> identify a subsituing variable when it's marked as something different
> like:
> {$var} than the uglyness of  -and if you follo the recommended
> way:
> 

Tomay-toe, toh-mah-toe.

> 2nd. As other users pointed, error handling.

Possibly.  I could also custom-build it or add it with other
libraries/classes.  Smarty has it built-in, making Smarty a great choice.

> 3th. Lack of temptation. If I start putting pure php code on my templates
> it wouldn't be long before half the application logic ends there, we'll
> know what's to code under tight schedules. Smarty by separating my
> presentation logic from my bussines logic helps me avoid spaghetti code.

You must be disciplined in any case.  Smarty has loops and custom
functions and can even include real PHP.  You just have to be disciplined.

> Appart from the ton of small features that smarty gives you like caching,
> easyness to do popups, the variable modificators, etc..

Caching/popups/variable modifications can be easily added with native PHP
functions (that perhaps people aren't aware of) or with external
libraries/classes.  Smarty has them all "under one roof," making it an
excellent choice -- when it's needed.

My point is that it isn't always needed, as I thought it was.  I'm sure
others believe it's their only choice.

/dev/idal

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Vicente Werner]

mmm some points:

1st. Clarity. It's much more clear to me to take a look at a template and 
identify a subsituing variable when it's marked as something different like:
{$var} than the uglyness of  -and if you follo the recommended way: 


2nd. As other users pointed, error handling.

3th. Lack of temptation. If I start putting pure php code on my templates it 
wouldn't be long before half the application logic ends there, we'll know 
what's to code under tight schedules. Smarty by separating my presentation 
logic from my bussines logic helps me avoid spaghetti code.

Appart from the ton of small features that smarty gives you like caching, 
easyness to do popups, the variable modificators, etc..

-- 
__
Vicente Antonio Sánchez Werner ( [EMAIL PROTECTED] )
Fijo: +34-923185650 Movil: +34-66865
Director Depto Informática, Desarrollo y Seguridad Informática
Wap Comunicaciones S.L.
C/Guadalajara nº9-11
37003 Salamanca (España)
--

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Enrico Weigelt]

* Chris de Vidal <[EMAIL PROTECTED]> [2004-04-14 11:33:56 -0400]:


> Naww... I'd been using Smarty for several weeks now because I thought the
> only alternative to spaghetti code was Smarty, but recently I realized
> that it's not, and that simple example shows it.  I didn't realize I had
> another alternative.

Well, you should probably try patTemplate :)


cu
-- 
-
 Enrico Weigelt==   metux IT services

  phone: +49 36207 519931 www:   http://www.metux.de/
  fax:   +49 36207 519932 email: [EMAIL PROTECTED]
  cellphone: +49 174 7066481
-
   -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting --
-

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Enrico Weigelt]

* Chris de Vidal <[EMAIL PROTECTED]> [2004-04-14 10:30:53 -0400]:


> So there are alternatives to what Smarty offers, but I also said "I just
> see them [template engines] as another tool."  It's a tool; use it where

I can't agree here. 

Template engines (in the sense we're talking here - for separating 
presentation/layout from application logic in web-like application 
environments) should be much more than just a tool, they're better 
should be considered as a fundamental component in the whole environment,
as well as the application server, the frontend webserver (httpd),
database/storage or client.

The W3C tries to establish its own template engine - XSLT - (probably
the most powerful) in the web. Of course its a little bit too 
complicated and overdozed for many small applications and quite hard
to learn for non-programmers. So there're other, more simple, 
template engines out there, i.e. patTemplate/pTemplate.


cu
-- 
-
 Enrico Weigelt==   metux IT services

  phone: +49 36207 519931 www:   http://www.metux.de/
  fax:   +49 36207 519932 email: [EMAIL PROTECTED]
  cellphone: +49 174 7066481
-
   -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting --
-

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Chris de Vidal]

Richard Davey said:
> CdV> I don't understand... how is this:
> [snip]
> CdV> Better than this?
> CdV> =
> CdV> $result = mysql_query ("SELECT * FROM users WHERE id =
> '".$_GET["id"]."');
> CdV> $row_array = mysql_fetch_array ($result);
> CdV> $name= $row_array["name"];
> CdV> $address = $row_array["address"];
> CdV> $state   = $row_array["state"];
> CdV> $include("template.tpl");
> CdV> ---
> CdV> 
> CdV> 
> CdV> Name: 
> CdV> Address: 
> CdV> State: 
> CdV> ...
> CdV> ===
>
> Because you're injecting variables directly into your HTML, which some
> of the time might be ok - but what if the $row_array doesn't contain
> "name" ? You'll raise an Error Warning without first passing it
> through some kind of test (or function).

A good point.  Alternatively I could write error handling myself or
include a library/class.  This is where, in my opinion, Smarty shines, but
is not significantly different than other libraries/classes.

> You assume that the PHP short-tags are enabled () for
> echoing variables and while most the time they are, you shouldn't bank
> on it in code (incidentally, you don't need the trailing ; on the
> short-tag echos).

I was waiting for someone to ding this :-)  I have been used to using
.

> Sure - these things can be fixed easily, but then that isn't the point
> - if you think about it logically, anything Smarty can do, PHP can do
> too (well, duh! :)
>
> But what if you want to take your template and perform a bit more than
> just mere variable substitution on it? How about highlighting all
> words that match a search term, or applying logic to a display block
> based on a user status?

Another good point.  But by writing it myself or including some other
library/class I could have the same functionality.  There again, Smarty is
a great library, and I'll use it when I need it.

> Personally I don't use smarty*, but even I can see the benefits it
> offers.

Me too.  It's likely I'll use it in the future.

/dev/idal

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Chris de Vidal]

pete M said:
> Think everyone is missing the point..
> the whole point of smarty is to take the presentation code away from the
> logic

No, I understood that point.  It's why I started using Smarty.  Take
another look at what I said:
http://marc.theaimsgroup.com/?l=php-general&m=108145205519710&w=2

/dev/idal

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Chris de Vidal]

Kelly Hallman said:
> I don't recall anyone ever advancing the notion that Smarty turned PHP
> into something more than it was before. By definition it is merely a layer
> that makes your life as a developer easier. A tool!

Yeah but in my ignorance that's what I thought, and I realized I probably
was not alone.

> However, those of us who are seeing great benefit from the use of Smarty
> are not mere ignoramouses, and I feel that the implication being made is
> that we're not seeing what PHP can already do. This is false.

OK but I was an ignoramous and I believe there *are* others out there like
myself.

> The reason this is such a contentious issue, I think, is because the point
> being made--while correct, and note-worthy--is short-changing Smarty by
> calling it redundant. I feel that one's use of Smarty may indeed be
> redundant, that's easy to do. However, Smarty is not inherently redundant.
> Using Smarty redundantly does not make Smarty itself one bit redundant.

I said it was mostly, not completely redundant.  In the case of the cool
built-in functions you've got some advantages.  But I believe those could
also be (perhaps more effectively) implimented with other libraries.  It's
just a tool.

> To make that claim, you're dropping a pretty heavy dis on a lot of people
> who have invested a great deal of time, effort, and subsequently realized
> great benefits from Smarty and it's templating brethren. Not to mention
> all those who have devoted great effort in the development of these tools.

I believe it and most templating engines were written because many people
didn't know they had an alternative.  I could be wrong; if so, it is a
"heavy dis."  Didn't mean it that way, so if I am wrong I humbly
apologize.

> I'm seriously not trying to sound harsh here, but do you think that by
> realizing you could structure your PHP code in such a way to mimic a basic
> Smarty template, you've now single-handedly debunked the purpose for all
> of this effort by so many avid PHP programmers? Seriously, now...!

Naww... I'd been using Smarty for several weeks now because I thought the
only alternative to spaghetti code was Smarty, but recently I realized
that it's not, and that simple example shows it.  I didn't realize I had
another alternative.

It's like this: "Does your mother know you're stupid?"  Either way you
answer, you're stupid.  If you don't realize you have another alternative
you're stuck.  I believe Smarty was written because people didn't realize
they had the other alternative.  If I am wrong, see above.

> Regardless of the merit of the point being made, I don't think that
> benefits anyone much. I'm sure when some guy came up with a metal knife,
> there was a dude there with a sharp rock saying, "but this works too!"
> Then the guy with the knife started using it to cut everything, while the
> rock required constant honing to remain sharp enough to do half the work.
> But the guy with the rock thought it was all he needed! I use a knife.

I see what you mean, but my point is PHP already *is* the knife: it
templates with about the same effort as Smarty.  At times less effort (in
which case I'd use native PHP), at times more (in which case I'd use
Smarty).

Anyway, thanks for the input.

/dev/idal

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Chris de Vidal]

Vicente Werner said:
> > http://marc.theaimsgroup.com/?l=php-general&m=108145205519710&w=2
> Ugh that's not just fuckingly ugly, but a total doom to maintain over the
> time -two months without touching the code and you're absolutely lost- .
> It maybe faster, it maybe a bit simpler since you only have to learn one
> language, but it's a mental carnage to maintain a client site that way

I don't understand... how is this:
==
$page = new Smarty();
$result = mysql_query ("SELECT * FROM users WHERE id = '".$_GET["id"]."');
$row_array = mysql_fetch_array ($result);
$page->assign("name",$row_array["name"]);
$page->assign("address", $row_array["address"]);
$page->assign("state",   $row_array["state"]);
$page->display("template.tpl");
---


Name: {$name}
Address: {$address}
State: {$state}
...
===


Better than this?
=
$result = mysql_query ("SELECT * FROM users WHERE id = '".$_GET["id"]."');
$row_array = mysql_fetch_array ($result);
$name= $row_array["name"];
$address = $row_array["address"];
$state   = $row_array["state"];
$include("template.tpl");
---


Name: 
Address: 
State: 
...
===

They both look about the same (well in the native PHP example I actually
wrote less code).

Perhaps you were looking at my spaghetti-code example, but take another
look, I posted 3 examples.

/dev/idal

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Chris de Vidal]

pete M said:
> what about the modifiers

> How would you code that lot and remember its ALL to do with presentation ?

I mentioned this.  Take another look at my post:
http://marc.theaimsgroup.com/?l=php-general&m=108145205519710&w=2
"[By using only PHP], At worst [I lose] some of the nice
Smarty functions such as html_options (which might be easily replaced by
phpHTMLlib or another widget library)."

So there are alternatives to what Smarty offers, but I also said "I just
see them [template engines] as another tool."  It's a tool; use it where
it saves time, but it's not as if native PHP lacks most (if not all) of
what Smarty offers, which is what I originally thought because I'd learned
PHP by spaghetti coding.

I would never say that Smarty is completely redundant.  Use it where it
makes sense.  But now that my eyes have been opened I believe it's
_mostly_ redundant.  I believe it was written because so many people
aren't aware that native PHP is a *very* effective template engine.

/dev/idal

P.S. Have a look at the article I linked in my post:
http://www.phppatterns.com/index.php/article/articleview/4/1/1/

While I don't totally agree with everything he says (he says ALL
templating engines are bad), it was an eye-opener for me.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Summary was Re: [PHP] smarty

[Jochem Maas]

Justin Patrin wrote:

Jochem Maas wrote:
...

Smarty does force that at all; you have to make the distinction and 
apply liberal self-restraint.
I meant 'does NOT force' - thinko!

...

PLEASE WORLD: GET BEHIND CSS, AND FREE CONTENT FROM STYLE ON THE CLIENT.
why because it allows the structrully mark-uped to be display more 
flexibly, for diff. display, aural readers, braille etc. removing the 
styling definitions it also allows you to specify different markup.


I want to. I so want to, but I can never get it to make the layout as I 
want it. I want to take a div and make it vertically or horizontally 
be practical - if you need to vertical align something and can't get it 
to work another way use a table.

I CSS site that I found really inspiring is http://www.csszengarden.com/
if you really 'want to' then take the time to read it and view all the 
styles (well not ness. all 247) - take a look at the HTML (and the CSS 
file for each style), maybe have a go at it yourself.

centered in another divif you figure out how to do it with dynamic 
try to let go of the assumption that you can control the display of your 
pages (think of the all the platform/hardware/software/user-settings/etc 
 combinations there are.) - you can only guide it. one of the founding 
ideas of the 'webpage' if that the manner in which it is displayed is 
upto the user (braille/speech/mobile/PC/Barney).

also attempt a site contruction by first creating a bare bones text only 
site with proper markup (P,H tags etc. prefer XHTML over HTML), the see 
what you can add. (have a look at the effect is of using different 
DOC-TYPEs)

sizes that is easy and works on all the major browsers, let me know. 
I've tried for hours, looks on I don't know how many websites, and I 
still couldn't do it. I went back to tables because it's just so easy. 
CSS makes my life very hard...it doesn't seem to have the basics needed 
to create an entire layout.
er but it really does (and the trick is to). not to worry I have been 
hacking css for about 3 years now, in the beginning it was even worse - 
support is getting better which means documentation often more closely 
ressembles truth ;-)

Make Mozilla/Opera part of your testing kit - they support CSS better 
(they are not 3+ years old like IE6).

instead of approaching it from the view of a print designer - ie fixed, 
static layout - assume the layout is a liquid 
(http://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=liquid+design)

to be honest - in this game you really have to study something to truely 
get a grip on it. I mean, how many scripts have you poured over, how 
many hours with just one of those scripts to get it to play just right? 
 CSS is no different.

That said, I do use lots of CSS for styling (font sizes, colors, images, 
printable pages, etc.), but fill-page styling via CSS is just beyond my 
reach.
dumping all those style definitions in a seperate file in a good start.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Summary was Re: [PHP] smarty

[Justin Patrin]

Jochem Maas wrote:

Chris de Vidal wrote:

Jochem Maas said:

1. 'Template Engine' - you can justifyably call PHP a template engine


Correct.  Seems that Smarty is, for the most part, redundant (see my last
post called "PHP makes a great templating engine (Was: smarty)").
I was not intending to pronounce Smarty redundant; on the contrary if 
anything - but thats not the point...


but I think calling Smarty a template engine confuses the issue - it
would be clearer call it something like 'Presentation Component' which
encapsulates output caching, output string transformation, markup
generation, presentation logic security & seperation of (code & possibly
human) tasks. viewing it as a component means viewing it as a tool,
tools are used when appropriate and according to their capabilities and
the scope of the job at hand. in principle a sizeable proportion of all
the.


Tool.  Look at it as just another tool.  I was seeing it as a "must have"
because I was somewhat ignorant of PHP's native capabilities.  It adds
complexity and does indeed slow down your program (the Smarty class must
load on every page) so keep those in mind.  On the other hand, you're


the Smarty core is smaller than, for example, PEAR::QuickForm (if you 
use all the plugins its about 40% larger) - and PEAR::QuickForm is 
usually used with a Renderer (e.g. Smarty!!), think of it like this: how 
much do you charge per hour, what does an extra CPU cost & how much, if 
any, time does Smarty save you. (besides which I think its quite easy to 
develop something in Smarty which does what QuickForm does but more 
transparently and with alot less hassle - IMHO).

Code is code; it might not be perfect but it might scratch an itch.

almost forced to separate business and presentation and you gain caching


Smarty does force that at all; you have to make the distinction and 
apply liberal self-restraint.

(though native PHP options or Zend are available).  So it's a weighty
decision.  But it is a good tool.


Realise that Smarty (usually) only re-compiles the template if it 
changes. The compiled template are full of generated PHP - there is 
little overhead in including that.

if you use a native PHP option then:
a, what is Smarty? (not important!)
b, what are the chances that your output code/module/class/etc will
not employ similar solutions to something like Smarty? because broadly 
speaking



3. 'Lock In'


I believe "Lock In" is a big problem unless you document well.  For
instance, my supervisor is probably going to choose ASP.NET (don't ask
why) for our next project.  But all along, I plan to document it well in
case we hit a stumbling block.  With a bit of effort and the source 
code I
can port it to PHP.  I've even toyed with the idea of keeping a
fully-functional copy written in PHP while he's working in ASP.NET ;-) 
But I've got better things to do.


Limitations are often purely percieved rather than actual


I believe that's why I chose Smarty for my last project.  I thought PHP
limited me to keeping business logic mixed with presentation logic, but
it's hardly the case.


and funnily enough Smarty is actually a pretty good example of a 
possible PHP based solution to the problem logic seperation.

When you consider that it's just another tool in your box, it works 
well. It's not the only way to let designers design and programmers 
program
(Jochem is a big believer in CSS for that).  Just think of it as another


PLEASE WORLD: GET BEHIND CSS, AND FREE CONTENT FROM STYLE ON THE CLIENT.
why because it allows the structrully mark-uped to be display more 
flexibly, for diff. display, aural readers, braille etc. removing the 
styling definitions it also allows you to specify different markup.
I want to. I so want to, but I can never get it to make the layout as I 
want it. I want to take a div and make it vertically or horizontally 
centered in another divif you figure out how to do it with dynamic 
sizes that is easy and works on all the major browsers, let me know. 
I've tried for hours, looks on I don't know how many websites, and I 
still couldn't do it. I went back to tables because it's just so easy. 
CSS makes my life very hard...it doesn't seem to have the basics needed 
to create an entire layout.

That said, I do use lots of CSS for styling (font sizes, colors, images, 
printable pages, etc.), but fill-page styling via CSS is just beyond my 
reach.

Ever written a print version of a page? why bother when all you need do 
  is specify alternative stylesheet(s) to use for print media.

Ever heard you page say 'IMAGE' 'TABLE' & 'DATA CELL' 50 odd times as a 
blind persons screen reader trys to make sense of your pretty new 
data-driven creation... where the f*** is the menu?! did you know there 
is even an extensive specification for markup of aural media (e.g. tone 
of voice, male/female, speed etc etc)

In my little world I have officially declared a Good Thing. of course
it leaves the problem of how to manage all those sty

RE: [PHP] smarty

[Pablo Gosse]

"Who the fuck you tink you're talkin' to, huh! Whatta you think I am?
Your fuckin' slave! You dont tell me what to do, Sosa. Youre shit! You
want a war, you got it. I'll take you to war!"


Shame on you for misquoting Scarface.

G'nite, "Tony".  Next time you're going to quote a classic please get it
right.

Oh, and this is a php list not alt.movies.misquoted ;o)

P.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Curt Zirzow]

* Thus wrote Richard Davey ([EMAIL PROTECTED]):
> Hello Antonio,
> 
> Friday, April 9, 2004, 12:21:15 AM, you wrote:
> 
> AM> "Who the  you tink you're talkin' to, huh! Whatta you
> (etc)
> 
> Dear God, who unlocked the monkey cage?

Monkey's can type better than that.


Curt
-- 
"I used to think I was indecisive, but now I'm not so sure."

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] smarty

[PHP Email List]

> From: Antonio Montana [mailto:[EMAIL PROTECTED]
> Subject: Re: [PHP] smarty
> "Who the fuck you tink you're talkin' to, huh!

Tink? DRINKS ARE ON THE HOUSE!!

LOL

> You dont tell me what to do, Sosa.

Sammy Sosa?

> You want a war, you got it.

Untraceable IP address - $145.00
Unbreakable Firewall - $253.00
AOL Dialup connection - $19.95
15 yr old punk talkin smack, "ONLINE" - PRICELESS

Man if I had a dime for everyone that wanted to "fight me" over the net, I'd
be Bill Gates!  Move over Microsoft, here comes InternetWars.com.  You gotta
love internet punks!

> I'll take you to war!"

Givem a Dialup connection a wireless mouse and keyboard and hey you can talk
smack online.  And what war are you going to, Iraq?  Someone needs to kick
the barstool out from under this schmuck!
Just when you thought the "smarty" template discussion/controversy was over,
HELL NO, Here comes the WAR!!

PS. Please send all dimes in the form of a check payable to...
Dimes for Internet Wars
1600 Pennsylvania Avenue NW
Washington, DC 20500

For those that I may have "Pissed off", Please don't respond to this email,
just send the dimes instead. :)  Thanks!
Wolf

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Smarty Summary was Re: [PHP] smarty

[Jochem Maas]

Chris de Vidal wrote:

Jochem Maas said:

1. 'Template Engine' - you can justifyably call PHP a template engine


Correct.  Seems that Smarty is, for the most part, redundant (see my last
post called "PHP makes a great templating engine (Was: smarty)").
I was not intending to pronounce Smarty redundant; on the contrary if 
anything - but thats not the point...


but I think calling Smarty a template engine confuses the issue - it
would be clearer call it something like 'Presentation Component' which
encapsulates output caching, output string transformation, markup
generation, presentation logic security & seperation of (code & possibly
human) tasks. viewing it as a component means viewing it as a tool,
tools are used when appropriate and according to their capabilities and
the scope of the job at hand. in principle a sizeable proportion of all
the.


Tool.  Look at it as just another tool.  I was seeing it as a "must have"
because I was somewhat ignorant of PHP's native capabilities.  It adds
complexity and does indeed slow down your program (the Smarty class must
load on every page) so keep those in mind.  On the other hand, you're
the Smarty core is smaller than, for example, PEAR::QuickForm (if you 
use all the plugins its about 40% larger) - and PEAR::QuickForm is 
usually used with a Renderer (e.g. Smarty!!), think of it like this: how 
much do you charge per hour, what does an extra CPU cost & how much, if 
any, time does Smarty save you. (besides which I think its quite easy to 
develop something in Smarty which does what QuickForm does but more 
transparently and with alot less hassle - IMHO).

Code is code; it might not be perfect but it might scratch an itch.

almost forced to separate business and presentation and you gain caching
Smarty does force that at all; you have to make the distinction and 
apply liberal self-restraint.

(though native PHP options or Zend are available).  So it's a weighty
decision.  But it is a good tool.
Realise that Smarty (usually) only re-compiles the template if it 
changes. The compiled template are full of generated PHP - there is 
little overhead in including that.

if you use a native PHP option then:
a, what is Smarty? (not important!)
b, what are the chances that your output code/module/class/etc will
not employ similar solutions to something like Smarty? because broadly 
speaking



3. 'Lock In'


I believe "Lock In" is a big problem unless you document well.  For
instance, my supervisor is probably going to choose ASP.NET (don't ask
why) for our next project.  But all along, I plan to document it well in
case we hit a stumbling block.  With a bit of effort and the source code I
can port it to PHP.  I've even toyed with the idea of keeping a
fully-functional copy written in PHP while he's working in ASP.NET ;-) 
But I've got better things to do.


Limitations are often purely percieved rather than actual


I believe that's why I chose Smarty for my last project.  I thought PHP
limited me to keeping business logic mixed with presentation logic, but
it's hardly the case.
and funnily enough Smarty is actually a pretty good example of a 
possible PHP based solution to the problem logic seperation.

When you consider that it's just another tool in your box, it works well. 
It's not the only way to let designers design and programmers program
(Jochem is a big believer in CSS for that).  Just think of it as another
PLEASE WORLD: GET BEHIND CSS, AND FREE CONTENT FROM STYLE ON THE CLIENT.
why because it allows the structrully mark-uped to be display more 
flexibly, for diff. display, aural readers, braille etc. removing the 
styling definitions it also allows you to specify different markup.

Ever written a print version of a page? why bother when all you need do 
  is specify alternative stylesheet(s) to use for print media.

Ever heard you page say 'IMAGE' 'TABLE' & 'DATA CELL' 50 odd times as a 
blind persons screen reader trys to make sense of your pretty new 
data-driven creation... where the f*** is the menu?! did you know there 
is even an extensive specification for markup of aural media (e.g. tone 
of voice, male/female, speed etc etc)

In my little world I have officially declared a Good Thing. of course
it leaves the problem of how to manage all those stylesheets 
effectively. something PHP might be able to help with.

my best shot so far at seperating the style from mark and creating 
something (vaguely) valid (don't think the w3c validator is 100%) & 
crossbrowser compatible (no doubt its not :-S). it quite image heavy - 
backgrounds, headers, graphic mouse-overs, 'quotes' etc but if you look 
 at the HTML source you'll see its quite devoid of any 'imagery':

http://www.oneworldtrade.nl/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Antonio Montana]

"Who the fuck you tink you're talkin' to, huh! Whatta you think I am? Your fuckin' 
slave! You dont tell me what to do, Sosa. Youre shit! You want a war, you got it. I'll 
take you to war!"
 

http://www.youdontknowwhoiam.org/lol.html



"John W. Holmes" <[EMAIL PROTECTED]> wrote:

Antonio M wrote:

> So say good night to the bad guy...cause it's the last time youre gonna see a bad 
> guy like me.

Good night. You're drank too much tonight, anyhow.

-- 
---John Holmes...

Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/

php|architect: The Magazine for PHP Professionals – www.phparch.com

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[John W. Holmes]

Antonio M wrote:

So say good night to the bad guy...cause it's the last time youre gonna see a bad guy like me.
Good night. You're drank too much tonight, anyhow.

--
---John Holmes...
Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/

php|architect: The Magazine for PHP Professionals – www.phparch.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Justin Patrin]

Robert Cummings wrote:
On Wed, 2004-04-07 at 21:35, Kelly Hallman wrote:

Apr 8 at 10:26am, Justin French wrote:

PHP itself is a great templating language :)



 


'>

Uhhh, yeah--that's not a templating, that's called spaghetti code :)

You get the concept. Smarty, as you know, basically takes a Smarty
template and writes PHP code similar to what you've done above, then
writes out the .php file, and includes it when you render your template.
So you'd get nearly the same effect by writing the PHP as a separate file
and including it as your last step, and it acts as your display logic.
That may be acceptable to you, as a PHP programmer. If you're the only one
who ever needs to modify your templates then that's great, more power to
you. I'm sure that you would have no problem having many levels of nesting
all over the place and not screwing anything up. So be it. But that's you.
I guarantee another person not as adept at PHP will screw that code up,
and there is less potential for that with a Smarty template. If you know
PHP as well as yourself, it should be plain to see how Smarty is just a
wrapper over PHP that makes templates easier to build and maintain.
For a designer or non-coder, Smarty will be easier to learn than PHP.
Unless your needs never exceed the very basics like you have demonstrated
above, you'll be hosed when another person needs to modify your template.  
Which goes back to a templating truism never in dispute: if this is all
you want templating for, it's six of one, half a dozen of the other.

However, there are practical limitations on what you can easily accomplish
with this approach, and Smarty addresses those issues. And you're worse
off if you invest a lot into building your sites this way, and then
realize you need some better templating strategies later.

You can still separate your logic from your presentation, template 
designers can still use quick, simple "tags" to include code, and the 
upside is that people familiar with PHP don't need to learn ANOTHER 
language (that's what Smarty is) -- they can dive straight in.
You can consider it it's own language, but really it's more like PHP with
different formatting. Which is why it's different than what you're doing
above--it's designed to facilitate templating. Your method is just poking
in variables and PHP into inline'd HTML. It works, but you're missing some
of the power of Smarty if you think that's all it's good for.

The question is, do you want to give your templater designers full 
access to the power of PHP, or not.
In other words: are your template designers already good PHP programmers?
It's not just hype, it solves real problems, even if you don't have them.


Smarty is a bit of a hack too... why do I need to declare my templates
within the PHP code? If I'm an HTML designer I'd like to create a new
page, include templates, use some data that's been made available and
have it all in the template. I sure as heck wouldn't want to have joe
programmer edit the main page, add support for importing my template.
This is the thing that bugs me about Smarty, its still got that hanging
dependency. And it's still got to include all those templates within the
source code.
I think you're missing something here. Yes, the PHP code has to choose a 
template to render...that's a given. But you can include other templates 
within a smarty template.

{include file="template2.tpl"}

In this way, the template writer can do whatever they want, have as many 
templates as they want, and the PHP coder doesn't have to know anything 
about it.

It is true that if you want more data the PHP programmer will have to 
give it smarty for you, but that's what happens when you seperate the 
display code...

InterJinn is superior in this respect. You use XML tags to import other
templates, you use XML tags to load modules and components, and you use
XML tags to do almost any kind of expansion you want. Of course, you can
go ahead and use something else, InterJinn provides the ability to plug
in custom compilers. InterJinn compiles to PHP code, includes are
INCLUDED at compile time not at run time. So given this scheme anyone
working on the HTML is already familiar with the syntax... hard to go
wrong with:


Hell you can even overload HTML tags. Not only that but Interjinn allows
recursive includes of templates and source files, and these includes can
be relative to the outer nested template or source file. Furthermore,
there's nothing forcing the use of the InterJinn application layer so
InterJinn can be used entirely for it's templating features, in which
case it provides a faster resulting PHP page than using PHP include().
Cheers,
Rob.


--
paperCrane 
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] smarty

[Chris W. Parker]

Antonio M 
on Thursday, April 08, 2004 12:57 PM said:

> You need people like me so you can point your fingers and say "hey
> theres the bad guy!" So what does that make you? Good guys? Don't kid
> yourselves. You're no better than me. You just know how to hide --
> and how to lie. Me I don't have that problem..Me I always tell the
> truth--even when I lie.
> 
> So say good night to the bad guy...cause it's the last time youre
> gonna see a bad guy like me. 
> 
> -T. Montana

please make sure to at least include *something* from the original email
you are responding to. there's no context without it.


thanks!!
chris.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] smarty

[Antonio M]

You need people like me so you can point your fingers and say "hey theres the bad 
guy!" So what does that make you? Good guys? Don't kid yourselves. You're no better 
than me. You just know how to hide -- and how to lie. Me I don't have that problem..Me 
I always tell the truth--even when I lie.
 
So say good night to the bad guy...cause it's the last time youre gonna see a bad guy 
like me.

-T. Montana

Re: [PHP] Smarty Summary was Re: [PHP] smarty

[Chris de Vidal]

Jochem Maas said:
> 1. 'Template Engine' - you can justifyably call PHP a template engine

Correct.  Seems that Smarty is, for the most part, redundant (see my last
post called "PHP makes a great templating engine (Was: smarty)").

> but I think calling Smarty a template engine confuses the issue - it
> would be clearer call it something like 'Presentation Component' which
> encapsulates output caching, output string transformation, markup
> generation, presentation logic security & seperation of (code & possibly
> human) tasks. viewing it as a component means viewing it as a tool,
> tools are used when appropriate and according to their capabilities and
> the scope of the job at hand. in principle a sizeable proportion of all
> the.

Tool.  Look at it as just another tool.  I was seeing it as a "must have"
because I was somewhat ignorant of PHP's native capabilities.  It adds
complexity and does indeed slow down your program (the Smarty class must
load on every page) so keep those in mind.  On the other hand, you're
almost forced to separate business and presentation and you gain caching
(though native PHP options or Zend are available).  So it's a weighty
decision.  But it is a good tool.

> 3. 'Lock In'

I believe "Lock In" is a big problem unless you document well.  For
instance, my supervisor is probably going to choose ASP.NET (don't ask
why) for our next project.  But all along, I plan to document it well in
case we hit a stumbling block.  With a bit of effort and the source code I
can port it to PHP.  I've even toyed with the idea of keeping a
fully-functional copy written in PHP while he's working in ASP.NET ;-) 
But I've got better things to do.

> Limitations are often purely percieved rather than actual

I believe that's why I chose Smarty for my last project.  I thought PHP
limited me to keeping business logic mixed with presentation logic, but
it's hardly the case.

When you consider that it's just another tool in your box, it works well. 
It's not the only way to let designers design and programmers program
(Jochem is a big believer in CSS for that).  Just think of it as another
tool and it's no big deal.

/dev/idal

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty - php as template

[Amanda Hemmerich]

Can anyone direct me to a good resource for learning to use PHP as a
templating language along with plenty of examples?  I prefer books, but
web is fine, too.

Thanks so much!
Amanda

On Thu, 8 Apr 2004, Justin French wrote:

> On 07/04/2004, at 1:33 AM, Angelo Zanetti wrote:
> 
> > hi all has anyone used smarty before? what do you think of it? I think 
> > it's
> > pretty nice to seperate your script (code) from your design.
> >
> > i would like to hear your comments and if you have any alternatives 
> > let me
> > know.
> 
> PHP itself is a great templating language :)
> 
> 
> 
>   
>   
>
>   
>   
>   '>
>   
>   
> 
> 
> You can still separate your logic from your presentation, template 
> designers can still use quick, simple "tags" to include code, and the 
> upside is that people familiar with PHP don't need to learn ANOTHER 
> language (that's what Smarty is) -- they can dive straight in.
> 
> The question is, do you want to give your templater designers full 
> access to the power of PHP, or not.  In my case, I did.
> 
> 
> Justin
> 
> ---
> Justin French
> http://indent.com.au
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Smarty Summary was Re: [PHP] smarty

[Jochem Maas]

I have been following this thread closely and thought I'd summarize a 
few points:

1. 'Template Engine' - you can justifyably call PHP a template engine, 
but I think calling Smarty a template engine confuses the issue - it 
would be clearer call it something like 'Presentation Component' which 
encapsulates output caching, output string transformation, markup 
generation, presentation logic security & seperation of (code & possibly 
human) tasks. viewing it as a component means viewing it as a tool, 
tools are used when appropriate and according to their capabilities and 
the scope of the job at hand. in principle a sizeable proportion of all 
the.

2. 'The Template Language' - basic PHP and Smarty 'languages' are 
roughly on par in terms of complexity (MMV - were all unique!), 
personally I feel that Smarty markup looks tidier alongside (X|(X)?HT)ML.

3. 'Lock In' - the lock-in argument is academic. in reality projects you 
 build using Smarty will be decommissioned or rewritten (at which point 
you can choose to use something else) long before lock-in becomes an 
issue. Besides being locked-in to Free & Open code doesn't sound too bad 
- if you don't use somebody elses 'template engine' then you will 
probably end up writing something similar to perform the related tasks - 
 using somebody elses frees you from dev, maintainance, doc-writing etc

4. 'Limited Interface' -

5. 'Limitations' - when you find Smarty limits you, but you are 
otherwise convinced its a good tool for the job, subclass it and make it 
do things your way (or write BadAss(tm) plugins - for which you can 
achieve fame and glory if you make them available on the Smarty Wiki 
;-). any real limitations of Smarty are not of a level which would 
trouble novice users of PHP, they are simply not yet at the level where 
they are stretching the capabilities of PHP or components they use. 
Smarty is limited in 2 ways:
	1. because PHPs syntax is very broad and flexible (the fact that
	it is typeless is probably no help in this respect), this makes
	it extremely difficult to support it all with in the Smarty 		
	constructs -it not only has to work, but it has to work
	As Expected(tm).
	2. on purpose in order to allow the develop to determine what 	
	interface (functional markup*) designers. Limiting the interface
	(and by definition defining an interface) is a Good Thing(tm)
	thats why PHP5 supports interfaces for classes - consider them,
	like steel-toe-capped boots in the fight against spaghetti code.
Limitations are often purely percieved rather than actual, possibly 
stemming from the fact that somebody else decided on how (i.e. not 
_what_) to do something, small price to pay if for a free, well 
supported component really. And when you look at it you might see that 
this is a bit like developing in a team, sometimes somebody (has to) 
make(s) a decision and your stuck with it regardless of whether you 
think it is correct.

6. 'Designers & Templates' - I use really heavy smarty markup (70% or 
more is not HTML) for the presentation logic... why because my templates 
are very generic - they expect php objects of a certain types and the 
create markup based on the structures within. I don't want any 
non-programmer anywhere near my templates - styling belongs in CSS, that 
is what designers should using to change the look and feel of the site - 
from a deisgners point of view CSS type markup is the future is layout - 
it almost completely removes the styling from the structural markup 
(Murphy's Law dictates that some of the designers wishes will mean 
having to tweak the functional markup templates - but that does not 
happen constantly.). Are your designers often styling/layout online 
articles are the like? maybe it time to try a webbased (X)HTML editor - 
for a couple of $, or even for free, you have an editor to create 
content with which you can store in files or a DB, even change history 
if you want and then extract this content and display it in one of your 
structural templates.

7. 'Why the fuck do we do this?' - for the kick of writing cool code for 
one, but there are always many tasks in writing an application which are 
mundane (to say the least) - for me Smarty takes care of a few of these 
and that makes coding more fun.

8. 'Why use Smarty?' - what a non-question or rather you have to answer 
it yourself. first determine what it is you need to do now (and 
possibily in the future) then go and look what best fits the need (read 
the code and the documentation, make an effort to actually run examples) 
- if nothing fits write something. if your going judge Smarty do it 
based on the quality of the code, level of support and the 
usuability/flexibility of its API.

9. 'php.net' - it possibly says something of Smarty that it is hosted 
under the PHP banner. Smarty is certainly not the only way, probably not 
the best way and possibly not the most flexible way. But it provides a 
free, stable, widely used & well supported frame

Re: [PHP] smarty

[Robert Cummings]

On Thu, 2004-04-08 at 11:45, John Nichel wrote:
> Robert Cummings wrote:
> >>>Yeah, yeah... fine. I'm sure InterJinn doesn't limit you in any way, right?
> >>>;)
> >>
> >>It will save you money on your car insurance.  ;)
> > 
> > 
> > And people wonder why I feel the need once in while to give you a good
> > kick in the teeth for being a hypocrite and idiot. This is completely
> > off-topic and let me remind you of your past need to bring your "better
> > than thou" attitude to bear on other posters in the form of
> > chastisement. Also these snide remarks are typical of most trolls.
> > Understandably you are a troll, and well, not really worth engaging in
> > conversation.
> > 
> > What I find curious is what drives your need to target me so often? Are
> > you angry that I make references to InterJinn? Do you have a problem
> > when I use it as an example or a point in debate? Really, WHAT IS YOUR
> > PROBLEM? Please get over it!
> > 
> > Cheers,
> > your buddy,
> > Rob.
> 
> Actually 'buddy', I made a little joke to add some levity to a topic 
> which seems to be teetering on the edge of personal discussion and 
> personal attacks (maybe you missed the little wink ;) ).  Guess we see 
> which side of the fence you seem to be on at the moment.  STFA 'buddy' 
> and you'll see that I make these little jokes from time to time, and 
> only once before had one of those jokes been directed towards InterJinn 
> (remember, it would simonize your car...which you even joked with).  But 
> no matter, I'll be your troll...you big bad Internet tough guy you. 
> Have a good one, 'buddy'.

Yes once is humour, and I met it with humour, but your consistency of
jabbing makes it more than humourous. It tends to make me think you have
some other agenda. And NO, a smiley face doesn't make me have to like
it, especially considering our past history where there is obviously no
love, which only strengthens the argument that you are being an ass. And
I have no need to STFA, I am quite aware of what you have said in the
past, my memory isn't currently failing me.

Rob.
-- 
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for   |
| creating re-usable components quickly and easily.  |
`'

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[John Nichel]

Robert Cummings wrote:
Yeah, yeah... fine. I'm sure InterJinn doesn't limit you in any way, right?
;)
It will save you money on your car insurance.  ;)


And people wonder why I feel the need once in while to give you a good
kick in the teeth for being a hypocrite and idiot. This is completely
off-topic and let me remind you of your past need to bring your "better
than thou" attitude to bear on other posters in the form of
chastisement. Also these snide remarks are typical of most trolls.
Understandably you are a troll, and well, not really worth engaging in
conversation.
What I find curious is what drives your need to target me so often? Are
you angry that I make references to InterJinn? Do you have a problem
when I use it as an example or a point in debate? Really, WHAT IS YOUR
PROBLEM? Please get over it!
Cheers,
your buddy,
Rob.
Actually 'buddy', I made a little joke to add some levity to a topic 
which seems to be teetering on the edge of personal discussion and 
personal attacks (maybe you missed the little wink ;) ).  Guess we see 
which side of the fence you seem to be on at the moment.  STFA 'buddy' 
and you'll see that I make these little jokes from time to time, and 
only once before had one of those jokes been directed towards InterJinn 
(remember, it would simonize your car...which you even joked with).  But 
no matter, I'll be your troll...you big bad Internet tough guy you. 
Have a good one, 'buddy'.

--
***
*  _  __   __  __   _  * John  Nichel *
* | |/ /___ __ \ \/ /__ _ _| |__ ___  __ ___ _ __  * 716.856.9675 *
* | ' http://www.KegWorks.com[EMAIL PROTECTED] * 14203 - 1321 *
***
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Robert Cummings]

On Thu, 2004-04-08 at 11:04, John Nichel wrote:
> John W. Holmes wrote:
> > From: "Robert Cummings" <[EMAIL PROTECTED]>
> > 
> >>On Thu, 2004-04-08 at 10:45, John W. Holmes wrote:
> >>
> >>>Any templating engine,
> >>>that's not PHP itself, is going to restrict what the designer can do to
> > 
> > some
> > 
> >>>extent.
> >>
> >>This is a pretty broad statement and is not true in general despite it's
> >>applicability in many cases.
> > 
> > 
> > Yeah, yeah... fine. I'm sure InterJinn doesn't limit you in any way, right?
> > ;)
> 
> It will save you money on your car insurance.  ;)

And people wonder why I feel the need once in while to give you a good
kick in the teeth for being a hypocrite and idiot. This is completely
off-topic and let me remind you of your past need to bring your "better
than thou" attitude to bear on other posters in the form of
chastisement. Also these snide remarks are typical of most trolls.
Understandably you are a troll, and well, not really worth engaging in
conversation.

What I find curious is what drives your need to target me so often? Are
you angry that I make references to InterJinn? Do you have a problem
when I use it as an example or a point in debate? Really, WHAT IS YOUR
PROBLEM? Please get over it!

Cheers,
your buddy,
Rob.
-- 
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for   |
| creating re-usable components quickly and easily.  |
`'

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Robert Cummings]

On Thu, 2004-04-08 at 10:59, John W. Holmes wrote:
> From: "Robert Cummings" <[EMAIL PROTECTED]>
> > On Thu, 2004-04-08 at 10:45, John W. Holmes wrote:
> > >
> > > Any templating engine,
> > > that's not PHP itself, is going to restrict what the designer can do to
> some
> > > extent.
> >
> > This is a pretty broad statement and is not true in general despite it's
> > applicability in many cases.
> 
> Yeah, yeah... fine. I'm sure InterJinn doesn't limit you in any way, right?
> ;)

Technically neither does Smarty since you can put PHP code in the
templates, but since InterJinn is backed by a framework which is
accessible by the render tags, accumulator tags, and various other
mechanisms, it can leverage all of the power of PHP while still
supporting business logic separation.

> I should have known better than to use the word "any" and used "most".

Well it's not generally like you to make gross generalizations :)

Cheers,
Rob.
-- 
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for   |
| creating re-usable components quickly and easily.  |
`'

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[John Nichel]

John W. Holmes wrote:
From: "Robert Cummings" <[EMAIL PROTECTED]>

On Thu, 2004-04-08 at 10:45, John W. Holmes wrote:

Any templating engine,
that's not PHP itself, is going to restrict what the designer can do to
some

extent.
This is a pretty broad statement and is not true in general despite it's
applicability in many cases.


Yeah, yeah... fine. I'm sure InterJinn doesn't limit you in any way, right?
;)
It will save you money on your car insurance.  ;)

--
***
*  _  __   __  __   _  * John  Nichel *
* | |/ /___ __ \ \/ /__ _ _| |__ ___  __ ___ _ __  * 716.856.9675 *
* | ' http://www.KegWorks.com[EMAIL PROTECTED] * 14203 - 1321 *
***
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[John W. Holmes]

From: "Robert Cummings" <[EMAIL PROTECTED]>
> On Thu, 2004-04-08 at 10:45, John W. Holmes wrote:
> >
> > Any templating engine,
> > that's not PHP itself, is going to restrict what the designer can do to
some
> > extent.
>
> This is a pretty broad statement and is not true in general despite it's
> applicability in many cases.

Yeah, yeah... fine. I'm sure InterJinn doesn't limit you in any way, right?
;)

I should have known better than to use the word "any" and used "most".

---John Holmes...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Robert Cummings]

On Thu, 2004-04-08 at 10:45, John W. Holmes wrote:
>
> [--SNIP--]
> Any templating engine,
> that's not PHP itself, is going to restrict what the designer can do to some
> extent.

This is a pretty broad statement and is not true in general despite it's
applicability in many cases.

Cheers,
Rob.
-- 
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for   |
| creating re-usable components quickly and easily.  |
`'

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[John W. Holmes]

From: "Hundiak, Arthur" <[EMAIL PROTECTED]>

> > From: John W. Holmes
> >Smarty has two benefits to using a PHP templating solution (imo)
>
> >1. Smarty forces you to keep the presentation layer separate from your
> >code/business layer.
> >2. Caching
>
> IMHO, a critical reason for choosing a template language over PHP is
> security.  Do you really want to give your template designers complete
> access to your databases?  Especially if customers have the ability to
> modify the templates themselves.

Very true. I had forgotten about that one. It can be seen as a feature or a
disadvantage, depending upon the person, though. Any templating engine,
that's not PHP itself, is going to restrict what the designer can do to some
extent.

---John Holmes...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] smarty

[Hundiak, Arthur]

> From: John W. Holmes
>Smarty has two benefits to using a PHP templating solution (imo)

>1. Smarty forces you to keep the presentation layer separate from your
>code/business layer.
>2. Caching

IMHO, a critical reason for choosing a template language over PHP is
security.  Do you really want to give your template designers complete
access to your databases?  Especially if customers have the ability to
modify the templates themselves.

I personally feel Smarty is too powerful but fortunately there are dozens of
php template systems out there.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[John Nichel]

John W. Holmes wrote:
From: "Kelly Hallman" <[EMAIL PROTECTED]>

Sure, they could. However, take a look at all the newbie questions on this
list. Maybe you've got time for all that hand holding.. but Smarty is a
lot closer to HTML, which many of them already know.


{$variable} is no more closer to HTML than . Either way you
still have to teach them the templating engine langauge. That language can
either be Smarty or a specific subset of PHP functions/methods that serves
as your templating engine (like how Justin had to write the "cycle()"
function). If you can teach them how a {section} works, then you can teach
them how a foreach() works or write a section() function that works just the
same.
This is the issue I have with things like Smarty.  No matter if I use 
PHP or Smarty, I have to 'teach' my designer how to 'code' in some 
aspect...and I've met quite a few designers who can't grasp JavaScript, 
much less Smarty or PHP.  Personally, I have the designers give me a 
HTML layout of the page to where I can cut up the HTML, and throw it 
into include files.

--
***
*  _  __   __  __   _  * John  Nichel *
* | |/ /___ __ \ \/ /__ _ _| |__ ___  __ ___ _ __  * 716.856.9675 *
* | ' http://www.KegWorks.com[EMAIL PROTECTED] * 14203 - 1321 *
***
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[John W. Holmes]

From: "Kelly Hallman" <[EMAIL PROTECTED]>

> Sure, they could. However, take a look at all the newbie questions on this
> list. Maybe you've got time for all that hand holding.. but Smarty is a
> lot closer to HTML, which many of them already know.

{$variable} is no more closer to HTML than . Either way you
still have to teach them the templating engine langauge. That language can
either be Smarty or a specific subset of PHP functions/methods that serves
as your templating engine (like how Justin had to write the "cycle()"
function). If you can teach them how a {section} works, then you can teach
them how a foreach() works or write a section() function that works just the
same.

> If you call inline code and variables a templating engine, I
> can see why you don't get it. PHP can serve a templating purpose, but it
> doesn't greatly facilitate that out of the box. It's not a strategy.

Mixing PHP and HTML is not this big, bad, evil thing that should be avoided
at all cost like many people make it out to be. The key is to separate the
"presentation / presentation logic" and the "business logic / backend code",
or whatever you want to call them. The "presentation logic" can either be
Smarty or PHP.

The problem is that if you use PHP, you must be very aware of what's going
on and ensuring you're keeping the two layers separate. It takes some
dedication. Smarty, however, FORCES you to keep the two layers separate and
I think that's why it's liked by many people. I personally think that Smarty
let you put _too much_ logic into the presentation layer, but everyone's
needs are different.

Smarty has two benefits to using a PHP templating solution (imo)

1. Smarty forces you to keep the presentation layer separate from your
code/business layer.
2. Caching

---John Holmes...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] smarty

[Kelly Hallman]

Apr 8 at 7:38am, Aaron Wolski wrote:
> I don't think this thread is tired. As someone who is about to dive into
> learning templating more than what I do now...

Tired in the sense that it had degenerated to a personal level that was 
uncalled for and off-topic. The merits of templating are never tired!

> I'll be frank with this next comment and say to you, Kelly, that it was
> fine and dandy for you to be antagonistic and demeaning with your tone
> towards Justin French when he commented that PHP, itself, IS a
> templating engine, but when John turned the tables in regards to those
> remarks made you get very defensive and ornery as illustrated in this

Here again, because I think it had been taken to a level that did not add
anything to the debate at hand, and was antagonistic for the sake of
antagonism. I was hardly trying to disrespect the point that Justin was
making, in fact I had no disagreement with the approach, other than that
it sold the concept of templating short by claiming that there is no
difference. If there was no difference, Smarty would not exist.

I think it is valid and important to understand that Smarty buys you
nothing you can't get with PHP. However, claiming that it's exactly the
same to use straight PHP, says to me that Smarty is either not being 
leveraged or it's true possibilities are not being realized.

There is a difference between a conscious choice by someone who is an
experienced PHP developer not to use Smarty, and someone who merely
doesn't see the leverage or purpose of the tool. Pedantic debates like
this surface regularly on topics such as OOP in PHP, to the detriment of
those looking for answers to problems they legitimately want to solve.

The reason this is frustrating is not because people should not have 
opinions or that there is nothing to be gained by expressing them. It's 
much different to say, for instance, "I don't use Smarty because for my 
purposes it's the same difference to just use a straight PHP approach" and 
to say "PHP already does exactly this, and thus Smarty is pointless."

And thank you for your guidance in regards to my conduct. Apparently you
also read the same things INTO my message to Justin, and thus it was okay
for a third person to take it to a personal level that was out of line and
when I merely respond to that unprovoked attack, you give me the lecture.

If someone has an issue with my tone, fine. I think that's a perception or
communication issue that can be dealt with by offline clarification, or
any number of other approaches. Going off the handle is not an appropriate
response, and I think even in my "defensive" response I showed Mr. Holmes
a level of decorum that was completely absent in his abusive message.

I see a lot of extremely snide messages on here, and yet, I posted an
opinionated, on-topic message that did not disrespect anyone--yet managed
to raise the dander of a small group--it's then ok with you if some guy
lets go with personal invective. But not okay for me to respond. Get real.

> I want to learn more about Smarty and it's obvious we have some great
> sources here to do so. Let's get past the snide remarks and keep focused
> on educating and discussing the merits of Smarty (or another templating
> engine) so that we all benefit.

Yes, PLEASE! I regretted having to send that message, but I did so for the
same reason I responded to this one. It was personally addressing me.

Learn to discern the difference between a passionate debate and personal
attacks (not that yours was an attack, but it was unnecessary to come in
and try to call the shots on an off-topic issue that was already dead).

Please, let's get on with the relevant discussion!

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] smarty

[Aaron Wolski]

> -Original Message-
> From: Kelly Hallman [mailto:[EMAIL PROTECTED] 
> Sent: April 7, 2004 11:51 PM
> To: John W. Holmes
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP] smarty
> 
> 
> Apr 7 at 10:22pm, John W. Holmes wrote:
> > > Uhhh, yeah--that's not templating, that's called spaghetti code :)
> > 
> > +1 - Use of buzzword
> 
> Right about here I could sense where this was going I 
> don't know, what would you call it? Is there a non-buzzword 
> term you'd be happier with?  
> That term predates PHP by a number of years, so I'm not sure 
> about buzz...
> 
> > > For a designer or non-coder, Smarty will be easier to learn than 
> > > PHP.
> > 
> > You must work with some real idiots.
> 
> Sigh... you must work with some really lousy designers!
> 
> > You can teach them to write {$variable} but you can't teach them to 
> > write  ?? Give your people some credit. If they can 
> > learn {section name="foo" loop=2 show=TRUE}{/section}, then 
> they can 
> > learn for($x=0;$x<2;$x++){ }, can't they??
> 
> Sure, they could. However, take a look at all the newbie 
> questions on this list. Maybe you've got time for all that 
> hand holding.. but Smarty is a lot closer to HTML, which many 
> of them already know.
> 
> > I'm sorry, but if Smarty takes your "template" and turns it 
> into code
> > like the example above, EXACTLY what "limitations" are you 
> going to run 
> > into using the method above that Smarty solves?
> 
> How about the limitation of lack of infinite time? Seriously 
> man, it's a tool. If you think that I was claiming Smarty 
> auto-magically did things you couldn't do with PHP, you need 
> to pay more attention...
> 
> > Fight it all you want, but PHP is a templating engine, too. That was
> > it's original purpose. And again, what "power" of Smarty 
> are we missing 
> > if Smarty just turns the template back into PHP code, anyhow?
> 
> Fight what? If you call inline code and variables a 
> templating engine, I can see why you don't get it. PHP can 
> serve a templating purpose, but it doesn't greatly facilitate 
> that out of the box. It's not a strategy.
> 
> I don't want to get into a tit-for-tat, but there are a lot 
> of things that Smarty makes much easier and more flexible 
> than coding straight PHP:
> 
> The ease of developing and applying different types of 
> template plugins, the ability to dynamically attach arbitrary 
> functions as template plugins, extending the Smarty class to 
> encapsulate methods to control more complex 
> template functionalities.. the list goes on..
> 
> Please read the next sentence twice. You can do it all with 
> plain PHP, but I can do it much faster with Smarty, which is 
> merely a TOOL.
> 
> > > In other words: are your template designers already good PHP 
> > > programmers? It's not just hype, it solves real problems, even if 
> > > you don't have them.
> > 
> > You can either teach your designers the Smarty language or you can 
> > teach
> > them PHP. Which one will set them up for success?
> 
> Again, very much not the point.
> 
> > Now, all that being said, I am a fan of Smarty and use it in some 
> > applications. But, there's no reason you can't use straight PHP and 
> > achieve the same results by simply separating presentation 
> logic from 
> > your code.
> 
> It's clear you're just trying to be antagonistic, so I won't 
> beleaguer the point. I have a strong understanding of PHP, 
> and I myself find Smarty easier to work with from a template 
> design standpoint.
> 
> Please feel free to call me a total idiot, question my 
> intelligence, belittle me or the people I work with, and 
> other side topics relating to the technical merits of Smarty 
> or the use of templating systems.
> 
> I found it really educational and enriching.
> Thanks for your contribution.
> 
> 
> PS: I think this is tired at this point; thank you to Justin 
> for a thoughtful response that reassured me it was still a 
> discussion. I realize that many PHP 'experts' (let's call 
> them) may find different solutions that suit them 
> differently. People have different levels and different 
> needs. I personally like Smarty, and Smarty was the original 
> topic of the thread. I'm open to ideas, but going back to 
> mixing PHP and HTML is not a new idea nor a true templating 
> system, and there are valid reasons I sought out a more 
> comprehensive 

Re: [PHP] smarty

[Richard Harb]

Well, I can't say that it's a 'good' tutorial, it's a little messy,
but it's along the lines of how I am using it ... If you want to have
a look, I put together a page and some explanations and stuffed it
into an archive (162Kb) You can downlad it at
http://www.wegotit.at/sm_demo.zip

If you're going to look at it, drop me a line to let me know if it's
too confusing or if you could actually make something out of it :)

Richard

Thursday, April 8, 2004, 9:11:06 AM, you wrote:


> Does anyone have a 'good' tutorial about Smarty. The one
> available on smarty.php.net is really basic...


> Vincent


> -Original Message-
> From: Robert Cummings [mailto:[EMAIL PROTECTED]
> Sent: jeudi 8 avril 2004 4:02
> To: Kelly Hallman
> Cc: PHP-General
> Subject: Re: [PHP] smarty


> On Wed, 2004-04-07 at 21:35, Kelly Hallman wrote:
>> Apr 8 at 10:26am, Justin French wrote:
>> > PHP itself is a great templating language :)
>> > 
>> > 
>> > 
>> >  
>> > 
>> > 
>> > > href='mailto:'>
>> > 
>> 
>> Uhhh, yeah--that's not a templating, that's called spaghetti code :)
>> 
>> You get the concept. Smarty, as you know, basically takes a Smarty
>> template and writes PHP code similar to what you've done above, then
>> writes out the .php file, and includes it when you render your template.
>> So you'd get nearly the same effect by writing the PHP as a separate file
>> and including it as your last step, and it acts as your display logic.
>> 
>> That may be acceptable to you, as a PHP programmer. If you're the only one
>> who ever needs to modify your templates then that's great, more power to
>> you. I'm sure that you would have no problem having many levels of nesting
>> all over the place and not screwing anything up. So be it. But that's you.
>> 
>> I guarantee another person not as adept at PHP will screw that code up,
>> and there is less potential for that with a Smarty template. If you know
>> PHP as well as yourself, it should be plain to see how Smarty is just a
>> wrapper over PHP that makes templates easier to build and maintain.
>> For a designer or non-coder, Smarty will be easier to learn than PHP.
>>  
>> Unless your needs never exceed the very basics like you have demonstrated
>> above, you'll be hosed when another person needs to modify your template.
>> Which goes back to a templating truism never in dispute: if this is all
>> you want templating for, it's six of one, half a dozen of the other.
>> 
>> However, there are practical limitations on what you can easily accomplish
>> with this approach, and Smarty addresses those issues. And you're worse
>> off if you invest a lot into building your sites this way, and then
>> realize you need some better templating strategies later.
>> 
>> > You can still separate your logic from your presentation, template
>> > designers can still use quick, simple "tags" to include code, and the
>> > upside is that people familiar with PHP don't need to learn ANOTHER
>> > language (that's what Smarty is) -- they can dive straight in.
>> 
>> You can consider it it's own language, but really it's more like PHP with
>> different formatting. Which is why it's different than what you're doing
>> above--it's designed to facilitate templating. Your method is just poking
>> in variables and PHP into inline'd HTML. It works, but you're missing some
>> of the power of Smarty if you think that's all it's good for.
>> 
>> > The question is, do you want to give your templater designers full
>> > access to the power of PHP, or not.
>> 
>> In other words: are your template designers already good PHP programmers?
>> It's not just hype, it solves real problems, even if you don't have them.

> Smarty is a bit of a hack too... why do I need to declare my templates
> within the PHP code? If I'm an HTML designer I'd like to create a new
> page, include templates, use some data that's been made available and
> have it all in the template. I sure as heck wouldn't want to have joe
> programmer edit the main page, add support for importing my template.
> This is the thing that bugs me about Smarty, its still got that hanging
> dependency. And it's still got to include all those templates within the
> source code.

> InterJinn is superior in this respect. You use XML tags to import other
> templates, you use XML tags to load modules and componen

RE: [PHP] smarty

[Vincent DUPONT]

Does anyone have a 'good' tutorial about Smarty. The one available on smarty.php.net 
is really basic...


Vincent


-Original Message-
From: Robert Cummings [mailto:[EMAIL PROTECTED]
Sent: jeudi 8 avril 2004 4:02
To: Kelly Hallman
Cc: PHP-General
Subject: Re: [PHP] smarty


On Wed, 2004-04-07 at 21:35, Kelly Hallman wrote:
> Apr 8 at 10:26am, Justin French wrote:
> > PHP itself is a great templating language :)
> > 
> > 
> > 
> >  
> > 
> > 
> > '>
> > 
> 
> Uhhh, yeah--that's not a templating, that's called spaghetti code :)
> 
> You get the concept. Smarty, as you know, basically takes a Smarty
> template and writes PHP code similar to what you've done above, then
> writes out the .php file, and includes it when you render your template.
> So you'd get nearly the same effect by writing the PHP as a separate file
> and including it as your last step, and it acts as your display logic.
> 
> That may be acceptable to you, as a PHP programmer. If you're the only one
> who ever needs to modify your templates then that's great, more power to
> you. I'm sure that you would have no problem having many levels of nesting
> all over the place and not screwing anything up. So be it. But that's you.
> 
> I guarantee another person not as adept at PHP will screw that code up,
> and there is less potential for that with a Smarty template. If you know
> PHP as well as yourself, it should be plain to see how Smarty is just a
> wrapper over PHP that makes templates easier to build and maintain.
> For a designer or non-coder, Smarty will be easier to learn than PHP.
>  
> Unless your needs never exceed the very basics like you have demonstrated
> above, you'll be hosed when another person needs to modify your template.  
> Which goes back to a templating truism never in dispute: if this is all
> you want templating for, it's six of one, half a dozen of the other.
> 
> However, there are practical limitations on what you can easily accomplish
> with this approach, and Smarty addresses those issues. And you're worse
> off if you invest a lot into building your sites this way, and then
> realize you need some better templating strategies later.
> 
> > You can still separate your logic from your presentation, template 
> > designers can still use quick, simple "tags" to include code, and the 
> > upside is that people familiar with PHP don't need to learn ANOTHER 
> > language (that's what Smarty is) -- they can dive straight in.
> 
> You can consider it it's own language, but really it's more like PHP with
> different formatting. Which is why it's different than what you're doing
> above--it's designed to facilitate templating. Your method is just poking
> in variables and PHP into inline'd HTML. It works, but you're missing some
> of the power of Smarty if you think that's all it's good for.
> 
> > The question is, do you want to give your templater designers full 
> > access to the power of PHP, or not.
> 
> In other words: are your template designers already good PHP programmers?
> It's not just hype, it solves real problems, even if you don't have them.

Smarty is a bit of a hack too... why do I need to declare my templates
within the PHP code? If I'm an HTML designer I'd like to create a new
page, include templates, use some data that's been made available and
have it all in the template. I sure as heck wouldn't want to have joe
programmer edit the main page, add support for importing my template.
This is the thing that bugs me about Smarty, its still got that hanging
dependency. And it's still got to include all those templates within the
source code.

InterJinn is superior in this respect. You use XML tags to import other
templates, you use XML tags to load modules and components, and you use
XML tags to do almost any kind of expansion you want. Of course, you can
go ahead and use something else, InterJinn provides the ability to plug
in custom compilers. InterJinn compiles to PHP code, includes are
INCLUDED at compile time not at run time. So given this scheme anyone
working on the HTML is already familiar with the syntax... hard to go
wrong with:



Hell you can even overload HTML tags. Not only that but Interjinn allows
recursive includes of templates and source files, and these includes can
be relative to the outer nested template or source file. Furthermore,
there's nothing forcing the use of the InterJinn application layer so
InterJinn can be used entirely for it's templating features, in which
case it provides a faster resulting PHP page than using PHP include().

Cheers,
Rob.
-- 
.--

RE: [PHP] smarty

[Jason Sheets]

Some excellent points, however

Smarty makes it much easier to do certain tasks than doing it in strait PHP
and Smarty is extendable with PHP both directly and indirectly, you can
create Smarty modifiers and functions and if necessary write inline PHP
code.  

Web development has an hourly cost even when quoted per project, if I can
shave 2 hours of time off of a project I've saved the client $100 to $150 on
budget or increased my profit margin depending on the project and the
client.  Those two hours are also time that can be invested in polishing the
project or documenation, increasing the liklihood of an additional contract
with them.

Smarty is also open source so you aren't locked into a particular language,
if you don't like it you can change it or extend it easily.  You can change
quite a bit of its behavior including opening and closing delimiters, etc.

html_options is an excellent example of smarty functionality eliminating
several lines of code and several minutes of coding, sure you could
duplicate or implement the functionality in PHP but why re-invent the wheel.


Smarty also has the benefit of introducing template caching and some other
really powerful features that arne't available natively in PHP, you could
use some PEAR classes or other functionality or implement it yourself but
then you get into the whole re-inventing trap again.

In many ways Smarty helps turn PHP into an even faster rapid application
development platform for me resulting in more profit and a much more stable
platform to use for clients, resulting in fewer complaints and a lower
defect rate.

I think this conversation has resulted in quite a few good points on both
sides but has also exposed that most people already have a bias towards one
technique and are unlikely to be swayed to the other side until a business
need arises that forces it.

Jason

A really good example woul
-Original Message-
From: Justin French [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 07, 2004 9:02 PM
To: Kelly Hallman
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP] smarty

On 08/04/2004, at 11:35 AM, Kelly Hallman wrote:

> Apr 8 at 10:26am, Justin French wrote:
>> PHP itself is a great templating language :)  
>>   
>>   
>>   > href='mailto:'>
>> 
>
> Uhhh, yeah--that's not a templating, that's called spaghetti code :)

I fail to see the difference in complexity.  Taking an example straight form
the smarty docs:


{section name=mysec loop=$users}
{strip}

   {$users[mysec].name}
   {$users[mysec].phone}

{/strip}
{/section}


Looks the same to me as:




   
   




(yes, I wrote a cycle() function in about 30 seconds)

> I guarantee another person not as adept at PHP will screw that code 
> up, and there is less potential for that with a Smarty template. If 
> you know PHP as well as yourself, it should be plain to see how Smarty 
> is just a wrapper over PHP that makes templates easier to build and 
> maintain.
> For a designer or non-coder, Smarty will be easier to learn than PHP.

Not in my experience.  Smarty lies somewhere in between a programming
language and pseudo tags... In *my* experience training template
designers...
{section name=mysec loop=$users}
was more confusing than:


Your mileage may vary, of course, but that's not my point.


> Unless your needs never exceed the very basics like you have 
> demonstrated above, you'll be hosed when another person needs to 
> modify your template.
> Which goes back to a templating truism never in dispute: if this is 
> all you want templating for, it's six of one, half a dozen of the other.
>
> However, there are practical limitations on what you can easily 
> accomplish with this approach, and Smarty addresses those issues. And 
> you're worse off if you invest a lot into building your sites this 
> way, and then realize you need some better templating strategies 
> later.

WHAT??? Are you suggesting that smarty templates are MORE EXTENSIBLE than
straight PHP???

This is exactly my point.  If you run with Smarty, you're LOCKED IN to that
language virtually forever.  Anything Smarty can do, I can replicate with
PHP (obviously), plus a whole heap more.  Smarty adds a layer of limitations
and simplicity to your templates, but at huge
cost:

You're locked into a proprietary templating language.  When that language
fails to deliver everything you want/need, you have no where to go.

A agree Smarty is fantastic at imposing limitations on it's templates, but
this is it's strength AND it's weakness.

> You can consider it it's own language, but really it's more like PHP 
> with different formatting. Which is why it's different than what 
> you're doing above--it's designed to facilitate templating. Your 
> method is just poking 

Re: [PHP] smarty

[Kelly Hallman]

Apr 7 at 10:22pm, John W. Holmes wrote:
> > Uhhh, yeah--that's not templating, that's called spaghetti code :)
> 
> +1 - Use of buzzword

Right about here I could sense where this was going I don't know, what
would you call it? Is there a non-buzzword term you'd be happier with?  
That term predates PHP by a number of years, so I'm not sure about buzz...

> > For a designer or non-coder, Smarty will be easier to learn than PHP.
> 
> You must work with some real idiots.

Sigh... you must work with some really lousy designers!

> You can teach them to write {$variable} but you can't teach them to
> write  ?? Give your people some credit. If they can learn
> {section name="foo" loop=2 show=TRUE}{/section}, then they can learn
> for($x=0;$x<2;$x++){ }, can't they??

Sure, they could. However, take a look at all the newbie questions on this
list. Maybe you've got time for all that hand holding.. but Smarty is a
lot closer to HTML, which many of them already know.

> I'm sorry, but if Smarty takes your "template" and turns it into code 
> like the example above, EXACTLY what "limitations" are you going to run 
> into using the method above that Smarty solves?

How about the limitation of lack of infinite time? Seriously man, it's a
tool. If you think that I was claiming Smarty auto-magically did things
you couldn't do with PHP, you need to pay more attention...

> Fight it all you want, but PHP is a templating engine, too. That was 
> it's original purpose. And again, what "power" of Smarty are we missing 
> if Smarty just turns the template back into PHP code, anyhow?

Fight what? If you call inline code and variables a templating engine, I
can see why you don't get it. PHP can serve a templating purpose, but it
doesn't greatly facilitate that out of the box. It's not a strategy.

I don't want to get into a tit-for-tat, but there are a lot of things that
Smarty makes much easier and more flexible than coding straight PHP:

The ease of developing and applying different types of template plugins,
the ability to dynamically attach arbitrary functions as template plugins,
extending the Smarty class to encapsulate methods to control more complex 
template functionalities.. the list goes on..

Please read the next sentence twice. You can do it all with plain PHP, but
I can do it much faster with Smarty, which is merely a TOOL.

> > In other words: are your template designers already good PHP programmers?
> > It's not just hype, it solves real problems, even if you don't have them.
> 
> You can either teach your designers the Smarty language or you can teach 
> them PHP. Which one will set them up for success?

Again, very much not the point.

> Now, all that being said, I am a fan of Smarty and use it in some
> applications. But, there's no reason you can't use straight PHP and
> achieve the same results by simply separating presentation logic from
> your code.

It's clear you're just trying to be antagonistic, so I won't beleaguer the
point. I have a strong understanding of PHP, and I myself find Smarty
easier to work with from a template design standpoint.

Please feel free to call me a total idiot, question my intelligence,
belittle me or the people I work with, and other side topics relating to
the technical merits of Smarty or the use of templating systems.

I found it really educational and enriching.
Thanks for your contribution.


PS: I think this is tired at this point; thank you to Justin for a
thoughtful response that reassured me it was still a discussion. I realize
that many PHP 'experts' (let's call them) may find different solutions
that suit them differently. People have different levels and different
needs. I personally like Smarty, and Smarty was the original topic of the
thread. I'm open to ideas, but going back to mixing PHP and HTML is not a
new idea nor a true templating system, and there are valid reasons I
sought out a more comprehensive approaches after doing it that way for
many years. I found much benefit in Smarty, and hope others will too.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Justin French]

On 08/04/2004, at 11:35 AM, Kelly Hallman wrote:

Apr 8 at 10:26am, Justin French wrote:
PHP itself is a great templating language :)



 


'>

Uhhh, yeah--that's not a templating, that's called spaghetti code :)
I fail to see the difference in complexity.  Taking an example straight 
form the smarty docs:


{section name=mysec loop=$users}
{strip}
   
  {$users[mysec].name}
  {$users[mysec].phone}
   
{/strip}
{/section}

Looks the same to me as:



   
  
  
   


(yes, I wrote a cycle() function in about 30 seconds)

I guarantee another person not as adept at PHP will screw that code up,
and there is less potential for that with a Smarty template. If you 
know
PHP as well as yourself, it should be plain to see how Smarty is just a
wrapper over PHP that makes templates easier to build and maintain.
For a designer or non-coder, Smarty will be easier to learn than PHP.
Not in my experience.  Smarty lies somewhere in between a programming 
language and pseudo tags... In *my* experience training template 
designers...
	{section name=mysec loop=$users}
was more confusing than:
	

Your mileage may vary, of course, but that's not my point.


Unless your needs never exceed the very basics like you have 
demonstrated
above, you'll be hosed when another person needs to modify your 
template.
Which goes back to a templating truism never in dispute: if this is all
you want templating for, it's six of one, half a dozen of the other.

However, there are practical limitations on what you can easily 
accomplish
with this approach, and Smarty addresses those issues. And you're worse
off if you invest a lot into building your sites this way, and then
realize you need some better templating strategies later.
WHAT??? Are you suggesting that smarty templates are MORE EXTENSIBLE 
than straight PHP???

This is exactly my point.  If you run with Smarty, you're LOCKED IN to 
that language virtually forever.  Anything Smarty can do, I can 
replicate with PHP (obviously), plus a whole heap more.  Smarty adds a 
layer of limitations and simplicity to your templates, but at huge 
cost:

You're locked into a proprietary templating language.  When that 
language fails to deliver everything you want/need, you have no where 
to go.

A agree Smarty is fantastic at imposing limitations on it's templates, 
but this is it's strength AND it's weakness.

You can consider it it's own language, but really it's more like PHP 
with
different formatting. Which is why it's different than what you're 
doing
above--it's designed to facilitate templating. Your method is just 
poking
in variables and PHP into inline'd HTML. It works, but you're missing 
some
of the power of Smarty if you think that's all it's good for.
I agree, there's more to smarty, but in the end, it's just an interface 
to PHP -- eventually you will hit the wall with the functionality that 
the interface allows.  Pure PHP templates however will only ever be 
limited by PHP itself.

In other words: are your template designers already good PHP 
programmers?
It's not just hype, it solves real problems, even if you don't have 
them.
As stated, this was not a problem for me, but it IS a problem for some. 
 Smarty is not a solution to every world problem.  It has it's place 
for sure, but I felt the need to point out that PHP alone is a great 
templating language, with limitless functionality.

It's up to the OP to take this thread and decide what he/she will do 
next.

---
Justin French
http://indent.com.au
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Kelly Hallman]

Apr 7 at 10:01pm, Robert Cummings wrote:
> Smarty is a bit of a hack too... why do I need to declare my templates
> within the PHP code? If I'm an HTML designer I'd like to create a new
> page, include templates, use some data that's been made available and
> have it all in the template. I sure as heck wouldn't want to have joe
> programmer edit the main page, add support for importing my template.

I like Smarty because it solved many of the problems I was having trying
to tackle the problems manifest when using no templating strategy.

Actually, InterJinn has been on my radar screen for a while now, and 
thanks to your timely plug, I think I'll try it out and see how it 
compares. Incidentally, your posts on the Smarty list are what had me 
considering InterJinn in the first place.. how subversive of you! :)

I'm not married to Smarty, I just think that it's got a lot more to offer
than many PHP coders give it credit for after a mere cursory evaluation.  
Further, many of the people who shun templating systems aren't really
working with web applications as much as simple PHP scripts, where
templating solutions are much less necessary.

I think we're on the same side. Perhaps I just haven't yet seen the light.  
I'll give InterJinn a go. I hope it's all you say it is. One thing we can
both agree on is that templating is not inherently redundant with PHP.

--Kelly

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[John W. Holmes]

Kelly Hallman wrote:
Apr 8 at 10:26am, Justin French wrote:

PHP itself is a great templating language :)



 


'>



Uhhh, yeah--that's not a templating, that's called spaghetti code :)
+1 - Use of buzzword

You get the concept. Smarty, as you know, basically takes a Smarty
template and writes PHP code similar to what you've done above, then
writes out the .php file, and includes it when you render your template.
So you'd get nearly the same effect by writing the PHP as a separate file
and including it as your last step, and it acts as your display logic.
That may be acceptable to you, as a PHP programmer. If you're the only one
who ever needs to modify your templates then that's great, more power to
you. I'm sure that you would have no problem having many levels of nesting
all over the place and not screwing anything up. So be it. But that's you.
I guarantee another person not as adept at PHP will screw that code up,
and there is less potential for that with a Smarty template. If you know
PHP as well as yourself, it should be plain to see how Smarty is just a
wrapper over PHP that makes templates easier to build and maintain.
For a designer or non-coder, Smarty will be easier to learn than PHP.
You must work with some real idiots. You can teach them to write 
{$variable} but you can't teach them to write  ?? Give 
your people some credit. If they can learn {section name="foo" loop=2 
show=TRUE}{/section}, then they can learn for($x=0;$x<2;$x++){ }, can't 
they??

However, there are practical limitations on what you can easily accomplish
with this approach, and Smarty addresses those issues. And you're worse
off if you invest a lot into building your sites this way, and then
realize you need some better templating strategies later.
I'm sorry, but if Smarty takes your "template" and turns it into code 
like the example above, EXACTLY what "limitations" are you going to run 
into using the method above that Smarty solves?

You can still separate your logic from your presentation, template 
designers can still use quick, simple "tags" to include code, and the 
upside is that people familiar with PHP don't need to learn ANOTHER 
language (that's what Smarty is) -- they can dive straight in.
You can consider it it's own language, but really it's more like PHP with
different formatting. Which is why it's different than what you're doing
above--it's designed to facilitate templating. Your method is just poking
in variables and PHP into inline'd HTML. It works, but you're missing some
of the power of Smarty if you think that's all it's good for.
Fight it all you want, but PHP is a templating engine, too. That was 
it's original purpose. And again, what "power" of Smarty are we missing 
if Smarty just turns the template back into PHP code, anyhow?

The question is, do you want to give your templater designers full 
access to the power of PHP, or not.


In other words: are your template designers already good PHP programmers?
It's not just hype, it solves real problems, even if you don't have them.
You can either teach your designers the Smarty language or you can teach 
them PHP. Which one will set them up for success?

Now, all that being said, I am a fan of Smarty and use it in some 
applications. But, there's no reason you can't use straight PHP and 
achieve the same results by simply separating presentation logic from 
your code.

--
---John Holmes...
Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/

php|architect: The Magazine for PHP Professionals – www.phparch.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Robert Cummings]

On Wed, 2004-04-07 at 21:35, Kelly Hallman wrote:
> Apr 8 at 10:26am, Justin French wrote:
> > PHP itself is a great templating language :)
> > 
> > 
> > 
> >  
> > 
> > 
> > '>
> > 
> 
> Uhhh, yeah--that's not a templating, that's called spaghetti code :)
> 
> You get the concept. Smarty, as you know, basically takes a Smarty
> template and writes PHP code similar to what you've done above, then
> writes out the .php file, and includes it when you render your template.
> So you'd get nearly the same effect by writing the PHP as a separate file
> and including it as your last step, and it acts as your display logic.
> 
> That may be acceptable to you, as a PHP programmer. If you're the only one
> who ever needs to modify your templates then that's great, more power to
> you. I'm sure that you would have no problem having many levels of nesting
> all over the place and not screwing anything up. So be it. But that's you.
> 
> I guarantee another person not as adept at PHP will screw that code up,
> and there is less potential for that with a Smarty template. If you know
> PHP as well as yourself, it should be plain to see how Smarty is just a
> wrapper over PHP that makes templates easier to build and maintain.
> For a designer or non-coder, Smarty will be easier to learn than PHP.
>  
> Unless your needs never exceed the very basics like you have demonstrated
> above, you'll be hosed when another person needs to modify your template.  
> Which goes back to a templating truism never in dispute: if this is all
> you want templating for, it's six of one, half a dozen of the other.
> 
> However, there are practical limitations on what you can easily accomplish
> with this approach, and Smarty addresses those issues. And you're worse
> off if you invest a lot into building your sites this way, and then
> realize you need some better templating strategies later.
> 
> > You can still separate your logic from your presentation, template 
> > designers can still use quick, simple "tags" to include code, and the 
> > upside is that people familiar with PHP don't need to learn ANOTHER 
> > language (that's what Smarty is) -- they can dive straight in.
> 
> You can consider it it's own language, but really it's more like PHP with
> different formatting. Which is why it's different than what you're doing
> above--it's designed to facilitate templating. Your method is just poking
> in variables and PHP into inline'd HTML. It works, but you're missing some
> of the power of Smarty if you think that's all it's good for.
> 
> > The question is, do you want to give your templater designers full 
> > access to the power of PHP, or not.
> 
> In other words: are your template designers already good PHP programmers?
> It's not just hype, it solves real problems, even if you don't have them.

Smarty is a bit of a hack too... why do I need to declare my templates
within the PHP code? If I'm an HTML designer I'd like to create a new
page, include templates, use some data that's been made available and
have it all in the template. I sure as heck wouldn't want to have joe
programmer edit the main page, add support for importing my template.
This is the thing that bugs me about Smarty, its still got that hanging
dependency. And it's still got to include all those templates within the
source code.

InterJinn is superior in this respect. You use XML tags to import other
templates, you use XML tags to load modules and components, and you use
XML tags to do almost any kind of expansion you want. Of course, you can
go ahead and use something else, InterJinn provides the ability to plug
in custom compilers. InterJinn compiles to PHP code, includes are
INCLUDED at compile time not at run time. So given this scheme anyone
working on the HTML is already familiar with the syntax... hard to go
wrong with:



Hell you can even overload HTML tags. Not only that but Interjinn allows
recursive includes of templates and source files, and these includes can
be relative to the outer nested template or source file. Furthermore,
there's nothing forcing the use of the InterJinn application layer so
InterJinn can be used entirely for it's templating features, in which
case it provides a faster resulting PHP page than using PHP include().

Cheers,
Rob.
-- 
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for   |
| creating re-usable components quickly and easily.  |
`'

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Kelly Hallman]

Apr 8 at 10:26am, Justin French wrote:
> PHP itself is a great templating language :)
> 
> 
> 
>  
> 
> 
> '>
> 

Uhhh, yeah--that's not a templating, that's called spaghetti code :)

You get the concept. Smarty, as you know, basically takes a Smarty
template and writes PHP code similar to what you've done above, then
writes out the .php file, and includes it when you render your template.
So you'd get nearly the same effect by writing the PHP as a separate file
and including it as your last step, and it acts as your display logic.

That may be acceptable to you, as a PHP programmer. If you're the only one
who ever needs to modify your templates then that's great, more power to
you. I'm sure that you would have no problem having many levels of nesting
all over the place and not screwing anything up. So be it. But that's you.

I guarantee another person not as adept at PHP will screw that code up,
and there is less potential for that with a Smarty template. If you know
PHP as well as yourself, it should be plain to see how Smarty is just a
wrapper over PHP that makes templates easier to build and maintain.
For a designer or non-coder, Smarty will be easier to learn than PHP.
 
Unless your needs never exceed the very basics like you have demonstrated
above, you'll be hosed when another person needs to modify your template.  
Which goes back to a templating truism never in dispute: if this is all
you want templating for, it's six of one, half a dozen of the other.

However, there are practical limitations on what you can easily accomplish
with this approach, and Smarty addresses those issues. And you're worse
off if you invest a lot into building your sites this way, and then
realize you need some better templating strategies later.

> You can still separate your logic from your presentation, template 
> designers can still use quick, simple "tags" to include code, and the 
> upside is that people familiar with PHP don't need to learn ANOTHER 
> language (that's what Smarty is) -- they can dive straight in.

You can consider it it's own language, but really it's more like PHP with
different formatting. Which is why it's different than what you're doing
above--it's designed to facilitate templating. Your method is just poking
in variables and PHP into inline'd HTML. It works, but you're missing some
of the power of Smarty if you think that's all it's good for.

> The question is, do you want to give your templater designers full 
> access to the power of PHP, or not.

In other words: are your template designers already good PHP programmers?
It's not just hype, it solves real problems, even if you don't have them.

--Kelly

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] smarty

[Jason Sheets]

I can see your point and have used this technique in very small applications
where the benefit of Smarty or other template engines are negated by the
performance/resource usage overhead.

However intermixing markup and PHP has introduced many problems in too many
PHP projects for me to use this technique in very many applications I have
to support.  Additionally the usage of mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 07, 2004 6:26 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP] smarty

On 07/04/2004, at 1:33 AM, Angelo Zanetti wrote:

> hi all has anyone used smarty before? what do you think of it? I think 
> it's pretty nice to seperate your script (code) from your design.
>
> i would like to hear your comments and if you have any alternatives 
> let me know.

PHP itself is a great templating language :)





 


'>




You can still separate your logic from your presentation, template designers
can still use quick, simple "tags" to include code, and the upside is that
people familiar with PHP don't need to learn ANOTHER language (that's what
Smarty is) -- they can dive straight in.

The question is, do you want to give your templater designers full access to
the power of PHP, or not.  In my case, I did.


Justin

---
Justin French
http://indent.com.au

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Justin French]

On 07/04/2004, at 1:33 AM, Angelo Zanetti wrote:

hi all has anyone used smarty before? what do you think of it? I think 
it's
pretty nice to seperate your script (code) from your design.

i would like to hear your comments and if you have any alternatives 
let me
know.
PHP itself is a great templating language :)





 


'>



You can still separate your logic from your presentation, template 
designers can still use quick, simple "tags" to include code, and the 
upside is that people familiar with PHP don't need to learn ANOTHER 
language (that's what Smarty is) -- they can dive straight in.

The question is, do you want to give your templater designers full 
access to the power of PHP, or not.  In my case, I did.

Justin

---
Justin French
http://indent.com.au
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[John W. Holmes]

From: "Chris de Vidal" <[EMAIL PROTECTED]>

> Or are you saying:
> $pt = new MyPage;
> $pt->render('contact.tpl');
> OR
> $pt = new MyPage;
> $pt ->render('prices.tpl');
> OR
> $pt = new MyPage;
> $pt->render('index.tpl');
> 
> I can see the benefit of this method if that's what you mean.

That's what I meant. :) I guess I was too consise. 

---John Holmes...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Jochem Maas]

Chris W. Parker wrote:
Chris de Vidal 
on Tuesday, April 06, 2004 11:43 AM said:

I could have put a tag in the template like {bio} but that'd mean
maintaining HTML in the PHP code which I wanted to avoid (left the
"prettyness" to the Front Page developer).  Instead, I put something
like this in the template:
{if $level > 2}
{bio}
{/if}


i've never used smarty* but i think i understand how it works. so my
question is this...
would it not be better to place that logic in your php code instead of
your template?
what you suggest is handy for situations where you want to limit access 
to anything remotely programmy from users/designers who have no 
understanding/experience etc (or who use tools like FrontPage...yuck!)
(Maybe DreamWeaver is a better option, has better HTML output/processing 
and can be made to work nicely with Smarty templates.)

BUT...

It's probably important to understand that templating is really about 
the seperation of presentation & application/business logic in order to 
allow, for example, better task seperation (interface/graphic designers 
edit templates and programmers edit PHP files) and not about the 
seperation of code & content (or HTML & PHP or somesuch): it is true 
that most ('so called' -- not all are really template engines) allow you 
to also seperate the HTML & PHP.

bare this in mind: PHP is also a templating engine! image 1 file which 
does calculation, DB transactions and setting output variables and 
another file which outputs HTML according to logic that reacts to the 
values of the output variables.

to me performance is second to everything else (I prefer slow code thats 
well documented, loosely coupled* and easily extentable to super fast 
unreadable tightly coupled code) - first make it do what you need it to 
do! you can always optimize later and if the code is still not fast 
enough then code accelerators (like the ZendAccelerator or PHPa) and 
faster hardware probably offer the cheapest (and mostly quickly 
implemented) performance boost.

I think Smarty is a really good tool and very well supported & 
documented. I have run into limitations regarding PHP5 dereferenced 
object syntax and static object call syntax which led me to investigate 
the template parsing mechanism of Smarty - I found regular expressions 
which exceeded 1000 chars in length!! this I found to be a little 
worrying, none the less Smarty is still faster & I see very little 
slowdown even when forcing a recompile on every page hit as opposed to 
not using Smarty at all.

I hope that adds to you understanding a bit. If anything is unclear or I 
have stated something that is incorrect I'd love to hear about it -- 
always looking to learn more about stuff, especially PHP!

Jochem

--
*coupling refers to the level of interdependency of various elements 
with you application. using Smarty _allows_ you to loosen the coupling 
between business & presentation logic (you can technically write all 
your business logic in Smarty templates but that is ill-advised) by 
creating a std API for transfering data from one layer to the next.

my thinking is this: if {bio} contains anything, it will print to the
page. if it doesn't contain anything, nothing will be printed. so
there's no need to check the value of $level within the template since
{bio} will simply contain something, or it will not.
i'm purely looking to understand this "smarty" thing a little better. :)

chris.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Chris de Vidal]

John W. Holmes said:
> From: "Chris de Vidal" <[EMAIL PROTECTED]>
>> Kelly Hallman said:
>> > Going even one step further (the beauty of Smarty: always another
> level),
>> > just extend the Smarty object itself. Then, instead of making all your
>> > templates includes other templates (such as a header or a footer), you
> can
>> > make your overall page be a template, and the extended Smarty object
>> can
>> > be given extra functionality to control the page:
>> >
>> > {* MyPage.tpl -- Smarty template for the entire page *}
>> > ...header...
>> > {include file=$content}
>> > ...footer...
>> >
>> > // mypage.php -- extended Smarty object
>> > class MyPage extends Smarty {
>> >var $tmpl = 'MyPage.tpl';
>> >function render($x) {
>> >   $this->assign('content',$x);
>> >   $this->display($this->tmpl); } }
>> >
>> > // actualphpcode.php -- called by the browser
>> > $pt = new MyPage;
>> > $pt->render('pagecontent.tpl');
>>
>> Sorry, I'm feeling better now but still don't understand what you're
>> telling me/us.  Could you please expound?  What functionality does this
>> afford?
>
> If I can take first shot, since this was posted to the list... :)

No!!!  Well, OK.  :)

> It's basically a wrapper around Smarty to automatically load the
> header-content-footer template and dynamically fill in the content based
> on what's passed to render. So, displaying all of your different pages
> would be as simple as:
>
> $pt = new MyPage;
> $pt->render('contact.tpl');
>
> $pt ->render('prices.tpl');
>
> $pt->render('index.tpl');
>
> etc... The "wrapper" automatically loads the "master" template with the
> header and footer, and then replaces the {content} tag with the content of
> the appropriate template that render() was passed.
>
> Just one method of many. If I'm interpreting it right, that is. :)

Ahh OK, that makes sense, 'cept now you've introduced new confusion
(sorry, I must be dense today).  What's with loading all of your pages
(contact/prices/index) in one page?

Or are you saying:
$pt = new MyPage;
$pt->render('contact.tpl');
OR
$pt = new MyPage;
$pt ->render('prices.tpl');
OR
$pt = new MyPage;
$pt->render('index.tpl');

I can see the benefit of this method if that's what you mean.

Thanks for helping clarify it,
/dev/idal

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[John W. Holmes]

From: "Chris de Vidal" <[EMAIL PROTECTED]>

> Kelly Hallman said:
> > Going even one step further (the beauty of Smarty: always another
level),
> > just extend the Smarty object itself. Then, instead of making all your
> > templates includes other templates (such as a header or a footer), you
can
> > make your overall page be a template, and the extended Smarty object can
> > be given extra functionality to control the page:
> >
> > {* MyPage.tpl -- Smarty template for the entire page *}
> > ...header...
> > {include file=$content}
> > ...footer...
> >
> > // mypage.php -- extended Smarty object
> > class MyPage extends Smarty {
> >var $tmpl = 'MyPage.tpl';
> >function render($x) {
> >   $this->assign('content',$x);
> >   $this->display($this->tmpl); } }
> >
> > // actualphpcode.php -- called by the browser
> > $pt = new MyPage;
> > $pt->render('pagecontent.tpl');
>
> Sorry, I'm feeling better now but still don't understand what you're
> telling me/us.  Could you please expound?  What functionality does this
> afford?

If I can take first shot, since this was posted to the list... :)

It's basically a wrapper around Smarty to automatically load the
header-content-footer template and dynamically fill in the content based on
what's passed to render. So, displaying all of your different pages would be
as simple as:

$pt = new MyPage;
$pt->render('contact.tpl');

$pt ->render('prices.tpl');

$pt->render('index.tpl');

etc... The "wrapper" automatically loads the "master" template with the
header and footer, and then replaces the {content} tag with the content of
the appropriate template that render() was passed.

Just one method of many. If I'm interpreting it right, that is. :)

---John Holmes...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Chris de Vidal]

Kelly Hallman said:
> Going even one step further (the beauty of Smarty: always another level),
> just extend the Smarty object itself. Then, instead of making all your
> templates includes other templates (such as a header or a footer), you can
> make your overall page be a template, and the extended Smarty object can
> be given extra functionality to control the page:
>
> {* MyPage.tpl -- Smarty template for the entire page *}
> ...header...
> {include file=$content}
> ...footer...
>
> // mypage.php -- extended Smarty object
> class MyPage extends Smarty {
>var $tmpl = 'MyPage.tpl';
>function render($x) {
>   $this->assign('content',$x);
>   $this->display($this->tmpl); } }
>
> // actualphpcode.php -- called by the browser
> $pt = new MyPage;
> $pt->render('pagecontent.tpl');

Sorry, I'm feeling better now but still don't understand what you're
telling me/us.  Could you please expound?  What functionality does this
afford?

/dev/idal

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] smarty

[Jason Sheets]

I use Smarty for most of my commericial and non commercial websites, it
makes it very easy to share and re-use code because the appliciation logic
is separate from the presentation logic.

It also makes it possible to encode the scripts using Zend Encoder, Turck
MMCache or similar projects which leaving the site owner the ability to
change their template files where encoding scripts that contained the HTML
inline would make this impossible. I use PHPDocumentor to give them API
documentation so they can add additional pages, functionality to their site
whether it has been encoded or not.

It also keeps people out of where they shouldn't be (for example users tend
to introduce parse errors when editing PHP files) and gives them an easy to
understand interface to their site.
I also use Smarty template caching, and end user caching and output
compression, resulting in lightening fast websites for the user on most
internet connections.

I've tried other templating engines including FastTemplate and haven't been
as impressed as I am with Smarty, of course the power comes with the price
that you are slowing execution slightly but the increased development speed
and other benefits usually outweigh the costs in my case.

Jason
-Original Message-
From: Angelo Zanetti [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 06, 2004 9:33 AM
To: [EMAIL PROTECTED]
Subject: [PHP] smarty

hi all has anyone used smarty before? what do you think of it? I think it's
pretty nice to seperate your script (code) from your design.

i would like to hear your comments and if you have any alternatives let me
know.

Angelo


Disclaimer
This e-mail transmission contains confidential information, which is the
property of the sender.
The information in this e-mail or attachments thereto is intended for the
attention and use only of the addressee. 
Should you have received this e-mail in error, please delete and destroy it
and any attachments thereto immediately. 
Under no circumstances will the Cape Technikon or the sender of this e-mail
be liable to any party for any direct, indirect, special or other
consequential damages for any use of this e-mail.
For the detailed e-mail disclaimer please refer to
http://www.ctech.ac.za/polic or call +27 (0)21 460 3911

--
PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Chris de Vidal]

John W. Holmes said:
>> I could have put a tag in the template like {bio} but that'd mean
>> maintaining HTML in the PHP code which I wanted to avoid (left the
>> "prettyness" to the Front Page developer).  Instead, I put something
>> like
>> this in the template:
>> {if $level > 2}
>>  {bio}
>> {/if}
>
> Rather than putting "logic" into your presentation layer, the whole "bio"
> content should be a separate template. You then make the decision to
> either
> load the template into $bio or not from within PHP. So {$bio} will either
> be
> an empty string or the content of the other template, depending upon your
> PHP logic. And you still maintain the separation of "presentation" and
> "code"...

Why that would make too much sense ;-P  Yeah I think I see what you're
saying.

CD

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] smarty

[Chris de Vidal]

Chris W. Parker said:
>> I could have put a tag in the template like {bio} but that'd mean
>> maintaining HTML in the PHP code which I wanted to avoid (left the
>> "prettyness" to the Front Page developer).  Instead, I put something
>> like this in the template:
>> {if $level > 2}
>>  {bio}

I should have put
< html for bio or image or hyperlink >

The way I put it there it looks like Smarty template code.

>> {/if}
>
> i've never used smarty* but i think i understand how it works. so my
> question is this...
>
> would it not be better to place that logic in your php code instead of
> your template?
>
> my thinking is this: if {bio} contains anything, it will print to the
> page. if it doesn't contain anything, nothing will be printed. so
> there's no need to check the value of $level within the template since
> {bio} will simply contain something, or it will not.

I could, but bio/image/hyperlink has HTML that I want to leave for my
Front Page developer to be able to tweak.  I want her to make it pretty
and I just want to make it work.  When the PHP code also had HTML her
Front Page was constantly screwing with the code.

And now she can mock up a new website in whatever she wants (Word exported
to HTML for all I care) and I can hook in PHP code very easily.  Together
we can knock out nice-looking sites in far less time.

/dev/idal

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Chris de Vidal]

Kelly Hallman said:
> Apr 6 at 2:43pm, Chris de Vidal wrote:
>> Given that scripts are compiled the first time they're ran, you'll
>> never* notice the bloat and never lack performance; it's the same as
>> real PHP code and can be optimized with a caching engine like Zend.
>
> Certainly. However, the Smarty compiler is about 2200 lines of code, and
> the Smarty class itself (which does load every time) is about 2000. Both
> figures rounded up, and both files contain heaps of comments.

Ahh never thought about that.

> Still, many people consider this bloat, if they're merely wanting to
> search and replace a couple of values on an HTML template.

Yep, I was given something simple on this mailing list for this task. 
Looked perfect -- at first -- but I recognized I was going to need more
(if/then and loops) so I used Smarty instead.  But here is a very simple
template engine:
http://marc.theaimsgroup.com/?l=php-general&m=107644142420608&w=2

>> Instead, I put something like this in the template:
>> {if $level > 2}{bio}{/if}
>
> Again, take it a step further and you may just load up a $User object (of
> your design) within your PHP code. Then in the template, you could use:
>
> {if $User->hasPermission('write')} ... {/if}
>
> When you start thinking like this, your PHP logic gets very slim and easy
> to read and maintain. This is the goal and benefit of templating.

Sweet!

> It becomes especially powerful when working on a larger web app. You
> needn't assign your values into the template from each PHP page. You can
> make a boilerplate include and assign common variables as references:
>

>
> So you can attach references right off the bat in an include, then every
> time you use that include, you've already got things assigned and can
> change them all you want before displaying, without additional assignment.
>
> Going even one step further (the beauty of Smarty: always another level),
> just extend the Smarty object itself. Then, instead of making all your
> templates includes other templates (such as a header or a footer), you can
> make your overall page be a template, and the extended Smarty object can
> be given extra functionality to control the page:
>

>
> Now, is Smarty awesome, or what? :)

I don't quite understand what you're saying because I'm feeling ill at the
moment :-P so I'll have to try to comprehend it later.

But thanks for the enthusiasm!

/dev/idal

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[Kelly Hallman]

Apr 6 at 2:43pm, Chris de Vidal wrote:
> Given that scripts are compiled the first time they're ran, you'll
> never* notice the bloat and never lack performance; it's the same as
> real PHP code and can be optimized with a caching engine like Zend.

Certainly. However, the Smarty compiler is about 2200 lines of code, and
the Smarty class itself (which does load every time) is about 2000. Both
figures rounded up, and both files contain heaps of comments.  

Still, many people consider this bloat, if they're merely wanting to
search and replace a couple of values on an HTML template.

Those people are not really leveraging a template system, but if that's
all you wanted to do--ever--I can see why the additional overhead would be
undesirable. After all, a simple search and replace for a few values
doesn't require 4000 lines of code parsed (or 2000, after compilation).

> OK so you will notice it the first time and if you make any changes

Yes, and whenever your cached/compiled template has expired.

> For our next site, she'll mock up everything in Front Page how she wants
> it to look then I'll add template tags and business logic.  Whee!
> Separation of code from design, at last!

Working with others is one of the main benefits of a templating system. It 
doesn't matter then if it's FrontPage code or not, at least you, as the 
developer, don't have to muck with it. And it's easier to clean up later.

> It will be tempting to put all logic in the PHP but you might need some
> logic in the template; for example, we have a level check...

I'd go a step further and suggest using as much logic in the template as
possible. In a basic sense, it's display logic, not application logic.

> Instead, I put something like this in the template:
> {if $level > 2}{bio}{/if}

Again, take it a step further and you may just load up a $User object (of 
your design) within your PHP code. Then in the template, you could use:

{if $User->hasPermission('write')} ... {/if}

When you start thinking like this, your PHP logic gets very slim and easy 
to read and maintain. This is the goal and benefit of templating.

A common reaction when starting to work with Smarty is "you mean I need to
assign each variable into the template one-by-one?!" On a certain level
this is true. But as illustrated above, you can also pass arrays, objects
and other complex data structures into your template.

It becomes especially powerful when working on a larger web app. You
needn't assign your values into the template from each PHP page. You can
make a boilerplate include and assign common variables as references:

// boiler.php
$pt = new Smarty;
$pt->assign_by_ref('User',$User);

// mypage.php
require "boiler.php";
$User->doStuff();
$User->admin = true;
$pt->display('template.tpl');

So you can attach references right off the bat in an include, then every
time you use that include, you've already got things assigned and can
change them all you want before displaying, without additional assignment.

Going even one step further (the beauty of Smarty: always another level),
just extend the Smarty object itself. Then, instead of making all your
templates includes other templates (such as a header or a footer), you can
make your overall page be a template, and the extended Smarty object can 
be given extra functionality to control the page:

{* MyPage.tpl -- Smarty template for the entire page *}
...header...
{include file=$content}
...footer...

// mypage.php -- extended Smarty object
class MyPage extends Smarty {
   var $tmpl = 'MyPage.tpl';
   function render($x) {
  $this->assign('content',$x);
  $this->display($this->tmpl); } }

// actualphpcode.php -- called by the browser
$pt = new MyPage;
$pt->render('pagecontent.tpl');

Now, is Smarty awesome, or what? :)
--Kelly

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] smarty

[John W. Holmes]

From: "Chris de Vidal" <[EMAIL PROTECTED]>

> I could have put a tag in the template like {bio} but that'd mean
> maintaining HTML in the PHP code which I wanted to avoid (left the
> "prettyness" to the Front Page developer).  Instead, I put something like
> this in the template:
> {if $level > 2}
>  {bio}
> {/if}

Rather than putting "logic" into your presentation layer, the whole "bio"
content should be a separate template. You then make the decision to either
load the template into $bio or not from within PHP. So {$bio} will either be
an empty string or the content of the other template, depending upon your
PHP logic. And you still maintain the separation of "presentation" and
"code"...

---John Holmes...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] smarty

[Chris W. Parker]

Chris de Vidal 
on Tuesday, April 06, 2004 11:43 AM said:

> I could have put a tag in the template like {bio} but that'd mean
> maintaining HTML in the PHP code which I wanted to avoid (left the
> "prettyness" to the Front Page developer).  Instead, I put something
> like this in the template:
> {if $level > 2}
>  {bio}
> {/if}

i've never used smarty* but i think i understand how it works. so my
question is this...

would it not be better to place that logic in your php code instead of
your template?

my thinking is this: if {bio} contains anything, it will print to the
page. if it doesn't contain anything, nothing will be printed. so
there's no need to check the value of $level within the template since
{bio} will simply contain something, or it will not.

i'm purely looking to understand this "smarty" thing a little better. :)


chris.


* i did try it once or twice in the past, with little things but didn't
quite grasp it.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php