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 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....
> 
> 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 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
> 
> 
> _______________________________________________
> 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

Reply via email to