Re: [PHPTAL] Minimized version of modifiers
I agree with this entirely and would like to add my voice to the 'not shortening' camp. In an environment where the author is also the maintainer and the xml is simple and short then I can certainly see the temptation to try and par the syntax down much like C but years of experience have told me that the benefits of a more descriptive syntax massively outweigh the slight inconvenience of having to type more. I regularly have to deal with another language where aliasing is easy to do and often used to 'save on typing' - SQL. Some of our legacy codebase is stacked with SQL statements over 100 lines long joining 10 or 12 tables and where every table has been aliased - 'attributes' is aliased to 'a' while 'customers' is 'cu' and 'companies' becomes 'c', 'accountDetails' becomes 'ad' and 'products', 'packages' and 'privileges' become 'p', 'pa' and 'pr'. Once you have experienced such coding you really appreciate two very simple points: descriptive is better and there should be one way to do everything. If you are that bothered about having to write long attribute names I can only assume it is either because you don't want to type as much or you are trying to fit everything on one line. The former can be solved using any modern IDE by assigning shortcuts. The latter can be solved by finding a better (and probably much clearer to read) way to flow elements over multiple lines. I generally go for each attribute on its own line, indented 1 level from the node name. Robert Goldsmith On 14 Jul 2011, at 23:05, Darrell Hamilton wrote: I would argue that compile time type inferencing in Scala is not comparable to shortening an attribute name. The intent of the feature in Scala is not to lessen the number of characters typed, but to eliminate the need to explicitly specify the type of a variable if that type is obvious as that could be considered redundant. A side effect of this feature just happens to be fewer characters typed. I would also argue that the only thing really gained by shortening the attribute names is fewer characters typed. After the debate over whose shortened attribute name has the best balance of conciseness and clarity, the only thing different is the number of characters typed. There is no added or simplified functionality. Additionally, with respect to refactoring and maintenance, I would argue that it's far more important to understand the TALES expression assigned to the attribute than having fewer characters to skip over to get to said expression. Anecdotally, I've found that the volume of characters that comprise the TALES expressions, especially for things like tal:attributes, so far out numbers those that comprise the attribute name that saving a handful of characters is made largely irrelevant. Darrell Hamilton, Software Developer, 4over, Inc darre...@4over.com 818-246-1170 ext. 285 On Thu, Jul 14, 2011 at 12:26 PM, Anton Andriyevskyy x.meg...@gmail.com wrote: Darrell, all this sounds good, but it the same ends up that we want to have more concise html with shorter attributes. Concise (but still readable) always wins - a good example would be Scala programming language where compiler infers many things automatically but still keeps things strongly typed, and this ends up with very concise syntax, so I'm remaining sure that conciseness is good and simplifies many things. In case of phptal, not only writing of html becomes faster, but also reading - which is very important when you do refactoring and maintenance. Regards, Anton Andriyevskyy Business Automation Web Development On Thu, Jul 14, 2011 at 8:47 PM, s...@canterris.com wrote: Thank you for contacting Canterris. I???m currently out of the office until July 25. Please feel free to contact Will Freemen (w...@canterris.com) or Canterris Technical Support (supp...@canterris.com) for any support requests. ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: Re: [PHPTAL] Minimized version of modifiers
Thank you for contacting Canterris. I???m currently out of the office until July 25. Please feel free to contact Will Freemen (w...@canterris.com) or Canterris Technical Support (supp...@canterris.com) for any support requests. ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: [PHPTAL] Minimized version of modifiers
Robert, I'm typing ~500...700 symbols in a minute, so it was not told about typing from my side. Again, my opinion is that when you do something for yourself and you are very experienced, next level up is shorter notation - then you read understand refactor faster. Well I'm not pushing this change, I'm just interested if someone used to do so and how it was done. Regards, Anton Andriyevskyy Business Automation Web Development On Fri, Jul 15, 2011 at 10:59 AM, Robert Goldsmith rgoldsm...@names.co.ukwrote: I agree with this entirely and would like to add my voice to the 'not shortening' camp. In an environment where the author is also the maintainer and the xml is simple and short then I can certainly see the temptation to try and par the syntax down much like C but years of experience have told me that the benefits of a more descriptive syntax massively outweigh the slight inconvenience of having to type more. I regularly have to deal with another language where aliasing is easy to do and often used to 'save on typing' - SQL. Some of our legacy codebase is stacked with SQL statements over 100 lines long joining 10 or 12 tables and where every table has been aliased - 'attributes' is aliased to 'a' while 'customers' is 'cu' and 'companies' becomes 'c', 'accountDetails' becomes 'ad' and 'products', 'packages' and 'privileges' become 'p', 'pa' and 'pr'. Once you have experienced such coding you really appreciate two very simple points: descriptive is better and there should be one way to do everything. If you are that bothered about having to write long attribute names I can only assume it is either because you don't want to type as much or you are trying to fit everything on one line. The former can be solved using any modern IDE by assigning shortcuts. The latter can be solved by finding a better (and probably much clearer to read) way to flow elements over multiple lines. I generally go for each attribute on its own line, indented 1 level from the node name. Robert Goldsmith On 14 Jul 2011, at 23:05, Darrell Hamilton wrote: I would argue that compile time type inferencing in Scala is not comparable to shortening an attribute name. The intent of the feature in Scala is not to lessen the number of characters typed, but to eliminate the need to explicitly specify the type of a variable if that type is obvious as that could be considered redundant. A side effect of this feature just happens to be fewer characters typed. I would also argue that the only thing really gained by shortening the attribute names is fewer characters typed. After the debate over whose shortened attribute name has the best balance of conciseness and clarity, the only thing different is the number of characters typed. There is no added or simplified functionality. Additionally, with respect to refactoring and maintenance, I would argue that it's far more important to understand the TALES expression assigned to the attribute than having fewer characters to skip over to get to said expression. Anecdotally, I've found that the volume of characters that comprise the TALES expressions, especially for things like tal:attributes, so far out numbers those that comprise the attribute name that saving a handful of characters is made largely irrelevant. Darrell Hamilton, Software Developer, 4over, Inc darre...@4over.com 818-246-1170 ext. 285 On Thu, Jul 14, 2011 at 12:26 PM, Anton Andriyevskyy x.meg...@gmail.com wrote: Darrell, all this sounds good, but it the same ends up that we want to have more concise html with shorter attributes. Concise (but still readable) always wins - a good example would be Scala programming language where compiler infers many things automatically but still keeps things strongly typed, and this ends up with very concise syntax, so I'm remaining sure that conciseness is good and simplifies many things. In case of phptal, not only writing of html becomes faster, but also reading - which is very important when you do refactoring and maintenance. Regards, Anton Andriyevskyy Business Automation Web Development On Thu, Jul 14, 2011 at 8:47 PM, s...@canterris.com wrote: Thank you for contacting Canterris. I???m currently out of the office until July 25. Please feel free to contact Will Freemen (w...@canterris.com) or Canterris Technical Support ( supp...@canterris.com) for any support requests. ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: Re: [PHPTAL] Minimized version of modifiers
Thank you for contacting Canterris. I???m currently out of the office until July 25. Please feel free to contact Will Freemen (w...@canterris.com) or Canterris Technical Support (supp...@canterris.com) for any support requests. ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: [PHPTAL] Minimized version of modifiers
Does anyone know if Sean is out of the office? ;) On 15 Jul 2011, at 09:28, s...@canterris.com wrote: Thank you for contacting Canterris. I???m currently out of the office until July 25. Please feel free to contact Will Freemen (w...@canterris.com) or Canterris Technical Support (supp...@canterris.com) for any support requests. ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: [PHPTAL] Minimized version of modifiers
Do not take it globally, please.
I love Phptal and I have not found anything better for PHP so far.
But I still insist aliases would be helpful
Even PHP itself has aliases for some functions.
Hope it makes senseforsomeone.
But I'm not here to argue.
I just wanted to get some experience in such aliasing shared.
Regards,
Anton
On Friday, July 15, 2011, Robert Goldsm rgoldsm...@names.co.uk wrote:
There will always be examples in every language that attempt to show it is
'better' than another :)
How about we just agree that for those who want a modifiable syntax and have
a desire to skip the verbosity of xml there are many alternative templating
systems for PHP - smarty and twig being examples. Personally, I consider them
as prime examples of why PHPTal is a good templating language and a warning
as to what could happen if we are not careful ;)
Robert
On 15 Jul 2011, at 09:22, Anton Andriyevskyy wrote:
and also, for guys who love all this long and annoying xml things,
attributes etc...
Is it not true that setting up routing in concise way like with F3 framework:
F3::route('GET /login', 'PageLogin::run');
... is really more clean and readable then 5-lines in XML in configuration
file in Java-word.
Nothing against Java, I'm just talking about conciseness in coding
Thanks!
Anton
On Fri, Jul 15, 2011 at 11:17 AM, Anton Andriyevskyy x.meg...@gmail.com
wrote:
Robert, I'm typing ~500...700 symbols in a minute, so it was not told about
typing from my side.
Again, my opinion is that when you do something for yourself and you are
very experienced,
next level up is shorter notation - then you read understand refactor
faster.
Well I'm not pushing this change, I'm just interested if someone used to do
so and how it was done.
Regards,
Anton Andriyevskyy
Business Automation Web Development
On Fri, Jul 15, 2011 at 10:59 AM, Robert Goldsmith rgoldsm...@names.co.uk
wrote:
I agree with this entirely and would like to add my voice to the 'not
shortening' camp. In an environment where the author is also the maintainer
and the xml is simple and short then I can certainly see the temptation to
try and par the syntax down much like C but years of experience have told me
that the benefits of a more descriptive syntax massively outweigh the slight
inconvenience of having to type more.
I regularly have to deal with another language where aliasing is easy to do
and often used to 'save on typing' - SQL. Some of our legacy codebase is
stacked with SQL statements over 100 lines long joining 10 or 12 tables and
where every table has been aliased - 'attributes' is aliased to 'a' while
'customers' is 'cu' and 'companies' becomes 'c', 'accountDetails' becomes
'ad' and 'products', 'packages' and 'privileges' become 'p', 'pa' and 'pr'.
Once you have experienced such coding you really appreciate two very simple
points: descriptive is better and there should be one way to do everything.
If you are that bothered about having to write long attribute names I can
only assume it is either because you don't want to type as much or you are
trying to fit everything on one line. The former can be solved using any
modern IDE by assigning shortcuts. The latter can be solved by finding a
better (and probably much clearer to read) way to flow elements over
multiple lines. I generally go for each attribute on its own line, indented
1 level from the node name.
Robert Goldsmith
On 14 Jul 2011, at 23:05, Darrell Hamilton wrote:
I would argue that compile time type inferencing in Scala is not
comparable to shortening an attribute name. The intent of the feature
in Scala is not to lessen the number of characters typed, but to
eliminate the need to explicitly specify the type of a variable if
that type is obvious as that could be considered redundant. A side
effect of this feature just happens to be fewer characters typed.
I would also argue that the only thing really gained by shortening the
attribute names is fewer characters typed. After the debate over
whose shortened attribute name has the best balance of conciseness and
clarity, the only thing different is the number of characters typed.
There is no added or simplified functionality. Additionally, with
respect to refactoring and maintenance, I would argue that it's far
more important to understand the TALES expression assigned to the
attribute than having fewer characters to skip over to get to said
expression.
Anecdotally, I've found that the volume of characters that comprise
the TALES expressions, especially for things like tal:attributes, so
far out numbers those that comprise the attribute name that saving a
handful of characters is made largely irrelevant.
Darrell Hamilton,
Software Developer,
4over, Inc
darre...@4over.com
818-246-1170 ext. 285
On
--
Anton Andriyevskyy
Business Automation Web Development
Re: Re: [PHPTAL] Minimized version of modifiers
Thank you for contacting Canterris. I???m currently out of the office until July 25. Please feel free to contact Will Freemen (w...@canterris.com) or Canterris Technical Support (supp...@canterris.com) for any support requests. ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: Re: Re: [PHPTAL] Minimized version of modifiers
Thank you for contacting Canterris. I???m currently out of the office until July 25. Please feel free to contact Will Freemen (w...@canterris.com) or Canterris Technical Support (supp...@canterris.com) for any support requests. ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: [PHPTAL] tal:attributes and checkboxes
Now I was thinking to use tal:attributes=checked x something like that to be sure that it the item is checked after the checking submit the form. Is this totally wrong way to get my idea to work? Sounds OK. PHPTAL understands boolean attributes like checked and selected, so if you get x to be truthy/falsy, it will work. Reading session directly in the template is probably a stretch, but you could do something like: $phptal-favorite_checked = $_SESSION[...]; -- regards, Kornel Lesiński ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: Re: [PHPTAL] tal:attributes and checkboxes
Thank you for contacting Canterris. I???m currently out of the office until July 25. Please feel free to contact Will Freemen (w...@canterris.com) or Canterris Technical Support (supp...@canterris.com) for any support requests. ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: [PHPTAL] PHPTAL interpreter takes too long to recover from encountering an unterminated HTML element
On Thu, 14 Jul 2011 17:17:27 +0100, romtek rom...@gmail.com wrote: If my template code contains an unterminated HTML element (e.g. img src=stuff.jpg, br, etc.), PHP interpreter takes minutes to process a request and display an error message. And while doing that, it consumes lots of CPU and RAM. Could this be improved? That definitely shouldn't happen — PHPTAL throws exception as soon as it finds an error and that takes milliseconds. Do you have your own exception handler? If PHP terminates on max execution time, where does it stop? A related request: considering that the web technology has shifted away from XHTML, it would be cool if PHPTAL wasn't as strict on XML requirements as it is now. E.g. it would be very convenient if some HTML elements, such as img, br, hr, didn't need to be terminated. There's HTML5 output option already. Input parsers are be replaceable. You can write HTML one if you want :) -- regards, Kornel Lesiński ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: Re: [PHPTAL] PHPTAL interpreter takes too long to recover from
Thank you for contacting Canterris. I???m currently out of the office until July 25. Please feel free to contact Will Freemen (w...@canterris.com) or Canterris Technical Support (supp...@canterris.com) for any support requests. ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
