On 4/23/02 12:42 PM, "Nathan Bubna" <[EMAIL PROTECTED]> wrote:
> Geir said: >>>> We've discussed this (several times :). >>> >>> :) i thought i'd seen stuff on this a while back. was any conclusion > or >>> consensus reached before? >>> >> >> No. That's why it didn't go in. "Less is more". > > heh. yeah, i'm starting to see that pattern for most requests/complaints. > only a small handful of people really participate in the thread, but > eventually get tired of debating the minutia while waiting for a general > consensus concerning the bulk of the proposal and go quiet. i agree that > less is often more, but always? Not always. Of course not. But putting things in because one person thinks its a good idea for their app right now is *not* a good idea. For example, there are two things I wrote for vel-tools-view, the servlet logger and webappcontextloader. I am using them, and happy to report back that they work so far, and think they should be added to the core if they continue to work out. However, that was only after making sure that it worked in practice. They sure *look* like a good idea, but adding to the codebase to be maintained forevermore isn't. >is the lack of widespread consensus for > proposals really due more to silent opposition or to simple inertia? oh > well, so it goes. > >>>> I wonder if >>>> >>>> #set($foo = " this is a long \ >>>> string") >>>> >>>> Would be better... Then it's clear how much whitespace you want :) I >>>> dunno. What do the non-programmers think? Is \ too weird? >>> >>> hmm. what if we want the line break in the string? >> >> "\n" ? > > ah, but "less is more", no? Not when 'less' == 'incomplete'. Or we say that you *can't* have a line break in the string, and you must do it with two separate strings. Either way, we would need to resolve this. Right? > is it not simpler to say, "if they typed it in > the string, they want it?" i'll say more on this below, but let's not let > this minutia (multi-line string definitions) prevent us from moving forward > on allowing > > #set( $array = > "foo", > "bar", > "woogie" ) > > and > > #myVM( 'one' > $two ) > > i've heard seen no opposition to this, and a fair bit of support (as much as > anything around here tends to get). Hang on - lets address the problem at hand. I was talking about something else.... > >>> would using the \ to >>> define strings over several lines be optional? >> >> No, because !@(Directive+)* -> ~~VM?Directive@@ >> >> (sorry :) > > ok, i'll take your word for it. if it's not optional, then i am -1 on using > \ So how would it work? You can or not (your choice) use \ to denote a line break? >> I understand your concerns - that's what I was alluding to above. But you >> know what's going to happen. Someone is going to float a #set() in the >> middle of a template : >> >> #set($foo = " hello there >> I am a >> string with linebreaks >> and >> where is the whitespace delimited?" >> ) >> >> So what output do you want? > > eh, no output :) :) > but i would want $foo to be a reference to the following string > > " hello there > I am a > string with linebreaks > and > where is the whitespace delimited?" Hm > i think this is much simpler and less 'magic'. think of the input not > visually, but just as a stream of characters. I do every time I revisit the whitespace gobbling thread. > if they put a character, they > must want it. remember, i want velocity to stop gobbling any whitespaces > outside of directives, so i think we should be consistent and not gobble any > inside of strings either. if they really don't want the line breaks, they > shouldn't type them. keep it simple. I agree 100%. That's an interesting proposal :) removal of *all* magic whitespace gobbling :) > >>>> I can go find the stuff I had done a while ago - also the \' and \" >>>> escaping. This will break backwards compatibility, I think. >>> >>> i think this would be good to have so people don't have to hack them in > ala > [snip] >> Agreed - I had it last year, but we never reached consensus. I want to do >> this all the way - i.e. Lets figure out if we go with \ as an escape, and >> figure how we move forward because it will break compatibility. >>> >>> i doubt that this will break things for many people. i don't think > there >>> are that many people that want a literal \' or \" in their strings. >> >> Wanna bet ? > > :-) not much for gambling, sorry. but i'll keep my aforementioned doubt, > thank you. :) >> Also, if not, then do we not have a 'global' rule about >> >> \c >> >> Where c == any character? > > heh, now that would probably break plenty of templates, but i like it. if > we're gonna throw in \' \" and \\ to put ' " and \ in strings, we may as > well have \c always be c. Yes - except for \n :) (I don't really buy that, btw) This is the conundrum we got into last time - do we do the 'usual' escaping rules from Java? Regex 'escaping'? >that would at least make for a simple, consistent > rule. now, as for the question of things like \t and \n. i'm not sure how > i feel about those being tab and line break instead of t and n. the \c -> > c rule is simpler, and if we go with the "leave it if they typed it" > approach to whitespace in strings, i think we have our bases covered and > don't need a special \t or \n. > > to summarize, i'd like to see > > input: > --------------- > #set( $foo = "\c" )$foo > --------------- > output: > --------------- > c > --------------- > and > > input: > --------------- > #set( $foo = > "foo > bar" )$foo > --------------- > output: > --------------- > foo > bar > --------------- > > how's that sound to folks? am i missing anything? > > as for the breakage the \c -> c change would cause... the fix should be > easy. just run through old templates and replace \ with \\ and you're all > set. Not that easy - some people could have stuff stored in databases, or generate stuff on the fly, or... Just pointing out that people find really weird/creative uses, and we have to be careful what we do to them with changes... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting "Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech." - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
