Nathan wrote: > and here comes feedback... :-) Thanks...was beginning to think nobody cared. ;-)
> why all the renaming? (e.g. VelocityStruts -> StrutsView?) Well, when I started looking at the soup of names, it was confusing to me, and considering I've been following along for quite a while, concluded it might confuse others even more. I tried to keep the name changes as minimal as possible, but produce more logical sense. Ex. VelocityServlet link pointed to the /view/ directory but references the "VelocityViewServlet". VelocityLibrary (which brings to mind "velocity.jar") really contains Tools and lives in /tools/, but calling it VelocityTools causes the redundant tools/tools reference anyway. Ugh. I proposed a change to "VelocityViewServlet", leave view/ alone, and call the menu entry ViewServlet since most everything can be prefixed in this sub-project as VelocitySomethingOrOther. (Perhaps the menu entry though should remain consistent despite the ugly long length.) Consistency was and is the tough part with so many re-uses of "view" "servlet" "library" "tool"... I'm trying :-) I'm want to help sort things out. And I don't know the best approach, but I certainly don't want to stay with a confusing status quo just to avoid a couple cvs delete/adds. ;-) > most of these names were somewhat informally decided upon > in dev list discussions. Hmm... Okay, I go on/off v-dev and might have missed that, so of course do what folks think is best. > think it'd be best to stay consistent on naming or at least > discuss such changes. Well, please consider this the discussion. :-) Obviously I'm not a committer, so it's not like I went out and made the changes in CVS. <grin> Also that's why the subject line is "proposed update"... and why I only sent it to the DEV list, not V-USERS. Wanted feedback from you folks first before regular users knew anything about my proposed changes. But alas, looks like as of this morning Pandora was let out of her box. :-( We can wordsmith the docs until they are more suitable for everyone. My goal is to help get clear docs out there so a 1.0 release can be made. (Gabriel wisely has docs listed as one of the req'ts before a release.) > i know typos are hard to avoid, but a few in there are > somewhat critical. > says the VelocityLayoutServlet's reference for screen content is > $BODY_CONTENT when it's actually hardcoded as $screen_content) Thanks, I'm sure there are other errors too. That one is easily fixed. In fact, it's now done. ;-) > none of the toolbox configuration snippets (that i noticed) > demonstrate using the <scope> attribute. I didn't even know the scope attrib existed. Ha! Agree, that should be added to the docs somewhere. How's it work? Say - speaking of stuff that might only exist in JavaDocs... what other JavaDocs might be good to pull up into the documentation pages? (I find that generally JavaDocs beyond the JSDK usually suck or don't exist, so I normally don't go there first. I'm betting others folks are perhaps lazy like me and wanting to see some docs first before they invest the time to CVS checkout and look at JavaDoc. ) > I could provide cvs diffs if my arm was twisted, but geez I > changed/added/renamed quite a few files to make this happen. It would be > easier to just send a tarball. ;-) > yeah, but easier for who? :-) I anticipated this reponse, that's why I said I'd provide them if asked. ;-) Before I start sending in patches, I'd prefer to get some confirmation that they are even wanted. And of course, I'll happily get in the habit of sending patches for corrections like that $screen_content error that are no-brainers. > Also moved the tree inside /velocity/tools/ to make it easier to type > and/or reference. This of course makes a bit of an issue for the > velocity/tools/tools directory (it works of course...just seems a bit > bit redundant redundant. > moving trees == renaming. see previous comments :) If it's merited, renaming in CVS isn't _that_ hard. <grin> Seriously though... I honestly did this directory change mostly so I could post a version for folks to eval that had links that worked. As for the finished product... I'm in the dark as to how Jakarta stuff works. Right now, there isn't a link to the sub-projects, except for a single page link: http://jakarta.apache.org/velocity/toolsubproject.html (Speaking of consistency again, notice how the VelocityViewServlet is referenced from there as simply "View" subproject. ;-) Obviously that won't be the production link for the new sub-project, right? The velocity CVS package is NOT what we see on the website. Ergo: If module "jakarta-velocity" becomes /velocity I figured "jakarta-velocity-tools" might become /velocity/tools How wrong am I? The reason I needed to care, btw, was so I could change the top logo link from "Velocity" to "Velocity Tools" and send links back to the correct directory. BTW - did no one like my logo artwork? Incidentally, I made the smaller logo(s) to help navigation and allow the browser to resize a bit narrower than with the big VELOCITY logo. But still, the printed out version causes an issue since the Apache Jakarta Project logo takes up 85% of the page. :-( > although i've always hated the /tools/tools too. though it would break > b.c., i admit i'd be willing to support & implement a change to > /tools/library. "Tool/Tool" or "Tool/Library" seems like a poor analogy. Howabout "tools/toolbox"? Seems a better analogy since tools do live in a toolbox, and of course there is already a ToolBoxManager :-) Now that I look at it, if that name change was made, then it would make more sense to move the Toolbox configuration from the tools/view docs: http://crufty.happysearch.com/velocity/tools/view/docs/index.html#Instal lation To: /velocity/tools/toolbox/docs/index.html Thoughts? Also - I hope to hear more feedback both postive/negative. Really excited here to be able to help any way I can. :-) Cheers, Tim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
