Nathan Bubna wrote: [...] > a lot of what MessageTool does is *already* duplicated in the > vel-struts package. both StrutsHtmlTool and StrutsBeanTool have similar > code offering message resource access. and IMO both classes do it poorly. > so my recommendation would be to completely pull those portions out.
Nathan, most of the code in the tools was pulled right from the Struts code base. > the LinkTool class (which is not Struts dependant) also duplicates some > portions of the StrutsHtmlTool (link(), baseRef(), and whatnot), and again I > would argue it does a far better job of dealing with links in templates. Again, right from the Struts code base. Can you be more specific about how you feel it should be improved? > overall my impression of the vel-struts package so far is that it is written > to mimic the functionality of the struts taglibs. frankly, i think that is > the wrong approach. i think having a > "make-velocity-in-struts-work-like-jsp-in-struts" mentality limits this > project to a utility for developers who want to port apps from struts/jsp to > struts/velocity. seeing as i wanted to build an app from scratch with > struts and velocity, i found the current vel-struts codebase to be poorly > organized and unintuitive. Your impression is right. In a first phase we are planning to provide approx. equivalent support for Struts in Velocity as there is support for Struts in JSP. This includes mainly support for access to resources of the Struts framework but does not include the more HTML-ish tags like the form tags. And yes, currently the context tools are organized and named similarly to the corresponding JSP custom tags. This is on purpose and the reasons are the following: - Struts developers should be able to communicate with each other independent of the view technology they use. This would be difficult if Velocity has a completely different view API. - I feel it would be quite arrogant to come in and redesign the entire view API that has been developed and used successfully by very many people. I believe it is more appropriate to match first what is there and then build on it. - A similarly structured view API will allow Velocity users to work with all the existing tutorials, users guide, examples, etc. - Finally it will help existing Struts developers to make the move to Velocity I agree view you that the view API can be improved and it is my strong believe that we should work on a better APIs. But the base should really be something that is roughly comparable what exists today in the Struts world. Does that make sense to you? > in the same vein, my MathTool (also not Struts dependent) is IMO more > flexible and robust and has been used (read tested) quite a bit. The current math tool is really only there because we needed a simple tool to test the toolbox mechanism, etc. If you have something better I am glad to replace that. > i don't mean to be contentious, but i think the current direction of the > vel-struts project is wrong. you and the other developers are free to > disagree, of course, and you can take or leave my code as you wish. I'm > just trying to help out a bit. Well, you haven't been very specific about what is wrong with the current approach. More specific points would help me. I'll have a look at your code and probably understand better. But, I believe that the right first step is not to overthrow the view API but to match what is there today on the JSP world and build on that. Fortunately the toolbox support will allow us to easily replace one tools by another tool. So nothing is written in stone. The next planned steps are: 1) To get some basic documentation ready, including user guide and reference documentation for the tools in general and the Struts support specifically. (I'm currently working on that) 2) Go over the existing Struts View API again and look in details at all the available API methods. Decide what of it should be made available in the Velocity world. We don't plan to support the convenience stuff that generates HTML, like the form tags. Gabe > > > > That's great. We will pull back the Commons 'rupert' as well and get this > > going. > > cool. sounds like there's more demand (and supply :-) out there for a > DateTool lately. it's probably time you guys put one in the tools > sub-project to get people using the same one. i like that last suggestion > today about making it grab the locale from the request. maybe sometime this > week i'll clean-up/rewrite my old rupert one to do that and follow the > pattern of the ones i contributed today. > > Nathan Bubna > [EMAIL PROTECTED] > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Gabriel Sidler Software Engineer, Eivycom GmbH, Zurich, Switzerland -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
