Hi all,
See this fairly half-baked ticket in Lighthouse for context:
https://prototype.lighthouseapp.com/projects/8886/tickets/773
Responding to the proof-of-concept commit, Kangax asked whether * was
used for this sort of thing anywhere else, and in a private email
Tobie flagged up how this in some sense tightly couples the LANG stuff
to the DOM stuff, which of course we're trying _not_ to do.
Meanwhile, I was also having further thoughts, so probably best (as
Tobie suggested to me in email) to 'round things up for discussion on
the list.
My thinking is still being thought, but basically:
1. Escaping HTML is a very common use case for Template, hence my
original desire for a simple and easy built-in way to handle it.
2. The current property expander code could handle functions that
accept no arguments with a trivial change. So just as #{user.name}
currently gets handled correctly, #{user.name.escapeHTML} could as
well (whereas at present you naturally get the source code for the
decompiled escapeHTML function!). That one small change supports my
common use case, but also several others -- toUpperCase, toLowerCase,
trim, ... So that's handy, cheap (both effort and runtime) support
for common use cases without tight coupling. That's useful not just
for transforming strings, either, but also for traversing object
graphs that use accessor methods. So #{niftything.getParent.name}
gives us the name property of the parent of the nifty thing.
(Extending this to support passing parameters to those functions
would, to me, cross a line we don't want to cross in terms of
complexity.)
3. Formatting flags are more commonly specified after the item being
formatted, usually with a colon separator. So #{property:flags}.
None of this prefix-with-an-asterisk stuff.
4. We don't want to implement formatting inside Template, that's scope
creep. If we want anything at all, we want Template to be able to
defer to formatters, and that's it.
5. Formatters could register with Template (for reuse) or be passed in
on an options property in the template constructor.
So I'm seeing two levels here. The first level supports functions in
the property expander code, and is a trivial change. The second level
is to provide semantics around triggering formatters using flags
following the tokens.
In all of this, we will want to consider performance enhancements and
complexity reduction such as Samuel Lebeau's work he mentions here:
http://groups.google.com/group/prototype-core/browse_thread/thread/b9f0b5c82a1fe702/332c887b25c75791#332c887b25c75791
-- T.J. :-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---
