Re: XmlGen Ant Task
I have just released an Ant task to generate code from XML files and Velocity templates called XmlGen. http://xmlgen.sourceforge.net This looks very nice and very well documented. Could anybody tell me if this could take part as a contribution to velocity project ? If I would have a vote(but I'm just a user), than I would vote for the inclusion of your contribution :). Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release VelocityTools 2.0-alpha1
Nathan Bubna-3 wrote: > > VelocityTools 2.0 is, in my estimation, ready for an alpha release. I > Why not user the same version number like Velocity? This way it would be much simpler for the users to match versions. E.g. they would intuitively use Velcity 1.6 with VelocityTools 1.6. Ahmed. -- View this message in context: http://www.nabble.com/-VOTE--Release-VelocityTools-2.0-alpha1-tf3991455.html#a11361412 Sent from the Velocity - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Interesting Velocity2js!
Hi, There's an interesting Velocity to JavaScript compiler: http://velocity2js.sourceforge.net/ Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: performance improvements
I haven't seen any data as to specifically how fast Velocity is vs. JSP or other tools - Ahmed do you have benchmarks you might share? I don't have a benchmark application that could be publicly used, otherwise I would have already submitted it to Apache :). At my previous job there were several applications combinations that ran on tests systems with various framework combinations. e.g. Few average values relevant for Velocity that I've saved: - Struts+Velocity vs Struts+JSP webapplication ~2.5x slower - CMS with Velocity vs CMS with JSP ~ 5x slower (lot of dynamic content with frequent page changes, Velocity cache shows it's limits). - SiteMesh+Velocity vs SiteMesh+JSP webapplication ~3.5x slower (here is the fault of the SiteMesh velocity decorator too, since the FM one is faster). Applications were implemented with several technologies for performance, learnability, reliability and other parameter measurements important in a commercial context. Basically Velocity is at least 2 times slower than JSP for all tests I've seen last year,(however it was not getting slower - but JSP was constantly getting faster :) ). Most of the results from 2002/2003 have reversed values (at that time Velocity was faster with the same magnitude, hence the reason it was included in so many benchmarks :) ). Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove Author tags?
Rather than sniping, how about some concrete ideas for what you'd like to see next? Or better yet, since you are hanging out in the developer list, some test cases or patches? I have a few ideas, but I don't know how to implement them :). The "obvious" need of something does not imply the ability to implement it :). E.g. one that might help improve the performance of Velocity would be a "velocity2Java" compiler, something that could be run like the JSP compiler. AFAIK the big part of performance gain of JSP in the last few years come exactly from this corner. It would be a fantastic gain if for a first version the compiler: - would work only off-line, so not at runtime like the JSP one, so only "pre-compile". - would be able to convert only part a of the templates (e.g. those pretty static and with big contexts), so not 100% coverage. At least these "generated" Java files would be than easier to profile than the Velocity engine + templates. Well, just an idea, but I really don't know if it's feasible for Velocity. Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove Author tags?
Basically removing all the @author tags from the velocity code base and docs and replacing it with 'Velocity development community' and a link to the dev-list. How about doing this? -1 from me as a user. In a lot of projects when I had problems, I was able to ask directly the author(s) of that class/utility, and this was very helpful. The complete project was too big and the work of just too many people. Yes, and this is excactly what we want to get rid of. None of the code is owned by any of us and sometimes the person named in the source is not even any longer around. That is the whole point of community. I don't think it's a good idea to get rid of exactly that thing :). My experience is that for a lot of open source projects, the so called "active community" is full of *zealots* that are ready all the time to rip the new user's request apart instead of helping. In most cases however, the author is very kind and helps, and most of the time knows better why he "designed that thing so", or just has very useful "insider information". Maybe you want to avoid contacting the authors, but that is the main reason people still use many of those projects (and in many cases hire them as consultants :) ). If you want to know, which committer wrote a specific line of code (which is much more interesting than who is mentioned in a file), use svn blame or the subversion viewer. That is what tools are there for. Of course :). However just reading what's on the screen takes less than a second, and most from the "Human Resources" have no ideas about such tools :). Do you really think the users do care so much about "cosmetics" when the concurrent products/technologies get real improvements? At least I do not really care about 'products' or 'technologies'. This "vision" from you can be really seen in the "evolution of Velocity" in the last few years, don't you think? :). Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove Author tags?
Basically removing all the @author tags from the velocity code base and docs and replacing it with 'Velocity development community' and a link to the dev-list. How about doing this? -1 from me as a user. In a lot of projects when I had problems, I was able to ask directly the author(s) of that class/utility, and this was very helpful. The complete project was too big and the work of just too many people. Why don't you people concentrate on important things, e.g. like performance? Do you really think the users do care so much about "cosmetics" when the concurrent products/technologies get real improvements? I'm just curious :), Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site build
Do you personally recommend apt or xdocs? It looks like apt is the easier format. Velocity should eat it's own dog food and use XDocs + DBF (DocBookFramework). Otherwise it's not really convincing. Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: improved error reporting
Have you confirmed this with 1.5? Many have changed. Of course :). E.g. Click-Framework is using Velocity 1.5 even before it was beta. Your best bet of improving this is to list specific suggestions. Start a wiki page perhaps. The more specific you are, the more likely you'll see the improvement you'd like. OK. This might take a while (to search the cases where messages are misleading). Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new directive - #evaluate
Start a thread and discuss them. OK, I'll make a list/document first with more details and explanations. For example-- what type of error reporting are you looking for? Basically better and smarter error/warning messages from Velocity. Many of the today messages are not helping besides the fact that the developer observers that something went wrong. The idea is that the more a message/error describes the real problem the quicker can the developer fix it. Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new directive - #evaluate
Be curious if there are any comments. -1 for this, from me as a long time Velocity user who advocated several projects to stay with Velocity (and managed to achieve this with only one). "Simplicity" is the *only* argument and advantage Velocity has these days. If you start to f. up with this, you can directly "invite" all your remaining users to switch to FreeMarker :(. What Velocity needs? 1. Speed. 2. Speed. 3. Speed. 4. Better (and smarter) Error Reporting. 5. Better and simpler whitespace control for the output. Just my 2 cents, Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity DocBook Framework 1.0
[Let's say, it will not get better and I'm already bored out of my mind again tinkering with XSL and XML.] This is the CfV for the first release of the Velocity DocBook Framework. It is intended for creating and maintaining high quality documentation generated in the DocBook format. The framework itself is completely generic, non-intrusive, 100% bio-degradable and environment-friendly. The release candidate is available from http://people.apache.org/~henning/DocBook-Framework/ The documentation (which also serves as showcase example is visible at http://people.apache.org/~henning/DocBook-Framework/DocBook-Framework-1.0.pdf) Very nice, thank you. I'm using XMLMind and with such tools, DocBook writing is very efficient. One thing however that always drives me crazy is image inclusion/handling(especially for PDF generation): all solutions so far fail handle it gracefully :(. I hope DBF will avoid the same mistakes. (No special explanations are need, just a look over the generated PDF and even a child can say that it's not how "it should be"). Even if I have no vote :) : [x] +1 Let's do it [ ] 0 I don't care. [ ] -1 No, because __ Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google Summer of Code project idea request
Ideas from the community? What about some *real* performance improvements? 4 years ago, when Velocity gained a big number of users, it was because Velocity was much faster than JSP. This is not true anymore, as JSP is much faster and scalable now. Maybe it would be the time to try to regain a part of your users with a "Performance Improvements Project". Of course, it doesn't sounds spectacular, but the effect would be one for sure :). Velocity needs really almost no new features(except better error reporting and whitespace control), but better speed is always good. Ahmed. P.S. I don't expect Velocity to be again faster than JSP (it was up to 5 times faster in the past), but now the situation is almost reversed, so reducing the gap a little would be great. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
