On 12/18/01 7:38 PM, "Will Hartung" <[EMAIL PROTECTED]> wrote:
> From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> >> You can help with that :) >> >> The thing to straighten out is the part about 'what you are trying to do'. >> What I mean by that is that you have a mental and working model of how >> things should work. >> >> I have a different point of view, looking at the VelValue class as > something >> that can be used as a universal tool for comparison and valuation that > would >> require no special changes to the core of Velocity. > What a missive... > In many ways, this is mostly my fault in many ways. > > I was dragged in late for this particular phase of the project. > > What we were doing previously was leveraging the J2SE MessageFormat class to > let the scripting users add variables to text. MessageFormat is little more > than a fancy 'printf'. > > However, the users were wanting to add conditional clauses to the messages > they were creating. So, the original proposal was for some ugly XMLesque > '<if var="MYVAR"> ... </if>' thing that only supported Boolean values. All > of the boolean values would be created within the scripting language before > being sent to the Templating Engine. > > When it got dumped in my lap, rather than just nodding and saying "Yessu > yessu", it just struck me that it was pretty silly to have to jump through a > hoop to write the parser and lexer for this XMLesque IF statement. Because, > it certainly was not XML. It wasn't anything. I had heard of Velocity as > being a "simple template engine", and it seemed like it would be a better > fit, and we'd get some more features for "free". > > Of course, I wasn't aware of the limitations of Velocity at that time, > naively thinking it was more flexible than it is. Anyway, it was "approved", > and down the slippery slope I slid... > > The first issue I noticed was that we couldn't compare anything but > Integers. It didn't make sense to me to support ".equals()" but not > ".compareTo()" for the objects, so I went through and made the comparison > logic work with items implementing "Comparable". The slippery slope gets > steeper. > > The problem with this is that I could pass in Any Olde Object into Velocity, > and Any Olde Object could implement a "smart" .compareTo(). But Integers > were not "smart". Although an Integer is Compareable, it's not Compareable > to anything other than Integers (well, maybe it can compareTo Numbers, but I > don't know). > > So, now if that stayed, I'd have to explain to the users that given this: > > $AOO = AnyOldeObject (preset from scripting language) > #set($IntValue = 1) > > then this: > > #if ($AOO < $IntValue) > > will work as expected, but this: > > #if ($IntValue < $AOO) ? > > will fail. That is not something easy to explain to users. This is > non-obvious behavior. > > That's a caustic case, but the core issue is that simply uplifting from > "Integers" to "Comparable" for the < <= == => >'s doesn't solve the issue we > would have without placing pretty silly restrictions for reasons that are > not at all visible to the user. > > Now, all of this could have been usurped if we just passed Integers down, > save for the fact that all the numbers in our scripting language are > Doubles. > > Also, if we did that, we wouldn't have had support for working with String > inequalities either. > > Finally, it seemed like it would be nice if the operations the scripters > were used to doing in the scripting language would translate well over into > the Template language. > > The Slippery Slope is pretty much vertical now. > > So, I felt once I had to bite the bullet on adding ANY other data type for > the inequalities and to be able to add math, then I felt it was easier to > make a Magic Value that was Very Smart about types and translations, etc. > (and conveniently fit well into the structure of our scripting language), > than it was to make a bunch of type specific code within Velocity to handle > these extensions. > > Down the rabbit hole I go, and VelocityValue springs from the ether. I did > VelocityValue in order to make Velocity more generic and isolate it from our > system as much as practical. > > To this point, I hadn't had to touch the actual grammar or parser, I just > played with the internal interpreter. My goal was to, as best as I could, > keep Velocity working as it did before, particularly from a performance > point of view. I didn't want my changes to impact the performance on folks > who chose not to use them. > > But after we fed the first cut to the users, the first reaction was "Where > are the floating point numbers?". This was important because a lot of the > numbers come from a medical model, and it would be nice if the users didn't > have to go through any shenanigans to use them. And believe me, I thought up > some really contrived solutions to the problem. We finally settled on things > like this: #(if $BODYTEMP * 1000 > 9860)You have a fever#end. But, anyone > would look at that and say that its a pretty weak solution. > Right - so here's where I say 'use tools'. Like, why not a data model in the context where you can do things like #if( $tool.hasFever( $bodytemp ) ) You have a fever #end > Now there's no slope at all, just simple freefall. > > When confronted with a choice between changing the tool, and changing the > user, it's almost always valid to look into changing the tool first. Adding > Doubles to the parser took less than a 1/2 hour. An easy half hour spent > that will save innumerable hours on the phone, in meetings, etc. > > For the Clinicians, #(if $BODYTEMP > 98.6) is downright intuitive. Again, #if( $tool.hasFever( $bodytemp ) ) > 99% of the time, the scripters are dealing solely with "scalars" rather than > anything more sophisticated. In this context, Numbers, Strings, and Dates > are all "scalars". Being able to do things like: #(if ($Date1 - $Date2) > 7) > You're a week overdue for your examination. It was due on $Date2 #end is a > Good Thing. Again, this I think is 100% business logic. Assume that $patient is an object that contains information about the patient #if ($tool.isExamOverdue( $patient ) ) You are overdue for your examination. It was due on $patient.nextExamDate() #end I'm clearly winging it here, but you see how a tool-oriented solution might work? > I guess the guiding philosophy here is that everything that I want to do is > "business" logic. Perhaps, the original idea of just passing in a slew of > booleans calculated from within the scripting as was originally proposed > would have better fit the model of what Velocity is. If Velocity didn't > already have the comparison operations or simple math, then we probably > would have just stopped right there and either adopted it, or abandoned it > right away. But, since it had the simple operations, just sitting there > teasing us and staying just out of reach, and since it wasn't that hard to > adapt to the new datatypes and behaviors, I just dived in and did it. > I personally believe that there actually is room to improve, but not the distance that you went, because if I remember from reading the code, there are huge assumptions made that VelocityValue() will work for everyone, and certainly implemented some, well, uncommon algebras, such as the uncommutative #set ($foo = 1 + "234") // result is an Integer, 235 #set ($foo = "1" + 1) // result is a String, "11" Or better expressed : "1" + 1 != 1 + "1" Now, I don't know about your designers, but non-commutative algrebras are a little beyond those I usually run across... > I certainly don't want to go against the philosophy of the community or the > vision of the creators. I hadn't even seen Velocity before, say, two weeks > ago. I only subscribe to the dev-list, not the user-list. That's great that you took to it so fast... > But, to me, I guess the question that I need put forth is whether the vision > for Velocity includes giving it the extensibility to where it can be turned > into something that isn't within that vision? Yes indeed it can, demonstrated but the fact you were able to take the code and make it do what you want. > Are you all comfortable with extending Velocity to the point where I could > make the additions I made, only with an add-on package rather than changes > to the core? Hm. Another issue we try to do is make sure that the language syntax is 'stable'. That doesn't mean it doesn't change ever though. > It seems to me that once you open up that gate, then next thing you know, > you've got a FrankenVelocity that looks not like what the creators dreamed > initially. Well, the dream of the creators isn't the sole driving force here. > I guess I just need to be clearer as to what the path is for Velocity, so I > can see better where something like extensible Comparisons, extensible Math, > and parsing Doubles can fit in. The problem with some of the latter is that you then are really wandering out of the land of templating into scripting/programming. To me (and I may be wrong because I have only gotten a short glimpse of what you are doing) you are making the templating system be your programming environment to some serious degree. The system is meant for accessing data and rendering it, and much of the flow logic is there for the purposes of layout. I mean, you should have seen the fight over '%'. :) > > I understand the Slippery Slope. Y'all have settled on your core and nailed > it to the mountain. "If we add Doubles, then they'll want X, and then Y, and > next thing you know, we have Python or something!" We already have a Python in the world and people are making templating systems that really keep you close to that language - things such as Cheetah. You can get real close to java with JSP using the scriptlets as another example. However, I personally don't want to be that close to the language, or at least not the designers. Yes, there are times when I go 'ug' when I forgot something in my model and can't do a calcuation or comparison in the template. But then I praise the insight and iterative improvement that went into developing the templating model when I find that I can change one object to reflect changing conditions (suppose you sold your system to be used on aliens where the core body temp was 112deg...) and my templates continue to work. > I didn't mean to push it a little more to the edge, but, like I said, I just > wanted to give something back that I thought would be useful to others. (And > note that I distinctly only posted these changes to the developer list, not > the Users list. That Masses don't know this exists, as I wanted tacit > approval of the project leaders, leaving it up to y'all to give it to > them...There was actual, calculated Madness to that Method...) Oh, they all know :) And we don't really work that way, giving it to them. It's very participatory, or was when things were changing fast. Now, it's settled down, is mature, and people really depend on it. So we are a little conservative for that reason too. > > If you can give me suggestions on where I can start looking to being able to > make my changes more modular, then I can try to do that. But, at the moment, > there's code in the interpreter. "If it ain't an Integer, then begone foul > beasts" is pretty clear in its intention. Difficult to get around, IMHO. And > it's not clear I'm allowed to change that code. (For assorted definitions of > "allowed"). You can do what you want with the code - the code was written and licensed so that you could change what you want, do with it what you want. Getting it back into the main code base is a little harder :) > Basically, I'm stuck. I'm keeping MyVeloctity-1.2 as is, becuase we have > users using it and *shock* documentation on how to use it. There's code > being made now against this new model, but that doesn't mean that all is > lost for the rest of you. Run, while you still can! Well you may be stuck, but how long would it take you to build a toolkit and convert the templates? You started working on this two weeks ago, so there can't be that many templates to do. And there is a community here that might be able to help with figuring out a good toolkit, although I think that you would have no problem doing it... > Sorry to cause such a fuss. I'll shut up now. > No fuss - don't be sorry. These are good conversations to have... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
