|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
php-general-digest-help
lists.php.net
Date: Wed Feb 13 2008 - 01:22:37 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
php-general Digest 13 Feb 2008 07:22:37 -0000 Issue 5290
Topics (messages 269180 through 269232):
Re: Question about development
269180 by: Jason Pruim
269182 by: Wolf
269184 by: Shawn McKenzie
269186 by: Aleksandar Vojnovic
269187 by: Jason Pruim
269188 by: Nathan Rixham
269189 by: Nathan Rixham
269200 by: Daniel Brown
269204 by: Jason Pruim
269219 by: Richard Lynch
269231 by: Xavier de Lapeyre
Re: Template system in PHP
269181 by: Christoph Boget
269185 by: Aleksandar Vojnovic
269190 by: Nathan Rixham
269191 by: Ryan A
269192 by: Shawn McKenzie
269193 by: Robert Cummings
269194 by: Greg Donald
269195 by: Nathan Rixham
269196 by: Greg Donald
269197 by: Robert Cummings
269198 by: Greg Donald
269199 by: Nathan Rixham
269201 by: Łukasz Wojciechowski
269202 by: Nathan Rixham
269203 by: Christoph Boget
269205 by: Nathan Nobbe
269206 by: Robert Cummings
269207 by: Robert Cummings
269208 by: Robert Cummings
269209 by: Nathan Rixham
269211 by: Nathan Nobbe
269212 by: András Csányi
269213 by: Greg Donald
269214 by: Greg Donald
269215 by: Shawn McKenzie
269216 by: Nathan Nobbe
269217 by: Michael McGlothlin
269218 by: Greg Donald
269222 by: mike
269223 by: Nathan Nobbe
269224 by: Michael McGlothlin
269227 by: Nathan Nobbe
269228 by: Michael McGlothlin
269229 by: Nathan Rixham
Re: PHP 5.2.5 installation
269183 by: Shawn McKenzie
Re: Recommended ORM for PHP
269210 by: Manuel Lemos
Re: memcached (was: session and Multi Server Architecture)
269220 by: mike
269232 by: Per Jessen
Re: Session and Multi Server Architecture
269221 by: mike
database design tool
269225 by: Shawn McKenzie
269226 by: Shawn McKenzie
Re: Security scanner (Lockdown Networks Enforcer)
269230 by: Daevid Vincent
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscribelists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribelists.php.net
To post to the list, e-mail:
php-generallists.php.net
----------------------------------------------------------------------
attached mail follows:
On Feb 12, 2008, at 1:03 PM, Nathan Rixham wrote:
> Jason Pruim wrote:
>> Hi Everyone,
>> I know this isn't 100% on topic... But when is any post to this
>> list 100% on topic? :)
>> I've been doing some googling trying to find info on how to plan
>> for what a website needs. Stuff like Does it need a forum, live
>> support, database driven etc. etc. Does anyone have a form that
>> they use to give to the client asking them to outline some ideas
>> that they have about the website?
>> What I'm looking for is something that I could give to a potential
>> client and ask them to describe some basic aspects of their target
>> audience, a rough idea of what they want it to look like, or at
>> least other sites that they like. Stuff like that..
>> Even if you don't have such a form, I'm sure you all have standard
>> questions you ask each client before giving a quote :)
>> Anyone want to share with the class?
>> If there is interest, I may even put it together on a webpage to
>> help future people :)
>> --
>> Jason Pruim
>> Raoset Inc.
>> Technology Manager
>> MQC Specialist
>> 3251 132nd ave
>> Holland, MI, 49424
>> www.raoset.com
>> japruimraoset.com
>
> I always take the simple approach, ask them what they want to
> achieve/expect from the website. Then verbally work backwards with
> them to figure out what the website needs in order to reach the
> clients goal.
>
> (personally) In all honesty I'd stay away from any kind of form, as
> they'll just pick "nice to have" boxes and end up with something
> overpriced, not suited to there needs and you'll get complaints in 6
> months time.
>
> hope that makes sense!
>
> ps: the only thing I've found useful that way after many years, is
> to make the base site structure with very short text descriptions on
> each page + links to the next page | and for god sake, leave the
> "home" page will very very last!
>
> Nathan
Hey Nathan,
Thanks for the reply. I'm just getting more and more into freelance
web work and have my first client asking for a quote. Before now, it's
all been internal applications, and the companies website that I have
worked on. Nothing for other people.
I was actually thinking that the form would be for me to make sure I
covered the basics... I'm alot better if I have something written down
and I can ask the client "Do you need to support multiple languages?"
Which to me then, would lead me into using a database[1] for storing
the pages and using browser sniffing to find out what language
preference they currently had selected to display in that language :)
[1] As I was typing this I realized that maybe a database isn't the
best idea for that, but it's the only way I can think of. Anyone who
wants to give me another option is more then welcome to do so!
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
japruimraoset.com <--Email and Googletalk/Jabber IM ID.
attached mail follows:
---- Jason Pruim <japruimraoset.com> wrote:
>
> On Feb 12, 2008, at 1:03 PM, Nathan Rixham wrote:
>
> > Jason Pruim wrote:
> >> Hi Everyone,
> >> I know this isn't 100% on topic... But when is any post to this
> >> list 100% on topic? :)
> >> I've been doing some googling trying to find info on how to plan
> >> for what a website needs. Stuff like Does it need a forum, live
> >> support, database driven etc. etc. Does anyone have a form that
> >> they use to give to the client asking them to outline some ideas
> >> that they have about the website?
> >> What I'm looking for is something that I could give to a potential
> >> client and ask them to describe some basic aspects of their target
> >> audience, a rough idea of what they want it to look like, or at
> >> least other sites that they like. Stuff like that..
> >> Even if you don't have such a form, I'm sure you all have standard
> >> questions you ask each client before giving a quote :)
> >> Anyone want to share with the class?
> >> If there is interest, I may even put it together on a webpage to
> >> help future people :)
> >> --
> >> Jason Pruim
> >> Raoset Inc.
> >> Technology Manager
> >> MQC Specialist
> >> 3251 132nd ave
> >> Holland, MI, 49424
> >> www.raoset.com
> >> japruimraoset.com
> >
> > I always take the simple approach, ask them what they want to
> > achieve/expect from the website. Then verbally work backwards with
> > them to figure out what the website needs in order to reach the
> > clients goal.
> >
> > (personally) In all honesty I'd stay away from any kind of form, as
> > they'll just pick "nice to have" boxes and end up with something
> > overpriced, not suited to there needs and you'll get complaints in 6
> > months time.
> >
> > hope that makes sense!
> >
> > ps: the only thing I've found useful that way after many years, is
> > to make the base site structure with very short text descriptions on
> > each page + links to the next page | and for god sake, leave the
> > "home" page will very very last!
> >
> > Nathan
>
> Hey Nathan,
>
> Thanks for the reply. I'm just getting more and more into freelance
> web work and have my first client asking for a quote. Before now, it's
> all been internal applications, and the companies website that I have
> worked on. Nothing for other people.
>
> I was actually thinking that the form would be for me to make sure I
> covered the basics... I'm alot better if I have something written down
> and I can ask the client "Do you need to support multiple languages?"
> Which to me then, would lead me into using a database[1] for storing
> the pages and using browser sniffing to find out what language
> preference they currently had selected to display in that language :)
>
>
> [1] As I was typing this I realized that maybe a database isn't the
> best idea for that, but it's the only way I can think of. Anyone who
> wants to give me another option is more then welcome to do so!
>
>
> --
>
> Jason Pruim
> Raoset Inc.
> Technology Manager
> MQC Specialist
> 3251 132nd ave
> Holland, MI, 49424
> www.raoset.com
> japruimraoset.com <--Email and Googletalk/Jabber IM ID.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
I generally ask people what they are looking to do with the site. Are they just wanting to have an image out there, do they want a contact form, do they want to sell something, do they really care to translate it (blowfish),
Then I go into how much $$$ do they want to spend, do they want to update it themselves, how they have worked on it in the past, etc.
Generally that alone gives me a good base point. But I'm scatter-brained enough that I just write things down as we talk and that leads me to more questions to ask them. :)
Wolf
attached mail follows:
Jason Pruim wrote:
>
> On Feb 12, 2008, at 1:03 PM, Nathan Rixham wrote:
>
>> Jason Pruim wrote:
>>> Hi Everyone,
>>> I know this isn't 100% on topic... But when is any post to this list
>>> 100% on topic? :)
>>> I've been doing some googling trying to find info on how to plan for
>>> what a website needs. Stuff like Does it need a forum, live support,
>>> database driven etc. etc. Does anyone have a form that they use to
>>> give to the client asking them to outline some ideas that they have
>>> about the website?
>>> What I'm looking for is something that I could give to a potential
>>> client and ask them to describe some basic aspects of their target
>>> audience, a rough idea of what they want it to look like, or at least
>>> other sites that they like. Stuff like that..
>>> Even if you don't have such a form, I'm sure you all have standard
>>> questions you ask each client before giving a quote :)
>>> Anyone want to share with the class?
>>> If there is interest, I may even put it together on a webpage to help
>>> future people :)
>>> --
>>> Jason Pruim
>>> Raoset Inc.
>>> Technology Manager
>>> MQC Specialist
>>> 3251 132nd ave
>>> Holland, MI, 49424
>>> www.raoset.com
>>> japruimraoset.com
>>
>> I always take the simple approach, ask them what they want to
>> achieve/expect from the website. Then verbally work backwards with
>> them to figure out what the website needs in order to reach the
>> clients goal.
>>
>> (personally) In all honesty I'd stay away from any kind of form, as
>> they'll just pick "nice to have" boxes and end up with something
>> overpriced, not suited to there needs and you'll get complaints in 6
>> months time.
>>
>> hope that makes sense!
>>
>> ps: the only thing I've found useful that way after many years, is to
>> make the base site structure with very short text descriptions on each
>> page + links to the next page | and for god sake, leave the "home"
>> page will very very last!
>>
>> Nathan
>
> Hey Nathan,
>
> Thanks for the reply. I'm just getting more and more into freelance web
> work and have my first client asking for a quote. Before now, it's all
> been internal applications, and the companies website that I have worked
> on. Nothing for other people.
>
> I was actually thinking that the form would be for me to make sure I
> covered the basics... I'm alot better if I have something written down
> and I can ask the client "Do you need to support multiple languages?"
> Which to me then, would lead me into using a database[1] for storing the
> pages and using browser sniffing to find out what language preference
> they currently had selected to display in that language :)
>
>
> [1] As I was typing this I realized that maybe a database isn't the best
> idea for that, but it's the only way I can think of. Anyone who wants to
> give me another option is more then welcome to do so!
>
>
> --
>
> Jason Pruim
> Raoset Inc.
> Technology Manager
> MQC Specialist
> 3251 132nd ave
> Holland, MI, 49424
> www.raoset.com
> japruimraoset.com <--Email and Googletalk/Jabber IM ID.
As to the multilingual; many approaches use defines for site words,
buttons, links etc... but since you most likely keep dynamic content in
the database then it makes sense to store the translations there too.
Then you can build a management interface for the customer to add
content and the associated translations.
-Shawn
attached mail follows:
Could you explain this a little better - "...into using a database[1]
for storing the
pages and using browser sniffing to find out what language preference
they currently had
selected to display in that language"?
Aleksandar
Quoting Jason Pruim <japruimraoset.com>:
>
> On Feb 12, 2008, at 1:03 PM, Nathan Rixham wrote:
>
>> Jason Pruim wrote:
>>> Hi Everyone,
>>> I know this isn't 100% on topic... But when is any post to this
>>> list 100% on topic? :)
>>> I've been doing some googling trying to find info on how to plan
>>> for what a website needs. Stuff like Does it need a forum, live
>>> support, database driven etc. etc. Does anyone have a form that
>>> they use to give to the client asking them to outline some ideas
>>> that they have about the website?
>>> What I'm looking for is something that I could give to a potential
>>> client and ask them to describe some basic aspects of their
>>> target audience, a rough idea of what they want it to look like,
>>> or at least other sites that they like. Stuff like that..
>>> Even if you don't have such a form, I'm sure you all have standard
>>> questions you ask each client before giving a quote :)
>>> Anyone want to share with the class?
>>> If there is interest, I may even put it together on a webpage to
>>> help future people :)
>>> --
>>> Jason Pruim
>>> Raoset Inc.
>>> Technology Manager
>>> MQC Specialist
>>> 3251 132nd ave
>>> Holland, MI, 49424
>>> www.raoset.com
>>> japruimraoset.com
>>
>> I always take the simple approach, ask them what they want to
>> achieve/expect from the website. Then verbally work backwards with
>> them to figure out what the website needs in order to reach the
>> clients goal.
>>
>> (personally) In all honesty I'd stay away from any kind of form, as
>> they'll just pick "nice to have" boxes and end up with something
>> overpriced, not suited to there needs and you'll get complaints in
>> 6 months time.
>>
>> hope that makes sense!
>>
>> ps: the only thing I've found useful that way after many years, is
>> to make the base site structure with very short text descriptions
>> on each page + links to the next page | and for god sake, leave the
>> "home" page will very very last!
>>
>> Nathan
>
> Hey Nathan,
>
> Thanks for the reply. I'm just getting more and more into freelance
> web work and have my first client asking for a quote. Before now, it's
> all been internal applications, and the companies website that I have
> worked on. Nothing for other people.
>
> I was actually thinking that the form would be for me to make sure I
> covered the basics... I'm alot better if I have something written down
> and I can ask the client "Do you need to support multiple languages?"
> Which to me then, would lead me into using a database[1] for storing
> the pages and using browser sniffing to find out what language
> preference they currently had selected to display in that language :)
>
>
> [1] As I was typing this I realized that maybe a database isn't the
> best idea for that, but it's the only way I can think of. Anyone who
> wants to give me another option is more then welcome to do so!
>
>
> --
>
> Jason Pruim
> Raoset Inc.
> Technology Manager
> MQC Specialist
> 3251 132nd ave
> Holland, MI, 49424
> www.raoset.com
> japruimraoset.com <--Email and Googletalk/Jabber IM ID.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
attached mail follows:
On Feb 12, 2008, at 2:09 PM, Aleksandar Vojnovic wrote:
> Could you explain this a little better - "...into using a
> database[1] for storing the
> pages and using browser sniffing to find out what language
> preference they currently had
> selected to display in that language"?
>
> Aleksandar
I'll try my best to :)
I have heard from people (Haven't done it my self) that it is possible
and reliable, to use the browsers language setting which gets
transmitted in one of the headers (Not sure which one off hand) to
initially select the language for the site from your database. IE: If
you speak english, and have english selected as your browser language
preference, it will send that to the server, when your script sees it,
it's a fairly good assumption that that would be the preferred
language to display in, so the server pushes up the english version of
the site.
Obviously, you need to have the actual translated files stored on your
server to choose from. And, you should always give them away of
overriding the guessed option, just in case they really don't want to
use what it appears like they do :)
Does that explain it better?
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
japruimraoset.com
attached mail follows:
Jason,
If you don't mind I may give you an email off the list in a moment to
brain storm up a quick list of questions to ask clients and indeed
client "gotchas".
For the time being as this seems to be going down the line of how to
handle multilingual sites here's my two pennies.
XML, store everything in XML, that way I can store extra info specific
to the files in there aswell. A quick XPath query [lang=en-gb] and I've
got the content I need.
To get around the search thing I generally store a plain text version of
the content in a single table, with the "key" being a geometry column to
keep things working ultra fast.
But.. I'm still experimenting - sure xml is the way forwards..
Nathan
Aleksandar Vojnovic wrote:
> Could you explain this a little better - "...into using a database[1]
> for storing the
> pages and using browser sniffing to find out what language preference
> they currently had
> selected to display in that language"?
>
> Aleksandar
>
> Quoting Jason Pruim <japruimraoset.com>:
>
>>
>> On Feb 12, 2008, at 1:03 PM, Nathan Rixham wrote:
>>
>>> Jason Pruim wrote:
>>>> Hi Everyone,
>>>> I know this isn't 100% on topic... But when is any post to this
>>>> list 100% on topic? :)
>>>> I've been doing some googling trying to find info on how to plan
>>>> for what a website needs. Stuff like Does it need a forum, live
>>>> support, database driven etc. etc. Does anyone have a form that
>>>> they use to give to the client asking them to outline some ideas
>>>> that they have about the website?
>>>> What I'm looking for is something that I could give to a potential
>>>> client and ask them to describe some basic aspects of their target
>>>> audience, a rough idea of what they want it to look like, or at
>>>> least other sites that they like. Stuff like that..
>>>> Even if you don't have such a form, I'm sure you all have standard
>>>> questions you ask each client before giving a quote :)
>>>> Anyone want to share with the class?
>>>> If there is interest, I may even put it together on a webpage to
>>>> help future people :)
>>>> --
>>>> Jason Pruim
>>>> Raoset Inc.
>>>> Technology Manager
>>>> MQC Specialist
>>>> 3251 132nd ave
>>>> Holland, MI, 49424
>>>> www.raoset.com
>>>> japruimraoset.com
>>>
>>> I always take the simple approach, ask them what they want to
>>> achieve/expect from the website. Then verbally work backwards with
>>> them to figure out what the website needs in order to reach the
>>> clients goal.
>>>
>>> (personally) In all honesty I'd stay away from any kind of form, as
>>> they'll just pick "nice to have" boxes and end up with something
>>> overpriced, not suited to there needs and you'll get complaints in 6
>>> months time.
>>>
>>> hope that makes sense!
>>>
>>> ps: the only thing I've found useful that way after many years, is
>>> to make the base site structure with very short text descriptions on
>>> each page + links to the next page | and for god sake, leave the
>>> "home" page will very very last!
>>>
>>> Nathan
>>
>> Hey Nathan,
>>
>> Thanks for the reply. I'm just getting more and more into freelance
>> web work and have my first client asking for a quote. Before now, it's
>> all been internal applications, and the companies website that I have
>> worked on. Nothing for other people.
>>
>> I was actually thinking that the form would be for me to make sure I
>> covered the basics... I'm alot better if I have something written down
>> and I can ask the client "Do you need to support multiple languages?"
>> Which to me then, would lead me into using a database[1] for storing
>> the pages and using browser sniffing to find out what language
>> preference they currently had selected to display in that language :)
>>
>>
>> [1] As I was typing this I realized that maybe a database isn't the
>> best idea for that, but it's the only way I can think of. Anyone who
>> wants to give me another option is more then welcome to do so!
>>
>>
>> --
>>
>> Jason Pruim
>> Raoset Inc.
>> Technology Manager
>> MQC Specialist
>> 3251 132nd ave
>> Holland, MI, 49424
>> www.raoset.com
>> japruimraoset.com <--Email and Googletalk/Jabber IM ID.
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
attached mail follows:
> Jason Pruim wrote:
>
> On Feb 12, 2008, at 2:09 PM, Aleksandar Vojnovic wrote:
>
>> Could you explain this a little better - "...into using a database[1]
>> for storing the
>> pages and using browser sniffing to find out what language preference
>> they currently had
>> selected to display in that language"?
>>
>> Aleksandar
>
>
> I'll try my best to :)
>
> I have heard from people (Haven't done it my self) that it is possible
> and reliable, to use the browsers language setting which gets
> transmitted in one of the headers (Not sure which one off hand) to
> initially select the language for the site from your database. IE: If
> you speak english, and have english selected as your browser language
> preference, it will send that to the server, when your script sees it,
> it's a fairly good assumption that that would be the preferred language
> to display in, so the server pushes up the english version of the site.
>
> Obviously, you need to have the actual translated files stored on your
> server to choose from. And, you should always give them away of
> overriding the guessed option, just in case they really don't want to
> use what it appears like they do :)
>
> Does that explain it better?
>
>
> --
>
> Jason Pruim
> Raoset Inc.
> Technology Manager
> MQC Specialist
> 3251 132nd ave
> Holland, MI, 49424
> www.raoset.com
> japruimraoset.com
Browsers generally send the the HTTP_ACCEPT_LANGUAGE header in a request.
$_SERVER[HTTP_ACCEPT_LANGUAGE] => en-gb,en;q=0.5
thus with mine, preference is en-gb, failing that anything en; failing
that whatever you've got.
ACCEPT_CHARSET is worth a check often aswell; finally POST requests can
also have a CONTENT_LANGUAGE specified which describes the lang of the
content.
attached mail follows:
On Feb 12, 2008 2:53 PM, Nathan Rixham <nrixhamgmail.com> wrote:
> Browsers generally send the the HTTP_ACCEPT_LANGUAGE header in a request.
>
> $_SERVER[HTTP_ACCEPT_LANGUAGE] => en-gb,en;q=0.5
>
> thus with mine, preference is en-gb, failing that anything en; failing
> that whatever you've got.
>
> ACCEPT_CHARSET is worth a check often aswell; finally POST requests can
> also have a CONTENT_LANGUAGE specified which describes the lang of the
> content.
Yes, but as has been said in the past, you can't rely on browser
headers, because they can easily be forged. ;-P
I can see it now....
"That'll mess with them. Now they'll think I'm Mexican!"
--
</Dan>
Daniel P. Brown
Senior Unix Geek
<? while(1) { $me = $mind--; sleep(86400); } ?>
attached mail follows:
On Feb 12, 2008, at 4:24 PM, Daniel Brown wrote:
> On Feb 12, 2008 2:53 PM, Nathan Rixham <nrixhamgmail.com> wrote:
>> Browsers generally send the the HTTP_ACCEPT_LANGUAGE header in a
>> request.
>>
>> $_SERVER[HTTP_ACCEPT_LANGUAGE] => en-gb,en;q=0.5
>>
>> thus with mine, preference is en-gb, failing that anything en;
>> failing
>> that whatever you've got.
>>
>> ACCEPT_CHARSET is worth a check often aswell; finally POST requests
>> can
>> also have a CONTENT_LANGUAGE specified which describes the lang of
>> the
>> content.
>
> Yes, but as has been said in the past, you can't rely on browser
> headers, because they can easily be forged. ;-P
>
> I can see it now....
>
> "That'll mess with them. Now they'll think I'm Mexican!"
Which goes back to giving them an easy way of changing the display
language :P If someone intentionally messes with the language headers
they deserve to get a language they may or may not know! :P
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
japruimraoset.com
attached mail follows:
On Tue, February 12, 2008 3:32 pm, Jason Pruim wrote:
>
> On Feb 12, 2008, at 4:24 PM, Daniel Brown wrote:
>
>> On Feb 12, 2008 2:53 PM, Nathan Rixham <nrixhamgmail.com> wrote:
>>> Browsers generally send the the HTTP_ACCEPT_LANGUAGE header in a
>>> request.
>>>
>>> $_SERVER[HTTP_ACCEPT_LANGUAGE] => en-gb,en;q=0.5
>>>
>>> thus with mine, preference is en-gb, failing that anything en;
>>> failing
>>> that whatever you've got.
>>>
>>> ACCEPT_CHARSET is worth a check often aswell; finally POST requests
>>> can
>>> also have a CONTENT_LANGUAGE specified which describes the lang of
>>> the
>>> content.
>>
>> Yes, but as has been said in the past, you can't rely on browser
>> headers, because they can easily be forged. ;-P
>>
>> I can see it now....
>>
>> "That'll mess with them. Now they'll think I'm Mexican!"
>
>
> Which goes back to giving them an easy way of changing the display
> language :P If someone intentionally messes with the language headers
> they deserve to get a language they may or may not know! :P
I was at an internet cafe in Paris once.
Despite having a French keyboard layout and a browser sending fr as my
preferred language, my French language skills were no better than when
I walked in... :-)
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?
attached mail follows:
Hi,
I usually use a MoSCoW Analysis.
http://en.wikipedia.org/wiki/MoSCoW_Method
From then on, I move into detailing each needs.
The S - Should have and C - could have parts are rather tricky if you are new to it.
So far this method has saved me more than once in many projects.
The most important aspects are the Must Have (which you should implement at all cost in the development cycle) and the Wont Have.
Correctly defining the Wont Haves is a must.
You won't like to have to re-do your whole development simply because you forgot to point out that there "Wont have" multiple languages.
Or that there "Wont Have" a forum in this version.
One little trick that I used now is the following point in the Won't Have section. " Any not mentioned above" as default.
Dummy Site
Version 1.X
MoSCoW Analysis
Must Have Features
1 Registration Feature Allows user to register to website
2 Login Feature Allows user to login to website - Requires registration
3 Recover Pwd Feature Allows user to reset his password "- Unique email required - mail() function - Overwrite pwd with a random pwd - Send hash MD5"
4 Search Allows users to search for posts "- basic search - advanced search"
5 Product display
6 Add Products
7 Display latest news
Should Have Features
1 Profile Updates Allows users to update their profiles. "- Change password
- Change display name
- Change information details
- Cannot change email"
Could Have Features
1 Forum
2 Chat
Wont Have Features
1 Any not mentioned above
2 Multiple Languages
Xavier de Lapeyre
Web Developer
Please consider the environment before printing this mail note.
-----Original Message-----
From: Jason Pruim [mailto:japruimraoset.com]
Sent: mardi 12 fvrier 2008 19:50
To: PHP-General General
Subject: [PHP] Question about development
Hi Everyone,
I know this isn't 100% on topic... But when is any post to this list
100% on topic? :)
I've been doing some googling trying to find info on how to plan for
what a website needs. Stuff like Does it need a forum, live support,
database driven etc. etc. Does anyone have a form that they use to
give to the client asking them to outline some ideas that they have
about the website?
What I'm looking for is something that I could give to a potential
client and ask them to describe some basic aspects of their target
audience, a rough idea of what they want it to look like, or at least
other sites that they like. Stuff like that..
Even if you don't have such a form, I'm sure you all have standard
questions you ask each client before giving a quote :)
Anyone want to share with the class?
If there is interest, I may even put it together on a webpage to help
future people :)
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
japruimraoset.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
attached mail follows:
> > eval() is my favorite templating engine.
> > http://php.net/eval
> Ditto on Eval()
> PHP is already a templating system. Why go the long way around?
eval()? Man, you guys have some seriously large cajones. :p
thnx,
Chris
attached mail follows:
Because its painful and fun at the same time :)
Aleksandar
Quoting Nate Tallman <nate.tallmanconnectivhealth.com>:
> Ditto on Eval()
>
> PHP is already a templating system. Why go the long way around?
>
> On Feb 12, 2008 10:13 AM, Greg Donald <gdonaldgmail.com> wrote:
>
>> On 2/12/08, Xavier de Lapeyre <xavieredsnetworks.net> wrote:
>> > Do any of you guys & gurls know of a way to implement that template
>> > system.
>>
>> eval() is my favorite templating engine.
>>
>> http://php.net/eval
>>
>>
>> --
>> Greg Donald
>> http://destiney.com/
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
attached mail follows:
I still don't understand why general net users don't just like to see
print_r output; it's got all the info they could want, ordered and
structured *shrugs*
vote: text/plain
Aleksandar Vojnovic wrote:
>
>
> Because its painful and fun at the same time :)
>
> Aleksandar
>
> Quoting Nate Tallman <nate.tallmanconnectivhealth.com>:
>
>> Ditto on Eval()
>>
>> PHP is already a templating system. Why go the long way around?
>>
>> On Feb 12, 2008 10:13 AM, Greg Donald <gdonaldgmail.com> wrote:
>>
>>> On 2/12/08, Xavier de Lapeyre <xavieredsnetworks.net> wrote:
>>> > Do any of you guys & gurls know of a way to implement that template
>>> > system.
>>>
>>> eval() is my favorite templating engine.
>>>
>>> http://php.net/eval
>>>
>>>
>>> --
>>> Greg Donald
>>> http://destiney.com/
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
attached mail follows:
Add my vote too for Smarty....
HTH,
-R
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
attached mail follows:
Ryan A wrote:
> Add my vote too for Smarty....
>
> HTH,
> -R
>
>
>
> ____________________________________________________________________________________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
I like smarty and it's very powerful, however what you find is that it's
just a less capable replacement for PHP. If I want conditional
statements to display HTML and/or loop through arrays, why would I want
to do it in smarty tags? Instead of moving display away from logic, it
just replaces the logic with a different language. When I use templates
I pretty much want variable substitution. My next project I'll probably
use HTML files with little bits of PHP echos etc... sprinkled throughout.
-Shawn
attached mail follows:
On Tue, 2008-02-12 at 14:22 -0600, Shawn McKenzie wrote:
> Ryan A wrote:
> > Add my vote too for Smarty....
> >
> > HTH,
> > -R
> >
> >
> >
> > ____________________________________________________________________________________
> > Looking for last minute shopping deals?
> > Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>
> I like smarty and it's very powerful, however what you find is that it's
> just a less capable replacement for PHP. If I want conditional
> statements to display HTML and/or loop through arrays, why would I want
> to do it in smarty tags? Instead of moving display away from logic, it
> just replaces the logic with a different language. When I use templates
> I pretty much want variable substitution. My next project I'll probably
> use HTML files with little bits of PHP echos etc... sprinkled throughout.
I prefer content formatting encapsulation as provided by custom tags.
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. |
`------------------------------------------------------------'
attached mail follows:
On Feb 12, 2008 2:57 PM, Robert Cummings <robertinterjinn.com> wrote:
> I prefer content formatting encapsulation as provided by custom tags.
Decorators?
--
Greg Donald
http://destiney.com/
attached mail follows:
Shawn McKenzie wrote:
> Ryan A wrote:
>> Add my vote too for Smarty....
>>
>> HTH,
>> -R
>>
>>
>>
>> ____________________________________________________________________________________
>> Looking for last minute shopping deals?
>> Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>
> I like smarty and it's very powerful, however what you find is that it's
> just a less capable replacement for PHP. If I want conditional
> statements to display HTML and/or loop through arrays, why would I want
> to do it in smarty tags? Instead of moving display away from logic, it
> just replaces the logic with a different language. When I use templates
> I pretty much want variable substitution. My next project I'll probably
> use HTML files with little bits of PHP echos etc... sprinkled throughout.
>
> -Shawn
re: If I want conditional statements to display HTML and/or loop through
arrays, why would I want to do it in smarty tags?
Things are very different when there are a team of varyingly skilled
people on the job, do you really want a junior designer going in and
changing bits of a php application, when you could limit the damage to a
smarty template?
further; the font end smarty language is definately needed; concider
{if $articles}
{*loop through articles and show in table *}
{else}
{* show no articles message *}
{/if}
in my opinion, being able to dump that kind of ultra simple logic onto
the designers makes:
1: my life much easier
2: my php files much neater
3: my code my "own domain" without worrying about random comments and
breakages from designers
4: the designers happier as they have more freedom and power to control
the display, without having to worry
final note:
personally I output every script to a suitably named .tpl file with a
single line {debug} - job done
attached mail follows:
On Feb 12, 2008 1:58 PM, Nathan Rixham <nrixhamgmail.com> wrote:
> I still don't understand why general net users don't just like to see
> print_r output; it's got all the info they could want, ordered and
> structured *shrugs*
>
> vote: text/plain
I agree. I usually add a little function like this to my PHP projects:
function debug( $var )
{
echo '<pre>';
print_r( $var );
echo '</pre>';
}
--
Greg Donald
http://destiney.com/
attached mail follows:
On Tue, 2008-02-12 at 15:02 -0600, Greg Donald wrote:
> On Feb 12, 2008 2:57 PM, Robert Cummings <robertinterjinn.com> wrote:
> > I prefer content formatting encapsulation as provided by custom tags.
>
> Decorators?
Custom tags (XML style ones anyways) provide support for arbitrary
ordering and omission of optional attributes. They nest nicer than
function calls, and they have the same general formatting as the HTML
with which you are working. Additionally, they provide the opportunity
to punt anything not necessary at run-time to pre-compiled HTML.
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. |
`------------------------------------------------------------'
attached mail follows:
On Feb 12, 2008 3:15 PM, Robert Cummings <robertinterjinn.com> wrote:
> Custom tags (XML style ones anyways) provide support for arbitrary
> ordering and omission of optional attributes. They nest nicer than
> function calls, and they have the same general formatting as the HTML
> with which you are working. Additionally, they provide the opportunity
> to punt anything not necessary at run-time to pre-compiled HTML.
Your solution to templating is XML?
--
Greg Donald
http://destiney.com/
attached mail follows:
Are you creating custom DTD's or 1.1 XHTML Mods then? I'd like to see
that, it's something I'd toyed with a few times in the past but found it
far too time consuming (even for me), and opted for the ol' redefine
everything in CSS
*lightbulb* :: runs off to try css on custom tags <why have i never
tried that before> :: <ponders accessibility..> :: wanders off to waste
time researching anyways>
Robert Cummings wrote:
> On Tue, 2008-02-12 at 15:02 -0600, Greg Donald wrote:
>> On Feb 12, 2008 2:57 PM, Robert Cummings <robertinterjinn.com> wrote:
>>> I prefer content formatting encapsulation as provided by custom tags.
>> Decorators?
>
> Custom tags (XML style ones anyways) provide support for arbitrary
> ordering and omission of optional attributes. They nest nicer than
> function calls, and they have the same general formatting as the HTML
> with which you are working. Additionally, they provide the opportunity
> to punt anything not necessary at run-time to pre-compiled HTML.
>
> Cheers,
> Rob.
attached mail follows:
I used Smarty for long time but now switched to two-step-rendering.
It's way more comfortable (for me). I suggest Zend_Layout + Zend_View
at the moment (framework.zend.com)
--
Łukasz Wojciechowski
attached mail follows:
*sigh* as always, firefox obeys, ie7 goes huh what?
Nathan Rixham wrote:
> Are you creating custom DTD's or 1.1 XHTML Mods then? I'd like to see
> that, it's something I'd toyed with a few times in the past but found it
> far too time consuming (even for me), and opted for the ol' redefine
> everything in CSS
>
> *lightbulb* :: runs off to try css on custom tags <why have i never
> tried that before> :: <ponders accessibility..> :: wanders off to waste
> time researching anyways>
>
> Robert Cummings wrote:
>> On Tue, 2008-02-12 at 15:02 -0600, Greg Donald wrote:
>>> On Feb 12, 2008 2:57 PM, Robert Cummings <robertinterjinn.com> wrote:
>>>> I prefer content formatting encapsulation as provided by custom tags.
>>> Decorators?
>>
>> Custom tags (XML style ones anyways) provide support for arbitrary
>> ordering and omission of optional attributes. They nest nicer than
>> function calls, and they have the same general formatting as the HTML
>> with which you are working. Additionally, they provide the opportunity
>> to punt anything not necessary at run-time to pre-compiled HTML.
>>
>> Cheers,
>> Rob.
attached mail follows:
> I agree. I usually add a little function like this to my PHP projects:
> function debug( $var )
> {
> echo '<pre>';
> print_r( $var );
> echo '</pre>';
>
> }
As an aside, you can save lines when debugging by doing:
echo '<pre>' . print_r( $var, TRUE ) . '</pre>';
thnx,
Chris
attached mail follows:
On Feb 12, 2008 4:18 PM, Greg Donald <gdonaldgmail.com> wrote:
> On Feb 12, 2008 3:15 PM, Robert Cummings <robertinterjinn.com> wrote:
> > Custom tags (XML style ones anyways) provide support for arbitrary
> > ordering and omission of optional attributes. They nest nicer than
> > function calls, and they have the same general formatting as the HTML
> > with which you are working. Additionally, they provide the opportunity
> > to punt anything not necessary at run-time to pre-compiled HTML.
>
> Your solution to templating is XML?
well thats what xslt is, which is pretty nice.
-nathan
attached mail follows:
On Tue, 2008-02-12 at 15:18 -0600, Greg Donald wrote:
> On Feb 12, 2008 3:15 PM, Robert Cummings <robertinterjinn.com> wrote:
> > Custom tags (XML style ones anyways) provide support for arbitrary
> > ordering and omission of optional attributes. They nest nicer than
> > function calls, and they have the same general formatting as the HTML
> > with which you are working. Additionally, they provide the opportunity
> > to punt anything not necessary at run-time to pre-compiled HTML.
>
> Your solution to templating is XML?
Not quite. My template engine allows arbitrary template types to be
defined that are applied in a configured order. One such template type
is similar to XML, but not quite. Specifically, the tags mostly conform
to XML semantics, but they do not require a root nor do they require
that the content in which they are embedded be well formed-- although
they themselves must be well-formed. This allows the use of XML style
custom tags to be used in any kind of document, whether it be HTML,
XHTML, XML, plaintext, whatever. For most projects I work on the
compiler is run to produce the documents requested. As such there is no
cache overhead. In fact, if all you want is HTML, you can compile so
that PHP is eliminated from the final result. I do this for CSS files
(and others) that I have in multiple files that indicate specific CSS
applicability. These are combined to a single CSS file by the template
compiler and require no PHP overhead when requested. In cases of actual
PHP empowered pages, in development I set a configuration variable to
enable detection of changes to any of the dependency template files
which invokes automatic recompilation. In production, auto recompilation
is disabled for better performance.
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. |
`------------------------------------------------------------'
attached mail follows:
On Tue, 2008-02-12 at 21:19 +0000, Nathan Rixham wrote:
> Are you creating custom DTD's or 1.1 XHTML Mods then? I'd like to see
> that, it's something I'd toyed with a few times in the past but found it
> far too time consuming (even for me), and opted for the ol' redefine
> everything in CSS
>
> *lightbulb* :: runs off to try css on custom tags <why have i never
> tried that before> :: <ponders accessibility..> :: wanders off to waste
> time researching anyways>
I don't muck with DTDs and I don't bother with XSL. I could I guess, but
they're more hassle than I care to work with. The tag lib hooks to PHP
handlers that do what you want in good old PHP. The link below (if
you're interested) is a basic example site that illustrates the custom
tag system and various other InterJinn stuff.
http://www.interjinn.com/download/exampleSite.tar.gz
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. |
`------------------------------------------------------------'
attached mail follows:
On Tue, 2008-02-12 at 16:37 -0500, Nathan Nobbe wrote:
> On Feb 12, 2008 4:18 PM, Greg Donald <gdonaldgmail.com> wrote:
>
> > On Feb 12, 2008 3:15 PM, Robert Cummings <robertinterjinn.com> wrote:
> > > Custom tags (XML style ones anyways) provide support for arbitrary
> > > ordering and omission of optional attributes. They nest nicer than
> > > function calls, and they have the same general formatting as the HTML
> > > with which you are working. Additionally, they provide the opportunity
> > > to punt anything not necessary at run-time to pre-compiled HTML.
> >
> > Your solution to templating is XML?
>
>
> well thats what xslt is, which is pretty nice.
Nah, I don't bother with XSLT.
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. |
`------------------------------------------------------------'
attached mail follows:
guys, you all know you can F5 in the "view source" bit of firefox yeah..
save's all the <pre>'s and loads of time!
right click : view source : F5 till your done debugging.
:)
Christoph Boget wrote:
>> I agree. I usually add a little function like this to my PHP projects:
>> function debug( $var )
>> {
>> echo '<pre>';
>> print_r( $var );
>> echo '</pre>';
>>
>> }
>
> As an aside, you can save lines when debugging by doing:
>
> echo '<pre>' . print_r( $var, TRUE ) . '</pre>';
>
> thnx,
> Chris
attached mail follows:
On Feb 12, 2008 4:45 PM, Robert Cummings <robertinterjinn.com> wrote:
> > well thats what xslt is, which is pretty nice.
>
> Nah, I don't bother with XSLT.
i know, i just thought id mention it, since xml was brought up and nobodys
even mentioned xslt yet.
i will likely move away from xslt, but i will be doing something different
than
the straight php based templating, like in code igniter. thats great for
simple
projects, but the thing i hate the most is escaping in and out of php, bleh!
im still experimenting w/ my solution so i wont bother to share it until its
worth
looking at, but for the meantime the basic php mechanism is suitable.
and i certainly dont use eval()! its slow and it opens holes to attacks.
the most simple, way to template w/ php is w/ php, very simply, you will
have a
file, blah.php
and watch how i include another 'template' after the data portion, (the
second template
is blah2.php
<someHtmlTag>
<?=$someDataFromPhp?>
<?php include('blah2.php'); ?>
</someOtherHtmlTag>
and there you have it, that is the most direct way to template w/ php,
backed by the
language itself. there is no need for eval either. i have my reasons for
not liking it,
but as i said, my system is far from ready and well this is cleaner than
writing functions
with strings, thats just horrid, imho.
whwe, rant finished :)
-nathan
attached mail follows:
2008/2/12, Xavier de Lapeyre <xavieredsnetworks.net>:
> Hi,
> I need to develop a website, but my management is rather unstable in his
> vision for the layout.
> I'm thinking of developing the components as classes and functions, and
> then use a template system to render the layout.
> If the management wishes to change the layout, I'll just have to modify
> my template and the jobs' done.
>
> Do any of you guys & gurls know of a way to implement that template
> system.
>
> (The best one I know of is that of Wordpress)
>
> Regards,
> Xavier de Lapeyre
> Web Developer
Hi Xavier!
I think you need a framework and i suggest the Zend Framework.
Good.
--
- -
-- Csanyi Andras -- http://sayusi.hu -- Sayusi Ando
-- "Bízzál Istenben és tartsd szárazon a puskaport!".-- Cromwell
attached mail follows:
On Feb 12, 2008 3:32 PM, Christoph Boget <christoph.bogetgmail.com> wrote:
> As an aside, you can save lines when debugging by doing:
>
> echo '<pre>' . print_r( $var, TRUE ) . '</pre>';
OMG, thanks for that. Lines are so expensive nowadays and all.
--
Greg Donald
http://destiney.com/
attached mail follows:
On Feb 12, 2008 3:37 PM, Nathan Nobbe <quickshiftingmail.com> wrote:
> well thats what xslt is, which is pretty nice.
/me point Nathan to http://en.wikipedia.org/wiki/Rhetorical_question
XSLT sucks, complete overkill.
--
Greg Donald
http://destiney.com/
attached mail follows:
Nathan Rixham wrote:
> Shawn McKenzie wrote:
>> Ryan A wrote:
>>> Add my vote too for Smarty....
>>> HTH,
>>> -R
>>>
>>>
>>>
>>>
>>> ____________________________________________________________________________________
>>>
>>> Looking for last minute shopping deals? Find them fast with Yahoo!
>>> Search.
>>> http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>>
>> I like smarty and it's very powerful, however what you find is that it's
>> just a less capable replacement for PHP. If I want conditional
>> statements to display HTML and/or loop through arrays, why would I want
>> to do it in smarty tags? Instead of moving display away from logic, it
>> just replaces the logic with a different language. When I use templates
>> I pretty much want variable substitution. My next project I'll probably
>> use HTML files with little bits of PHP echos etc... sprinkled throughout.
>>
>> -Shawn
>
> re: If I want conditional statements to display HTML and/or loop through
> arrays, why would I want to do it in smarty tags?
>
> Things are very different when there are a team of varyingly skilled
> people on the job, do you really want a junior designer going in and
> changing bits of a php application, when you could limit the damage to a
> smarty template?
>
> further; the font end smarty language is definately needed; concider
>
> {if $articles}
> {*loop through articles and show in table *}
> {else}
> {* show no articles message *}
> {/if}
>
> in my opinion, being able to dump that kind of ultra simple logic onto
> the designers makes:
> 1: my life much easier
> 2: my php files much neater
> 3: my code my "own domain" without worrying about random comments and
> breakages from designers
> 4: the designers happier as they have more freedom and power to control
> the display, without having to worry
>
> final note:
> personally I output every script to a suitably named .tpl file with a
> single line {debug} - job done
I understand, but my point that I didn't make earlier is that I know PHP
so I use that. Designers that I work with don't know PHP and don't know
smarty and have no desire to know. They know graphic design and HTML.
So I would rather give them some meaningful tags to insert somewhere in
their HTML. Actually moving the logic out of the presentation/design.
So instead of article.tpl:
{if $articles}
{*loop through articles and show in table *}
{else}
{* show no articles message *}
{/if}
I prefer to do this in my article.php:
if($articles) {
include('article.html');
//or optionally file_get_contents() and do replace on tags
}else{
return;
}
And let the designer have his article.html:
<table>
<tr>
<td><?php echo $something; ?></td>
<!-- or {something} that is replaced with echo $something; -->
</tr>
</table>
-Shawn
attached mail follows:
On Feb 12, 2008 5:10 PM, Greg Donald <gdonaldgmail.com> wrote:
> On Feb 12, 2008 3:37 PM, Nathan Nobbe <quickshiftingmail.com> wrote:
> > well thats what xslt is, which is pretty nice.
>
/\ is a statement, not a question ;)
>
> /me point Nathan to http://en.wikipedia.org/wiki/Rhetorical_question
>
> XSLT sucks, complete overkill.
>
the best part about xslt is its a standard, not some new contrivance from
some other corner of the galaxy like smarty.
furthermore i dont think it overkill at all. so lets see, what are you
rendering,
o, a subset of xml, xhmtl. so its actually quite concise. beyond that its
well
suited to target the output from an application to other potential clients
such
as programmatic ones eg. web service clients or mobile devices.
-nathan
attached mail follows:
I don't suggest the use of a template system unless you do need something as complex as XSLT. PHP itself works very well for templating. Just write your code so that the UI code is sepperate from the logic and everything is neat and tidy without adding a layer of complexity. If you want a really clean interface then break out your logic into a service that is connected with your UI layer by XML-RPC, SOAP, or whatever you're comfortable with. At least that extra complexity benefits by making scaling easier and making alternate interfaces easier.
--
Michael McGlothlin
Southwest Plumbing Supply
attached mail follows:
On Feb 12, 2008 4:23 PM, Nathan Nobbe <quickshiftingmail.com> wrote:
> > > well thats what xslt is, which is pretty nice.
>
> /\ is a statement, not a question ;)
Wow dude, you're a rock. I meant my question was rhetorical, not your
statement about my question.
> > /me point Nathan to http://en.wikipedia.org/wiki/Rhetorical_question
> >
> > XSLT sucks, complete overkill.
> >
> the best part about xslt is its a standard, not some new contrivance from
Creation does not prove usefulness.
> some other corner of the galaxy like smarty.
Well I certainly agree with that. Smarty is like the fat cousin you
hope doesn't show up to the 4th of July cookout. But there's always
some n00b developer who brings it up.. next thing you know the project
manager thinks it's a good idea because his "designers" will love to
use it (rofl) and then you're screwed.
> furthermore i dont think it overkill at all. so lets see, what are you
> rendering,
> o, a subset of xml, xhmtl. so its actually quite concise. beyond that its
> well
> suited to target the output from an application to other potential clients
> such
> as programmatic ones eg. web service clients or mobile devices.
REST is the new SOAP. Yaml is the new XML. I'm guessing this news
just hasn't made it into any PHP frameworks yet.
--
Greg Donald
http://destiney.com/
attached mail follows:
On 2/12/08, Greg Donald <gdonaldgmail.com> wrote:
> REST is the new SOAP. Yaml is the new XML. I'm guessing this news
> just hasn't made it into any PHP frameworks yet.
REST for the win.
SOAP is best left for the bathtub.
as far as templating engines go, a while back i wanted to see if i
could find the best template engine to suit all my needs. what i wind
up finding was 100's of PHP-based templating engines, a LOT of them
related to each other in some way. what you wind up doing is learning
a proprietary language that is basically mimicing the constructs of
PHP... and in theory, PHP -is- a templating language already.
so after lots of digging and reading, i've come to the conclusion that
packages like wordpress have it best: just let people write PHP. the
whole "designers shouldn't have to learn PHP" is bunk, because they'll
have to learn Smarty, or XSL, or some other proprietary language.
i would say though that as far as template languages go, XSL/XML seems
to be a decent fit. although XSL can be annoying (and processor
intensive), it's a perfect fit of data in XML that can be validated
and a template in XSL that can be validated and has presentation
logic, variables and is a standard (published by W3C) which is a lot
farther than any of these other templating languages can go.
attached mail follows:
On Feb 12, 2008 6:27 PM, Greg Donald <gdonaldgmail.com> wrote:
> On Feb 12, 2008 4:23 PM, Nathan Nobbe <quickshiftingmail.com> wrote:
> > > > well thats what xslt is, which is pretty nice.
> >
> > /\ is a statement, not a question ;)
>
> Wow dude, you're a rock. I meant my question was rhetorical, not your
> statement about my question.
>
well, my bad then; im just not clever like that i guess :D
>
> > > /me point Nathan to http://en.wikipedia.org/wiki/Rhetorical_question
> > >
> > > XSLT sucks, complete overkill.
> > >
> > the best part about xslt is its a standard, not some new contrivance
> from
>
> Creation does not prove usefulness.
>
> > some other corner of the galaxy like smarty.
>
> Well I certainly agree with that. Smarty is like the fat cousin you
> hope doesn't show up to the 4th of July cookout. But there's always
> some n00b developer who brings it up.. next thing you know the project
> manager thinks it's a good idea because his "designers" will love to
> use it (rofl) and then you're screwed.
>
haha;
i took a look at it when i was doing my initial research for a
templating solution roughly a year ago, but settled on xsl at that time.
i had done some previous research on xsl before then and it made sense.
since then i think its still pretty solid, but im working on my own little
template library where hopefully i wont have to deal with escaping in and
out of php, eg
<?php ?>
more template
<?php ?>
the main issue ive run into with it is my templates will be so small it just
will be too much overhead to splice them all together on a given page load.
> > furthermore i dont think it overkill at all. so lets see, what are you
> > rendering,
> > o, a subset of xml, xhmtl. so its actually quite concise. beyond that
> its
> > well
> > suited to target the output from an application to other potential
> clients
> > such
> > as programmatic ones eg. web service clients or mobile devices.
>
> REST is the new SOAP. Yaml is the new XML. I'm guessing this news
> just hasn't made it into any PHP frameworks yet.
>
rest has its advantages, but it is by far a complete replacement for soap.
as per yaml, i dont know that i ever heard of it until you mentioned it on
the
ruby thread. but that doctrine framework does apparently use it.
and if yaml does take off, ill be sure to tell everyone i discuss it w/ that
greg donald from php-general was on the yaml tip back in the day ;)
-nathan
attached mail follows:
Message-ID: <47B23CFD.4020900
swplumb.com>
Date: Tue, 12 Feb 2008 17:42:37 -0700
From: Michael McGlothlin <michaelm
swplumb.com>
MIME-Version: 1.0
CC: php-general
lists.php.net
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080401010205000908020602"
Subject: Re: [PHP] Template system in PHP
--------------ms080401010205000908020602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
> REST is the new SOAP. Yaml is the new XML. I'm guessing this news
> just hasn't made it into any PHP frameworks yet.
>
REST is fine for small communications but really isn't a very good
solution for large and complex communication. SOAP is the 600 pound
gorilla. Usually I use XML-RPC because it's sort of the middle ground. I
usually use REST mostly for simple services that just need a simple
trigger and response - often stuff I want to run from cron jobs. I save
SOAP for the rare job that REST or XML-RPC can't do although in those
cases I usually stop to consider if I'm making the problem more complex
than it needs to be.
YAML doesn't seem significantly easier (faster & less intensive) to
parse than XML, it doesn't seem as flexible as XML, and it's less
familiar for developers to work with so I don't really see the benefit.
It seems to exist entirely because some people didn't like the way XML
looked. It might be slightly smaller than XML but that's hardly an issue
since you can always compress your data. YAML fits in the same boat as
people pushing binary XML. It doesn't really make a lot of sense. It's
almost always cheaper to throw more CPU time at a problem than man hours
and YAML is less obvious to work with than XML so it doesn't make
business sense. If you really want something fast and non-intensive to
parse then use tab-separated values or something similar.
--
Michael McGlothlin
Southwest Plumbing Supply
--------------ms080401010205000908020602
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJJzCC
Au4wggJXoAMCAQICEFepHrPX/jtOsqWROfPaTCYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDExNjE4MzgwNloX
DTA5MDExNTE4MzgwNlowTDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEpMCcG
CSqGSIb3DQEJARYabWljaGFlbG1AcGx1bWJlcnNzdG9jay5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCzM6wljh4qKQ34hylE3JwaVPmQ+icLyLNnRVkHmPVAkXGRa46/
ly5eDP8G7R4162QHCpg/jxNWqh/NQfpy4QhEaHEu5cBTvLL7xvGzKywsNsSioAiKa6SwYkvo
QIke1trUHaFxlgrGu5yJh5xCLxgfekv+y8/jPpQi3xmRm8bfrs5b6zKlZ6raugj4K3h1gLXy
27sT82P+f/lYDAkQR6XL7oysyLCW62YS9cb5acm7UaztUmvbZoGMyyoSnHzL3TIQEoh7mIB/
iEVI+kGKTyG8XTMczDU+Z7HjxVccyyDjWoV7FGU+1bEySnxXTnBHOcVH1d5prKupF4tZ15Mn
gXIvAgMBAAGjNzA1MCUGA1UdEQQeMByBGm1pY2hhZWxtQHBsdW1iZXJzc3RvY2suY29tMAwG
A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAGkttpE+SXvLbVhluIZ7PJb/3Aywf//Da
SYM85fknLrUKlVJUQEysIL+S8cY9V0Aw39u3Hrd4+mTGruuzdYBkY1uS75OkTQ4KojG0Y1jN
agk5LLFi44wDZxRR8nfplctXiOGeplnR/4Z7hUg256bvVL3aJICvTckKf3XFL87ZOlIwggLu
MIICV6ADAgECAhBXqR6z1/47TrKlkTnz2kwmMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAxMTYxODM4MDZaFw0w
OTAxMTUxODM4MDZaMEwxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxKTAnBgkq
hkiG9w0BCQEWGm1pY2hhZWxtQHBsdW1iZXJzc3RvY2suY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAszOsJY4eKikN+IcpRNycGlT5kPonC8izZ0VZB5j1QJFxkWuOv5cu
Xgz/Bu0eNetkBwqYP48TVqofzUH6cuEIRGhxLuXAU7yy+8bxsyssLDbEoqAIimuksGJL6ECJ
Htba1B2hcZYKxruciYecQi8YH3pL/svP4z6UIt8ZkZvG367OW+sypWeq2roI+Ct4dYC18tu7
E/Nj/n/5WAwJEEely+6MrMiwlutmEvXG+WnJu1Gs7VJr22aBjMsqEpx8y90yEBKIe5iAf4hF
SPpBik8hvF0zHMw1Pmex48VXHMsg41qFexRlPtWxMkp8V05wRznFR9XeaayrqReLWdeTJ4Fy
LwIDAQABozcwNTAlBgNVHREEHjAcgRptaWNoYWVsbUBwbHVtYmVyc3N0b2NrLmNvbTAMBgNV
HRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBABpLbaRPkl7y21YZbiGezyW/9wMsH//w2kmD
POX5Jy61CpVSVEBMrCC/kvHGPVdAMN/btx63ePpkxq7rs3WAZGNbku+TpE0OCqIxtGNYzWoJ
OSyxYuOMA2cUUfJ36ZXLV4jhnqZZ0f+Ge4VINuem71S92iSAr03JCn91xS/O2TpSMIIDPzCC
AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/
DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+
K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG
A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu
Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi
MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBI
jNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZ
foSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj
ViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz
b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBXqR6z1/47TrKlkTnz2kwmMAkGBSsOAwIaBQCg
ggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDIxMzAw
NDIzN1owIwYJKoZIhvcNAQkEMRYEFC9rXH6tApooZVxLzqmIFwZIOfGyMFIGCSqGSIb3DQEJ
DzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQV6kes9f+O06ypZE589pMJjCBhwYLKoZI
hvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu
ZyBDQQIQV6kes9f+O06ypZE589pMJjANBgkqhkiG9w0BAQEFAASCAQCRboJomwrkfQfkNDoW
loojyQccbtbip3M7Ws/O92n0Mf0c2ILm/XdIpBM+AaBYb29+ejKawYq5B2bEj2+O7SV+/WRb
N1H0uJ0B8rmNdrVEtLgeIjLuF87WhIANgsd/Yhy5ge5Aydah4x3IrSBcbDCM0PPnCU5hoVBw
9DO2NjQ58D5KHjnYc1yZQlGWp4rISRuVx20i8TY4uOQGSHXhqPKE6zN+gFYAtvA9Ng64Q7yr
ZcAmowhMbyFxtmpc6aHtQGxaBFc52FtAZ5S6FEB7UHEgmKRnyCLY0OuHihZjf3VUxfu1ORo0
PMfq1vgT1bii4PPJFhB3xTLAjyPSGIyPU5OpAAAAAAAA
--------------ms080401010205000908020602--
attached mail follows:
On Feb 12, 2008 7:42 PM, Michael McGlothlin <michaelmswplumb.com> wrote:
>
> > REST is the new SOAP. Yaml is the new XML. I'm guessing this news
> > just hasn't made it into any PHP frameworks yet.
> >
> YAML doesn't seem significantly easier (faster & less intensive) to
> parse than XML, it doesn't seem as flexible as XML, and it's less
> familiar for developers to work with so I don't really see the benefit.
> It seems to exist entirely because some people didn't like the way XML
> looked. It might be slightly smaller than XML but that's hardly an issue
> since you can always compress your data. YAML fits in the same boat as
> people pushing binary XML. It doesn't really make a lot of sense. It's
> almost always cheaper to throw more CPU time at a problem than man hours
> and YAML is less obvious to work with than XML so it doesn't make
> business sense. If you really want something fast and non-intensive to
> parse then use tab-separated values or something similar.
damn dude, i couldnt have put it better myself if i tried.
i whole-heartedly agree. this is one situation where i feel throwing some
hardware
at it is totally appropriate. the only place you wont escape is the cost on
the
network, but you could always get more bandwidth too, right ? :)
btw. if there are schemas or dtds out there for what im working on, i will
always
run my xml against them and that makes it pretty damn easy to track down
problems.
and if there isnt a dtd or schema file, its usually some syntax i whipped up
for a little
project. and yes, i know yaml has support for validation..
-nathan
attached mail follows:
Message-ID: <47B24425.8000008
swplumb.com>
Date: Tue, 12 Feb 2008 18:13:09 -0700
From: Michael McGlothlin <michaelm
swplumb.com>
MIME-Version: 1.0
To: Nathan Nobbe <quickshiftin
gmail.com>
CC: php-general
lists.php.net
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050905000900020007070309"
Subject: Re: [PHP] Template system in PHP
--------------ms050905000900020007070309
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Nathan Nobbe wrote:
> On Feb 12, 2008 7:42 PM, Michael McGlothlin <michaelmswplumb.com
> <mailto:michaelmswplumb.com>> wrote:
>
>
> > REST is the new SOAP. Yaml is the new XML. I'm guessing this news
> > just hasn't made it into any PHP frameworks yet.
> >
> YAML doesn't seem significantly easier (faster & less intensive) to
> parse than XML, it doesn't seem as flexible as XML, and it's less
> familiar for developers to work with so I don't really see the
> benefit.
> It seems to exist entirely because some people didn't like the way XML
> looked. It might be slightly smaller than XML but that's hardly an
> issue
> since you can always compress your data. YAML fits in the same boat as
> people pushing binary XML. It doesn't really make a lot of sense. It's
> almost always cheaper to throw more CPU time at a problem than man
> hours
> and YAML is less obvious to work with than XML so it doesn't make
> business sense. If you really want something fast and non-intensive to
> parse then use tab-separated values or something similar.
>
>
> damn dude, i couldnt have put it better myself if i tried.
> i whole-heartedly agree. this is one situation where i feel throwing
> some hardware
> at it is totally appropriate. the only place you wont escape is the
> cost on the
> network, but you could always get more bandwidth too, right ? :)
Compression is a good choice for abusing your CPU more to free up
network resources. So network resources shouldn't be much of an issue.
> btw. if there are schemas or dtds out there for what im working on, i
> will always
> run my xml against them and that makes it pretty damn easy to track
> down problems.
> and if there isnt a dtd or schema file, its usually some syntax i
> whipped up for a little
> project. and yes, i know yaml has support for validation..
Validation is handy although my experience is that often vendors don't
bother making sure their stuff validates against their own schemas. Sort
off annoying if you have no choice but to work with them. Usually the
same vendors have crappy documentation too.
--
Michael McGlothlin
Southwest Plumbing Supply
--------------ms050905000900020007070309
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJJzCC
Au4wggJXoAMCAQICEFepHrPX/jtOsqWROfPaTCYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDExNjE4MzgwNloX
DTA5MDExNTE4MzgwNlowTDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEpMCcG
CSqGSIb3DQEJARYabWljaGFlbG1AcGx1bWJlcnNzdG9jay5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCzM6wljh4qKQ34hylE3JwaVPmQ+icLyLNnRVkHmPVAkXGRa46/
ly5eDP8G7R4162QHCpg/jxNWqh/NQfpy4QhEaHEu5cBTvLL7xvGzKywsNsSioAiKa6SwYkvo
QIke1trUHaFxlgrGu5yJh5xCLxgfekv+y8/jPpQi3xmRm8bfrs5b6zKlZ6raugj4K3h1gLXy
27sT82P+f/lYDAkQR6XL7oysyLCW62YS9cb5acm7UaztUmvbZoGMyyoSnHzL3TIQEoh7mIB/
iEVI+kGKTyG8XTMczDU+Z7HjxVccyyDjWoV7FGU+1bEySnxXTnBHOcVH1d5prKupF4tZ15Mn
gXIvAgMBAAGjNzA1MCUGA1UdEQQeMByBGm1pY2hhZWxtQHBsdW1iZXJzc3RvY2suY29tMAwG
A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAGkttpE+SXvLbVhluIZ7PJb/3Aywf//Da
SYM85fknLrUKlVJUQEysIL+S8cY9V0Aw39u3Hrd4+mTGruuzdYBkY1uS75OkTQ4KojG0Y1jN
agk5LLFi44wDZxRR8nfplctXiOGeplnR/4Z7hUg256bvVL3aJICvTckKf3XFL87ZOlIwggLu
MIICV6ADAgECAhBXqR6z1/47TrKlkTnz2kwmMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAxMTYxODM4MDZaFw0w
OTAxMTUxODM4MDZaMEwxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxKTAnBgkq
hkiG9w0BCQEWGm1pY2hhZWxtQHBsdW1iZXJzc3RvY2suY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAszOsJY4eKikN+IcpRNycGlT5kPonC8izZ0VZB5j1QJFxkWuOv5cu
Xgz/Bu0eNetkBwqYP48TVqofzUH6cuEIRGhxLuXAU7yy+8bxsyssLDbEoqAIimuksGJL6ECJ
Htba1B2hcZYKxruciYecQi8YH3pL/svP4z6UIt8ZkZvG367OW+sypWeq2roI+Ct4dYC18tu7
E/Nj/n/5WAwJEEely+6MrMiwlutmEvXG+WnJu1Gs7VJr22aBjMsqEpx8y90yEBKIe5iAf4hF
SPpBik8hvF0zHMw1Pmex48VXHMsg41qFexRlPtWxMkp8V05wRznFR9XeaayrqReLWdeTJ4Fy
LwIDAQABozcwNTAlBgNVHREEHjAcgRptaWNoYWVsbUBwbHVtYmVyc3N0b2NrLmNvbTAMBgNV
HRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBABpLbaRPkl7y21YZbiGezyW/9wMsH//w2kmD
POX5Jy61CpVSVEBMrCC/kvHGPVdAMN/btx63ePpkxq7rs3WAZGNbku+TpE0OCqIxtGNYzWoJ
OSyxYuOMA2cUUfJ36ZXLV4jhnqZZ0f+Ge4VINuem71S92iSAr03JCn91xS/O2TpSMIIDPzCC
AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/
DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+
K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG
A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu
Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi
MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBI
jNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZ
foSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj
ViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz
b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBXqR6z1/47TrKlkTnz2kwmMAkGBSsOAwIaBQCg
ggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDIxMzAx
MTMwOVowIwYJKoZIhvcNAQkEMRYEFCvGCE5eEoJYMZD6kCmvEbzpswE/MFIGCSqGSIb3DQEJ
DzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQV6kes9f+O06ypZE589pMJjCBhwYLKoZI
hvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu
ZyBDQQIQV6kes9f+O06ypZE589pMJjANBgkqhkiG9w0BAQEFAASCAQAUPcICnSIKPO0he28X
WTBpaGeLtz9p/ConCGzD6SFaW3X83UO30JMDCRRKR+ATT54ySltn5aPcLkN49ANq9zSg7e5H
EJzjUjhQ60VC13fbzvRjqRxr1Jo4jCGk9Vjt4HlDzuO8pjVSlUuxzEVp/9T3/O4zNCcRCTId
Wr7ImE0cf4qSATtmXP0EhZOcPC3sC1JHjmY2nW4LcVQ7y2cwB27IoKG+6O9CU7K1yLzwxxYt
MekPb9VfmqW8mJ5jU+w8LyGo+/fgonAxceDhOSw9eKCPPU4b8PM0D1cXBi94WOBfnhkqas4X
7E7U9tIKdgCNPxgojotKIMvsXTqCOfeDYT4mAAAAAAAA
--------------ms050905000900020007070309--
attached mail follows:
Michael McGlothlin wrote:
>
>> REST is the new SOAP. Yaml is the new XML. I'm guessing this news
>> just hasn't made it into any PHP frameworks yet.
>>
> REST is fine for small communications but really isn't a very good
> solution for large and complex communication. SOAP is the 600 pound
> gorilla. Usually I use XML-RPC because it's sort of the middle ground. I
> usually use REST mostly for simple services that just need a simple
> trigger and response - often stuff I want to run from cron jobs. I save
> SOAP for the rare job that REST or XML-RPC can't do although in those
> cases I usually stop to consider if I'm making the problem more complex
> than it needs to be.