Re: [PHP] Re: smarty
pete M said: > Moving our sites to smarty is the best thing we've done at our company... Just a few weeks ago, I'd have agreed wit' yah, but now I see Smarty as mostly (not always) redundant. See my post where I learned that PHP makes a great templating engine: 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
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
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
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
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] Re: smarty
Justin French said: > You must remember, Smarty is just a layer over PHP. All the functions > that you've listed exist in pure PHP code somewhere. It would > relatively easy to code equivalent templates in PHP. > > Taking some random examples from your list: I believe Smarty users would say "Yeah but the Smarty functions are already written," which is when I'd use Smarty. There are countless thousands of PHP libraries/classes that can also be added to save writing functions from scratch. My point is that the templating feature of Smarty is largely (but not completely) redundant. /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] smarty
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] Re: smarty
pete M said: > We sit in front of a PC and mock up the forms/ pages/ nav bar etc.. That > stuff then gets coded. I agree, and I'm saying you can also do that with native PHP. I plan on doing that with the next site I build. Then if I see that it makes sense to use Smarty I will, but you can mock up an entire site in Microsoft Word and templatize it with normal PHP. I believe we'll work even faster because Smarty isn't "in the way." /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: smarty
Enrico Weigelt said: > I really don't like smarty. The idea is simply not right. It's a good idea; in fact, PHP was originally supposed to be a templating engine. You can easily separate business and presentation logic in either PHP or Smarty. > + does not separate (imperative) code from layout. it still models > process logic To a limited extent. > + such non-trivial imperative code is not suited for non-programmer's > (perhaps graphical) editing tools. My goal is to allow my Front Page (yuck, don't have a choice) developer to mock up an entire site and then I'll plug in PHP or Smarty template code. Works well. Or I can supply an extremely sparse HTML file with PHP/Smarty template code in it and she can mock it up. > + the layouter has still so learn (a subset of) php and so also has > to be a programmer See above... > + offers no clear borderline between layout definitions and application > code. > you simply can't give a customer of your application service access to > without imposing really serious security problems. A valid concern. > + bound to the php-interpreter and cannot be used w/ other languages. > + content rendering process cannot be separated from the application > server. Another valid concern. Hey PHP/Smarty templates aren't for everyone. No one said they were. But for my next project I believe I'll be using native PHP as a template engine. /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: smarty
Peter Morgan said: >>>We sit in front of a PC and mock up the forms/ pages/ nav bar etc.. That >>>stuff then gets coded. >> >>I agree, and I'm saying you can also do that with native PHP. >>I plan on doing that with the next site I build. Then if I see that it >>makes sense to use Smarty I will, but you can mock up an entire site in >>Microsoft Word and templatize it with normal PHP. I believe we'll work >>even faster because Smarty isn't "in the way." > > what point are you actually trying to make.. That you can also *easily* use native PHP to mock up the forms/pages/nav bar into an HTML file. I'm trying to tell you that Smarty isn't the _only_ way to do what you're proposing, as I thought just a few weeks ago. In fact, it's simple to use native PHP to do the same thing. If you need to see an example to understand this, take a look at my post with the three examples (PHP spaghetti code, Smarty template, PHP template): http://marc.theaimsgroup.com/?l=php-general&m=108145205519710&w=2 I thought Smarty was the ONLY way to separate business logic from presentation, but I was wrong. It's a great tool but it's not the be-all-end-all I thought it was. /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] smarty
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] Re: smarty
Enrico Weigelt said: > Well, I'm a little bit "unpolite" against smarty, since it seems > that people tend to see it as "the best" (tm) and ignore other, > probably better solutions. (its the same thing w/ mysql or mailman) I'm "unpolite" against Smarty because I used to think PHP couldn't *easily* do most of* what Smarty can and that's simply not true. * By that I mean, as I have been stating, there are cases when Smarty just plain makes sense to use, even as a templating engine, and there are cases when I can template with native PHP with about the same effort as with Smarty. /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP] smarty
Ben said:
> But i don't see an alternative in your "Example 3".
Here was example 3 from my post:
http://marc.theaimsgroup.com/?l=php-general&m=108145205519710&w=2
$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:
...
By the way, that's 2 files you're looking at; something like index.php and
template.tpl.
Looks rather templaty, dontcha think? PHP was originally intended to be a
template engine (or so I've been told).
> I hate that coding mixed up with the rest of HTML/CSS.
Me too, which is why I went to Smarty, but then I realized I could do the
same thing without Smarty. Not that Smarty is bad (I'll probably use it
in the future) but I don't *need* it to separate business and presentation
logic and neither do you.
For further separation of design from markup, check out CSSZenGarden.com
for about 200 amazing designs done entirely with CSS. Seems there's no
limits to the design capabilities of CSS, including replacing HTML tables
and img tags.
Ultimately you could separate your entire website into CSS for design,
HTML for the markup of the data, PHP for getting the data, etc. Very
nice.
> It may be fact, that the perfomance could get worse a bit
> when using smarty* but since your not coding sth. for a high
> traffic site the usability of code is more important than that
> little peace of loss in performance.
I agree. The ease-of-use that templating affords is a good tradeoff for
the slight performance hit. Smarty does precompile the PHP and offers
caching, which helps... it's probably similar in performance to the native
PHP template method described above. With native PHP I can use buffering
and Zend and other native performance goodness so native PHP is almost
certainly going to be faster in nearly every case. Just my guess.
Overall, I'd use Smarty when I want to get the extra functions and widgets
in one library. It's a great tool.
/dev/idal
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP] smarty
pete M said: > Smarty is a cool tool and lots of people use it. You have decided NOT to > use it. I don't believe you've read a word I've written. I've been trying to tell people like myself that one can easily template with PHP. I thought I *needed* Smarty or any nice templating engine to seperate business and presentation logic; I was wrong. I was ignorant and perhaps there are others like me. I've also been saying that I'll probably use Smarty in the future. Advantages: numerous time-saving built-in functions, performance (debatable) Disadvantages: must learn yet another language and work with that language's shortcomings. I never said I've decided NOT to use it. I've never said it wasn't a cool tool. Please read carefully. /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] From my side, this thread is closed (Was: smarty)
Richard Harb said: > Could we please close the thread already? Sorry; sometimes I learn something new but still see ignorance going on around me, so I "get on a mission" to help. Seems some people are determined to stay ignorant and even get upset when someone offers a fresh point of view that perhaps would have helped them in the long run. That's always astounded me, but I guess I just need from it and drop it (else my arrogance shows itself). I was planning on unsubbing from this list anywho; getting distracted from work too much. >From my side, this thread is closed. I'll avoid replying to this thread any longer, unless offlist. /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] OOP slow -- am I an idiot?
I think perhaps I'm using classes and OOP incorrectly. The last time I used
them, they were slow.
I want to create a "customer" class which fetches its attributes from a MySQL
database. Something
like this pseudocode:
class customer
{
...
getName ($id)
{
$result = mysql_query ("SELECT name FROM customers WHERE id = '$id'");
return mysql_result ($result, 0);
}
getRevenue ($id,$department,$month,$year)
{
$result = mysql_query ("SELECT revenue FROM customer_revenue WHERE
customer_id = '$id' AND
department = '$department' AND month = '$month' AND year = '$year'");
return mysql_result ($result, 0);
}
...
}
(Again, that's just psedocode. Haven't written anything yet.)
That works great for just one revenue result, but what if I want to return
several results? What
if I want to build a report with hundreds of customers' revenues for a month?
For several months?
For an entire year? Doesn't it slow wa down? It seemed to in the past.
The method above
doesn't seem to scale well.
I did something like the above a few years ago. It was slow, and I think it's
because it was
doing this for each single row:
* Instantiate the class
* Perform a query for the name
* Perform a query for the first department
* Perform a query for the next department
* Perform a query for the next department
* Perform a query for the next department
* Perform a query for the next department
* Perform a query for the next department
* Perform a query for the next department
...
* Destroy the instantiation
* Start over
I love using object-oriented programming, but it seems to me that's ALOT of
performance burden
when I could just do something like this:
SELECT customers.name,
customer_revenue.revenue
FROM customers
INNER JOIN customer_revenue
ON customers.id = customer_revenue.customer_id
WHERE customer_revenue.department = '$department'
ANDcustomer_revenue.month = '$month'
ANDcustomer_revenue.year = '$year'
(PHP loop to display all results)
That seems like it would perform 20x faster.
It seems that the SQL economies of scale (ability to rapidly slurp large sets
of data) are
completely bypassed when using OOP to view ALOT of objects together on one
screen. It seems if I
want decent performance I would have to ignore OOP rules of method hiding and
access the data
directly when using anything more than just a few objects on one page.
A workaround -- I thought that perhaps I could fetch ALL of the data for a
customer into memory
upon initial instantiation, wherein I perform something like this:
SELECT *
FROM customers
INNER JOIN customer_revenue
ON customers.id = customer_revenue.customer_id
WHERE customers.id = '$id'
And then use the results from memory as-needed. It would be all data for a
customer from all
years across all departments.
That might perform better but it'd suck ALOT of data into memory, and what if I
add more than just
revenue to my customer class? Each customer could potentially represent a
limitless set of data.
So this doesn't seem like an optimal solution.
* Where am I going wrong?
* Tell me how YOU fetch data from multiple objects to generate reports.
* Is this an instance where it's better to just ignore OOP rules and go
straight to the data?
Whew, that's not fun to think about, particularly if my queries ever get to be
more complex.
Feedback, please. The goal is to maintain complex queries in just one place --
inside a class. I
want my data to _only_ be accessed from the black box called an OOP class.
CD
Think you're a good person? Yeah, right! ;-)
Prove it and get ten thousand dollars:
TenThousandDollarOffer.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OOP slow -- am I an idiot?
--- Johan Martin <[EMAIL PROTECTED]> wrote: > You should look into getting Professional PHP5 by Lecky-Thompson, > Eide-Goodman, Nowicki and Cove from WROX. ... > The collection class in chapter 5 discusses a programming problem > just like yours. I will look into that, thank you. CD Think you're a good person? Yeah, right! ;-) Prove it and get ten thousand dollars: TenThousandDollarOffer.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OOP slow -- am I an idiot?
--- Larry Garfield <[EMAIL PROTECTED]> wrote: > For your rudimentary example of object-relational mapping below, yes, > performance is going to be atrocious. That's because you're not taking any > advantage of the features that using OOP gives you. Well, I /thought/ I was taking advantage of black box-style hiding (not sure what it's called), that is, making sure the only place I type (and modify) my SQL query is hidden inside the private method of a class. > Again, pull extra data if you can. A somewhat larger result set is (usually) > better than multiple queries. How much you want to front-load in your object > and how much you want to defer to later depends on your specific problem and > how frequently the data will be used. OK that somewhat answers the question. > 5) If you need to grab 100 objects at once, but just need basic data out of > them, use a factory. Vis, (code snipped) I /think/ I understand the code. But I'd need more than just basic data, so I probably will just write a query. > 6) If you need to do a complex query with a couple of joins and such, then > don't waste your time or the computer's trying to shoe-horn it into SQL. SQL > is not inherently OO to start with! Just write your query and loop it and be > happy. OOP is not the answer to all problems. Sometimes it does just make > matters worse, no matter what Sun tries to tell you. :-) LOL Yeah, I was thinking of shoe-horning things into SQL for speed. > > I want my data to _only_ be accessed from the black box called an OOP > > class. > > That will work and is achievable in about 30% of all situations. For the > other 70%, you will have to just hunker down and *gasp* write SQL specific to > the task at hand at least some of the time. How much of the time once again > depends on your situation and the problem you're trying to solve. *gasp* :-) >From what it seems like people are telling me, it's a good idea to boot OOP >for large numbers of objects where I need more than just a little information and just use an SQL query, as I suspected. At least, for PHP; I wonder what Java people do in this situation. CD Think you're a good person? Yeah, right! ;-) Prove it and get ten thousand dollars: TenThousandDollarOffer.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OOP slow -- am I an idiot?
By the way, about myself. I'm primarily a system administrator. Most of the
time I USE code, NOT
write it. But I also dabble, and right now we need to improve our old custom
PHP revenue
application which has sat stagnant for a few years. We can't afford a
full-time programmer and I
know enough to be dangerous ;-) So I'm the guy.
All that to say I'm no pro and am humbly asking your collective professional
opinions.
--- Richard Lynch <[EMAIL PROTECTED]> wrote:
> > I want to create a "customer" class which fetches its attributes from
> > a MySQL database.
>
> No, you don't. :-)
>
> This is a classic example of the "obvious" OOP solution being wildly
> inappropriate.
I'll consider that possibility.
> Start thinking more in terms of what you want the whole application to
> do, and build classes that do THAT, rather then starting with a single
> customer and their info.
It seems you are advocating procedural programming here. I don't see how your
use of classes are
anything more than glorified functions. I could re-word the sentence above
thusly:
> Start thinking more in terms of what you want the whole application to
> do, and build [functions] that do THAT...
That's the path we went down at first and the net result was data access
functions being copied
and modified all over the place, making maintenance a real chore.
Did it have speed? Yes. Do I hesitate to make changes to it? Yes. In a
world where I am forced
to choose between speed and maintainability, I'll probably choose speed,
particularly when the
program will be used daily. However, I truly believe a speedier OOD is
attainable, which is why
I'm asking.
If, however, you are talking about some blending, where I create a
procedural-style class and then
make any modifications in subclasses which override the parent class, like this:
class parentFunction
{
getRevenueForCustomer ($id)
{
// SELECT * FROM customer_revenue WHERE customer_id = '$id'
}
}
class childFunction inherits parentFunction
{
// Overriding the parent function
getRevenueForCustomer ($id, $year, $month, $department)
{
// SELECT * FROM customer_revenue WHERE customer_id = '$id' AND year =
'$year' AND month =
'$month' AND department = '$department'
}
}
If that's what you mean, I honestly can't see how that saves coding time or
helps maintenance,
unless I need to also use some extraneous code with every query which would be
included into the
constructor. But then I could also use a function (instead of a class) which
is like a query
wrapper:
function sql_query ($query)
{
// Some massaging routines
// ...
// Some more
// ...
$result = mysql_query ($query);
// Error handling routines
// ...
// Other routines
// ...
return $result;
}
sql_query ("SELECT * FROM ...");
If that's the case, I don't see the need for classes at all, and that's
actually the path we went
down at first. We created a query function which massaged the input and
handled errors. I've
since learned that's not what I really wanted to do; I want to handle errors
elsewhere. I think
the above is easier to understand than using a class.
Anyway, tell me what you have in mind.
CD
Think you're a good person? Yeah, right! ;-)
Prove it and get ten thousand dollars:
TenThousandDollarOffer.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Solution: [PHP] OOP slow -- am I an idiot?
As I cannot think of a class-based way to build my report, I think I'll use a customer class everywhere BUT in the report. Inside the report I'll just use one SQL statement instead of dozens of instances and hundreds of queries. I'll make a note inside the class that this and that method is not the only place the data is accessed, to also check inside the report. Sometimes, you've just gotta compromise to get the job done. Most of the time, OOP is a good idea, but in this instance I don't think it's the best choice. It's less elegant but more pragmatic. Our project is medium-sized (only about 10K lines) and this will work just fine. (It makes me wonder if enterprise-class OO projects had to make the same decisions.) Thanks to everyone for your input. I need to unsubscribe from the list, so if you have any input, please CC: Chris (AT) deVidal (DOT) tv (my real email address). You might get an automatic reply, click the link. CD Think you're a good person? Yeah, right! ;-) Prove it and get ten thousand dollars: TenThousandDollarOffer.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Working with a Front Page developer
I've got a design developer who only knows Front Page. Despite my general hatred for Microsoft I can work around it :-) She's installed a Front Page PHP plugin (I think it's called Rocket PHP). However, the plugin is buggy; it's got problems that would be best fixed if I could completely separate code from design. Separating code from design is a snap when using HTML forms to call PHP programs (using FORM's ACTION= attribute), but when the code MUST to be embedded in the HTML (as I've had to do), it's tricky. One thought: I could use templates. She can design a normal HTML pages with template entries like [email_address] and [database_records] and such. Then I could use PHP to parse those templates and replace the template entries with real data. Can anyone recommend some template engines? Or tips on using PHP to parse an HTML doc, replacing it with real data? Any other tips? Books/websites on this subject? Thanks in advance! /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Working with a Front Page developer
Richard Davey said: > One of the most common (and well used) template engines is Smarty: > http://smarty.php.net/ > > It might be overkill for your needs though, writing a simple template > system is pretty easy. Looks like it's overkill, but I'll look through it in case I could use it on other projects. Got any tips on writing a template system? Anything I should be aware of, other than copious use of preg_replace? :-) /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[2]: [PHP] Working with a Front Page developer
Richard Davey said: > You don't have to use preg_replace, in its most "simplest" form the > following code will work just fine for a basic template system: Blow me down, that's exactly what I need! You just saved me hours of research. You rock!! Thanks Rich! /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Thank you, Microsoft! Now I need an alternate login method
Microsoft broke IE 6.0 SP1 on XP in January, requiring this patch to be
able to log into our MySQL-authenticated website:
http://www.microsoft.com/downloads/details.aspx?FamilyId=254EB128-5053-48A7-8526-BD38215C74B2&displaylang=en
Microsoft won't put out this patch into the regular XP updates (I guess
because many websites use an alternate method and it doesn't impact as
many people). You have to download it manually.
Of course, this is generating many complaints and we even lost a few
customers; people believe we're requring them to install software just to
log in, when we're really just requiring they fix something Microsoft
broke.
So I really need an alternate MySQL-authenticated method. Surely they exist?
I have a login page on an SSL-enabled Apache server that (I don't admin).
Here's my code (you can download a complete copy from
http://devidal.tv/~chris/mysql_auth.tar.bz2, including the SQL to create
the members table).
login.php:
==
===
edit_agent.php:
===
==
check_login.php:
= 1)
{
require_once ("close_db.php");
header ("Location: login.php?login_failed=true");
exit;
}
?>
=
valid_email.php:
=
open_db.php is just mysql_connect and mysql_select_db, while close_db.php
is just mysql_free_result and mysql_close. I've included them in the
tarball above as well as the SQL you will need if you want to try this for
yourself.
Again, this code worked well until Microsoft broke IE. It still works if
you apply the patch that Microsoft isn't rolling out to everyone.
I'd considered using Apache's .htaccess files, but I haven't tried
connecting that to MySQL for authentication. And I don't have admin
access on the box to install anything on the server.
Ideas??
/dev/idal
"GNU/Linux is free freedom." -- Me
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Thank you, Microsoft! Now I need an alternate loginmethod
Adam Voigt said: > What exactly is breaking? If it's the header to redirect, you could just > issue a meta refresh, or a javascript one. The only time redirects are sent is when there is a failure. Otherwise it's a simple post operation to a PHP file with an include. Have another look at the code. Try it on your server if you'd like. You can replicate the problem with an XP box that's recently (this month) been automatically updated. CD -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Thank you, Microsoft! Now I need an alternate loginmethod
Adam Voigt said: > If I ran XP I might be able to do that. From reading the security > release my MS, it sounds like some times the POST request gets b0rked, Yep. > if this is the case, I'm not sure there's much that can be done about > it. ...except find an alternate login method, which is my question. I know this isn't a problem on every site else there'd be far more uproar against Microsoft for not pushing it out. Surely there must be another method other than the code I showed this mailing list. I searched this group and someone suggested disabling Apache's keepalives but I don't have root on this box so that option is out. At this point it's either disable passwords or find an alternate method; we're angering customers (thank you Microsoft!). /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Thank you, Microsoft! Now I need an alternate login method
Andre Cerqueira said: > try absolute urls on 'Location' headers > if thats the problem, ie is not exactly broken, just making some > (questionable) standards mandatory There are no Location headers on correct logins. It's failing on correct logins. It's a known bug and they're not pushing out the fix like they did the bug, so people think it's us requiring them to install software when it's really a Microsoft problem. So... do you know of any alternate MySQL login methods? /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Thank you, Microsoft! Now I need an alternate loginmethod
Chris W. Parker said: > maybe this is too simple an answer but how about using GET instead? I'm about 90% sure that URL strings are passed in the clear to SSL servers, so this would defeat the purpose of SSL. I've found that some people have solved this problem by upgrading the server to a newer version of PHP. Again, I don't have admin access. The box is admined by a medium-sized hosting company so they might ignore my requests for them to upgrade. Are there any other ways to authorize using MySQL? /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Thank you, Microsoft! Now I need an alternateloginmethod
Matt Matijevich said: > > I'm about 90% sure that URL strings are passed in the clear to SSL > servers, so this would defeat the purpose of SSL. > > > I don't think this is true. You can see the query string in the > address bar, but (with what little http knowledge I have) the http > conversation is encrypted, if you sniff it, the contents will be > encrypted, even the query string. This still might make the user uncomfortable (it'd make me uncomfortable) so we can't ignore the "warm fuzzy" factor. But if you can confirm this, perhaps it'd be good enough. It seems this was fixed in a newer version of PHP or Apache or OpenSSL. Perhaps their lazy admins just need to update their server. Of course, I've been known to miss a few upgrades (he he he :-) so there's certainly an allowance for laziness, but not if my request for them to upgrade is ignored. Do you know of any other MySQL-enabled auth methods? Can you confirm GET strings are also encrypted? /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Thank you, Microsoft! Now I need an alternate loginmethod
Marek Kilimajer said: >> I searched this group and someone suggested disabling Apache's >> keepalives but I don't have root on this box so that option is out. > > Try to send "Connection: close" header, then the connection will be > terminated by the client. I don't understand... would I place that code in the posted PHP page, edit_agent.php? To reiterate, no custom headers are sent with any PHP function unless there is a failure. IE bombs on a successful login (when no custom headers are sent). I'm not sure where I'd include this custom header or why. /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] What's the use in OOP?
Stephen Craton said: > I've been reading up on object oriented programming in PHP for a while now > and I just don't get what's the use in using it. It supposedly makes it > faster, but I don't really see how in any of my scripts. What's the > advantage of OOP anyway, and why are so many people using it now? What > does it have to offer then just creating files full of functions to > include later like I've always done? Good question. OOP is mysterious until you get it, then you'll want to write everything in objects. Show a man how to use a hammer, and everything looks like a nail :-) One use is to organize loose functions. For example, we have a user/group administration section. Each user is represented with a user object. With the user object I put functions inside which do things like "Give me your group ID," "Give me your permissions," "Give me your name." So rather than writing a function for each of these and squirreling it away into an include file, I organize it into a user class (and squirrel it away into an include file :-) Same with groups. So I wanted to produce a list of users in the group. I ran something like this (pseudocode): $group_obj = new Group (1); foreach ($group_obj->get_group_list() as $member_id) $user_obj = new User (45); $user_obj->get_name (); // Displays "John" The equivalent standard programming is: function get_member_name($id) $SQL = "select name from members where id = $id"; return $name function get_group_list ($group_id) $SQL = "select member_id from groups where group_id = $group_id"; return $array_of_ids foreach (get_group_list(1) as $member_id) get_member_name ($member_id); // Displays "John" A bit messier. OOP lets each class worry about getting its own data. With this organization you can think more clearly about writing the business logic. You can build each object to "do" whatever you need it to (Tell someone your name when asked, tell someone your blood type when asked, donate blood when asked), and then go back and build business logic to orchestrate each action into an application "User, who are you? User, what is your blood type?" "User, donate blood."). So my use was for organization. In this example, OOP was actually slower (don't know who told you it'd be faster; I sure haven't found that to be true) and so eventually I'll revert to ordinary functional code. For each time I fetch the member name, the user's object must be built up and torn down. Am I doing something wrong? Perhaps. But it tells me OOP isn't right for any and every situation. Not everything is a nail. Other uses include extension. For instance, I might see a class I like and will download it. Say I want to impliment it but with a few customizations; I can extend that class. In the ordinary function world, if a new version of a library comes out I'd have to reimpliment those changes into the library again, but with a class I don't much care which changes are where (to some extent). For example, we modified an ordinary menu-building system to be object-oriented so we could publish it back to the developers. We then extended it to do a permission check using the user object above like this: get menu items extension: for each menu item, is the user allowed to see it? If not, remove it from the list show menu items I can now publish that code without the custom permission check and it'll work for anyone. It also helps developers segment their work. For a grand example, take a look at the Java classes, which are organized in a tree-like fashion. The code at the top is generic and it gets more specific as you descend the tree. Inheritence is king for Java, and there's very little code rewrite (if the developer knows what he's doing). There are a number of other reasons to use OOP, but speed should not be the first consideration. Perhaps there are situations in which it is faster than standard functions but I haven't see them, or perhaps you've really got to tweak it. Instead, use OOP for a more organized way to build a program. That's my layman's understanding of OOP for laymen like myself. Hope it helps! CD -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] RE:[PHP]What'stheuseinOOP?
Stephen Craton said:
> I used OO in my chat script (can be found at
> http://php.melchior.us) but it really seemed like a waste
> since it was such a small basic script. I never
> really find myself re-needing code except for database
> connectivity and calling the database and stuff like that.
My boss, before he really understood OOP, would take ordinary proceedural
code and wrap it in a class, which still wasn't object-oriented. I fear
you've done the same in your code (even though I haven't seen it) and are
wondering what the big whoop is about. I believe that if you don't
understand OO, you haven't been using OO.
Once you understand the whys (after using it for a bit) you'll see why
it's so cool. Now I wanna code everything OO :-)
I really understood it when a Java programmer I know once said "In
proceedural code, the nuts-and-bolts are functions which are verbs
(get_data(), open_database(), write_file()) while in object-oriented code,
the nuts and bolts are objects which are nouns ($user, $group, $job,
$house)."
So I'd build an OO chat room like so (pseudocode):
class chatroom
values: private or public, admin, name, max_users, comments, admin_present
methods: get/set_public_or_private, get/set_admin, get/set_name,
get/set_max_users, get/set_comments, display_help, update_member_list,
get/set_admin_present
class user
values: permission level, name, email address, password
methods: get/set permission level, get/set name, get/set email_address,
get/set password, join_chat_room, create_chat_room, leave_chat_room
class system chatroom extends chatroom
methods: check permissions, restart server
$phpchat = new chatroom ("phpchat");
$phpchat->set_public_or_private ("public");
$phpchat->set_admin ("[EMAIL PROTECTED]");
$phpchat->set_comments ("A great place to talk about PHP");
$user-> new user ("[EMAIL PROTECTED]");
$user->join_chat_root ("phpchat");
if ($phpchat->get_admin() == $user->get_email_address()) {
$phpchat->set_admin_present(TRUE); }
$phpchat->update_member_list();
...
It's not perfect but hopefully you'll understand the magic.
/dev/idal
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] [Newbie Guide] For the benefit of new members
Ma Siva Kumar said: > 10. Ask smart questions > http://catb.org/~esr/faqs/smart-questions.html Though I've been using newsgroups since '95 and though I'd read this page before, it's helpful to review it. I can see a few mistakes I'd made as recently as a few months ago on another list :-) This post's subject should read [Newbie and Experienced User Guide] LOL Thanks, /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] smarty
Kelly Hallman said:
> Apr 6 at 5:33pm, 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
>
> There are a lot of templating systems for PHP, but I chose Smarty because
> it seemed the most feature-laden, and likely to have continued support.
> I wanted to standardize on something, so I went for the most ubiquitous.
> Really, I couldn't be happier with it in every regard.
>
> At first it may seem like more than you need, but continue working with it
> and you'll find new design strategies that take you further than you ever
> thought you'd go. It's one of those things you start using and never look
> back. I use it on almost every project now, even small ones.
>
> There are the naysayers who complain it's too bloated for basic work,
> but I think the powerful benefits far outweigh any performance issues.
> I've never felt like it was slow or too much for a given task.
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.
* OK so you will notice it the first time and if you make any changes to
the file.
I just used it for the first time since I am trying to work with a real
estate agent who only had time to learn Front Page (yuk). We were in a
tight spot, because she'd make a change to the website and I'd have to
chase after her because Front Page screwed up the code (the RocketPHP
plugin was buggy, at best, and didn't allow her to flow).
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!
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: If the user is
at a low level he/she won't get fancy options on his profile. This
required outputting HTML.
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}
It's extremely low-level. I can leave the code which fetches the $level
in the PHP code and just have the checks in the template.
Hopefully you get the idea; you are recommended to leave presentation
logic in the template but all other logic should be in the back end PHP
file.
Smarty is a great templating engine which is easy to install and use on
any sized project and I highly recommend it.
/dev/idal
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] smarty
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
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
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
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
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] very large and long if statement
> I have this very large and long if statement:
> if
> (!empty($_SESSION['add']['type'])
> && !empty($_SESSION['add']['start_date']
> && !empty($_SESSION['add']['end_date'])
> && !empty($_SESSION['add']['name'])
> && !empty($_SESSION['add']['county'])
> && !empty($_SESSION['add']['discription'])
> && !empty($_SESSION['add']['StartingDay'])
> && !empty($_SESSION['add']['StartingMonth'])
> && !empty($_SESSION['add']['StartingYear'])
> && !empty($_SESSION['add']['EndingDay']})
> && !empty($_SESSION['add']['EndingMonth'])
> && !empty($_SESSION['add']['EndingYear']))
> {//run the insert query}
> else
> {//show error since one or more fields above are blank}
> was wondering if there was really any way to condense that down to
> something any better? all fields in the form that those came from are
> required...
Doubt you're going to make it smaller, but you can make it more readable.
As I understand it, !empty is redundant (at least, it's always worked for
me, but I'm no expert). Plus the use of AND should make it more
human-readable, like so:
if ($_SESSION['add']['type']
AND $_SESSION['add']['start_date']
AND $_SESSION['add']['end_date']
AND $_SESSION['add']['name']
AND $_SESSION['add']['county']
AND $_SESSION['add']['discription']
AND $_SESSION['add']['StartingDay']
AND $_SESSION['add']['StartingMonth']
AND $_SESSION['add']['StartingYear']
AND $_SESSION['add']['EndingDay']
AND $_SESSION['add']['EndingMonth']
AND $_SESSION['add']['EndingYear'])
{//run the insert query}
else
{//show error since one or more fields above are blank}
Personally, I'd clean it up a tiny bit more:
$add = $_SESSION['add'];
if ($add['type']
AND $add['start_date']
...
{//show error since one or more fields above are blank}
unset ($add);
Again, I'm no expert, but hopefully that'll help.
/dev/idal
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP makes a great templating engine (Was: smarty)
Justin French said:
> PHP itself is a great templating language :)
I've been studying on this myself. For some reason I didn't see this (is
it not explained well enough in books/websites/articles? Dunno.)
I used to code like so (shorthand), mixing business logic with
presentation:
Name:
Address:
State:
...
This was big trouble with my Front Page developer. She's a real estate
agent. She needs something visual and can't spend time learning something
else. Front Page's PHP plugin was buggy at best. Enter Smarty.
With Smarty, I was effectively separating business and presentation logic:
$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}
...
But one of the original intentions of PHP was as a templating system. It
just takes a little planning and thinking to use it as such:
$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:
...
A kool side effect is I don't have to learn another language. And it's
faster because less code loads on each page launch (Smarty's code must be
loaded on every page load). At worst, I lose caching features (however
other native PHP options exist, and/or use Zend) and some of the nice
Smarty functions such as html_options (which might be easily replaced by
phpHTMLlib or another widget library).
So while Smarty isn't at all bad, it doesn't appear to be *necessary* to
separate business logic from presentation. And I don't need to learn
another programming language.
So I may be going back to straight PHP :-)
For more info, read this:
http://www.phppatterns.com/index.php/article/articleview/4/1/1/
This article is rather rigid, stating that template engines are all bad.
I just see them as another tool, but not the *must have* I thought they
were before.
Thanks to Jochem Maas <[EMAIL PROTECTED]> for helping me open my eyes.
/dev/idal
--
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 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
