(to answer my own question in the subject: yes :)
Terry,
> Just to put things into proportion: Your list of possible
> enhancements is quite small when compared to the total number
> of features currently in Velocity.
That would be true for any product :)
> As you yourself suggest, your list includes a number of
> things that many members of this list feel are inappropriate
> for the template engine per se. Not that they aren't useful,
> but perhaps not as part of the core template engine.
No. The *List* I provided did not include any feature that I
would delegate to another framework (like a WebApp-FW), but only
features missing in Velocity. I just tried to make clear that I
am not keen on adding this and that to velocity.
> Those that remain are valid candidates, but hardly represent
> anything like a huge deficiency (as might be inferred from
> your original message).
If I scan the tools I regularely use, then I find *many* methods
that only provide workarounds for the limited capabilities of Velocity.
And that is true for many developers / designers! For instance, I
have to wrap every method call that requires a long as a parameter,
just because Velocity can't handle longs and so doesn't find the
method. So instead of writing $myObj.printLong(1) I have to write
$myObj.printLong("1") and adding a second method to $myObj. Besides
the fact, that I cannot deal with long values in VTL.
I agree, that velocity works for the purposes I use, but there are
quite a few flaws (for instance the escaping issue pops up regularely
on the users list - and that is such a basic thing).
> Again, I'm not disagreeing with the merits of specific items
> in your list. It's just that, even if they were all added,
> the total effect would be a relatively minor overall increase
> in the value of Velocity (which is already quite valuable as
> it stands).
>
> Don't you agree?
Again, no :). I don't think that correct Number-Handling and Map-Support
are luxury. If you monitor the user-list than you can find out, that
there are things, that really, really *need* to be done.
To make it clear (once again): I am *not* saying velocity suckz! I
*do* say, that the current project status suckz! And as I've shown
in the past, I am willing to do something. So I'd like to see the
project status / developer lead issue solved real soon so that we
can move forward and continue to fix bugs, add features and do some
optimizations / refactoring.
Peter
> Regards,
>
> Terry
>
> ----- Original Message -----
> From: "pero" <[EMAIL PROTECTED]>
> To: "'Velocity Developers List'" <[EMAIL PROTECTED]>
> Sent: Monday, March 03, 2003 7:36 AM
> Subject: RE: AW: velocity 1.3.1 final?
>
>
> > > I too use Velocity and find it quite stable. I've also
> extended it
> > > (as have
> > > most) with specialized tools, and as a result, it does precisely
> > > what I want it to do. I agree that it's important to
> take a look at
> > > the bug processing and make sure it is robust. But I don't
> > > understand your comment about losing ground in
> comparision to other
> > > engines. What does that mean in terms of being able to do things
> > > with other alternatives that you can't do with Velocity?
> >
> > A lot of things :( "Hot" issues have been:
> >
> > - Number support (Currently you can only cope with Integers)
> > - Map support (Currently only lists)
> > - Whitespace-Handling (The current Whitespace-Handling is
> > somewhat "unpredictable" and you cannot suppress
> Whitespaces without
> > nasty workaround #* *#)
> > - "local scope" for context-variables (very useful in Macros)
> > - More a bug: Macro-Reloading behavior and (perhaps)
> Macro-Overloading
> >
> > Of course you can extend Velocity with Tools to get the
> functionality
> > you need, but some things are so basic, that a Tool would
> be a really
> > bad design (Number- and Map-Support for instance)
> >
> > I would not say that features like full blown Localization-Support
> > belong to a template engine (as FM has it, AFAIK). So I would
> > concentrate on things as described above.
> >
> > BTW: There are patches for 2-3 of the 5 things above :)
> >
> > There are other things I could imagine, that would make the
> life of a
> > template-designer and thus a the life of a Java-Developer
> much easier.
> > One thing could be some sort of Filter-Mechanism (with which the
> > "Whitespace-Gobbling" could be solved) and so on.
> >
> > So there are some things, that are really needed (Number,
> Map), Bugs
> > and some nice features. Don't get me wrong: I *don't* want to put
> > *everything* into velocity! Many things belong to WebApp-Frameworks
> > and stuff.
> >
> > My $0.02
> >
> > Peter
> >
> > > Regards,
> > >
> > > Terry
> > >
> > > ----- Original Message -----
> > > From: "xMySign for Velocity" <[EMAIL PROTECTED]>
> > > To: "Velocity Developers List" <[EMAIL PROTECTED]>
> > > Sent: Monday, March 03, 2003 3:46 AM
> > > Subject: AW: AW: velocity 1.3.1 final?
> > >
> > >
> > > > Is there something in particular which is preventing you from
> > > > using the stable or development branches of Velocity?
> > >
> > > I'm using Velocity and it is quite stable, but it really
> lost ground
> > > in comparison with other template engines, and - that's the most
> > > important thing - there are quite a few bugs reported
> (have a look
> > > at the archives) and no one is fixing them, or - even worse -
> > > someone fixed it, but no one reviewed the patch so the
> bug is still
> > > left in the code. IMHO that's not the right way to find some
> > > interested commiters. I really would like to hear something
> > > about the thoughts of the current committers. what should be
> > > the future of Velocity? How we can find a lead?
> > >
> > > mike
> > >
> > >
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
