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 ;)
On 15 Jul 2011, at 09:22, Anton Andriyevskyy wrote:
> and also, for guys who love all this looooong 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....
> On Fri, Jul 15, 2011 at 11:17 AM, Anton Andriyevskyy <x.meg...@gmail.com>
> 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
> next level up is shorter notation - then you read & understand & refactor
> Well I'm not pushing this change, I'm just interested if someone used to do
> so and how it was done.
> Anton Andriyevskyy
> Business Automation & Web Development
> On Fri, Jul 15, 2011 at 10:59 AM, Robert Goldsmith <rgoldsm...@names.co.uk>
> 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 mailing list
PHPTAL mailing list