Tim said: ... > > 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.
hmm. i do agree that the current naming and organization of the project is at times confusing, ugly, and/or inconsistent. i think it might be worth the time to do some major reorganization, but *only* if we can come up with and agree on a satisfactory system of names and paths. > I tried to keep the name changes as minimal as possible, but produce > more logical sense. ... > 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. ;-) it's not the CVS work. it's a matter of inertia and consistency. we have to maintain a common "language" (i.e. system of terms and names) in order to communicate effectively. even if the existing "language" is not ideal, it's not wise to rewrite it all without some common agreement and understanding first. ... > > i think it'd be best to stay consistent on naming or at least > > discuss such changes. > Well, please consider this the discussion. :-) i suppose. however, though it is related to documentation, it really should precede it and thus probably deserves a new thread and proposal. > 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. :-( oh. sorry. :-/ > 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.) ... > > none of the toolbox configuration snippets (that i noticed) > > demonstrate using the <scope> attribute. > > I didn't even know the scope attrib existed. Ha! this is one reason docs need be a requirement before release! :-) you've probably also missed out on <create-session> and <data> too, eh? > 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? hmm. probably plenty from ServletToolboxManager, there might be a nugget or two hiding in XMLToolboxManager. ChainedContext talks about the internal context search order (note: i just fixed that javadoc), and the various ToolInfo interfaces and implementations have some meaningful comments. oh, and the javadocs of the various tools-tools and struts-tools are definitely worth a look. > (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 think that's a shame. personally, i use javadocs quite heavily. especially since i'm not a huge fan of doing html docs myself (though i don't really mind writing README's), i tend to primarily use javadoc to explain things. ... > Before I start sending in patches, I'd prefer to get some confirmation > that they are even wanted. help with docs is always appreciated around here :) ... > As for the finished product... I'm in the dark as to how Jakarta stuff > works. heh. me too. i know the java, but i've yet to really look into how things work around here with jakarta-site, xdocs, dvsl, or what-have-you. i suppose i'll have to pay more attention to that stuff now that i'm a committer. > 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? hopefully not. > 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? frankly, i don't know. geir? any wisdom regarding the website/docs? > 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? i'm fairly ambivalent when it comes to logos. but i am curious, what's up with the arrow-circle? reminds me of the recycling logo. ... > > 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 :-) ... ah, but then one must wonder why the ToolboxManager & co. aren't in the toolbox package, but the tools are. :-( you know, as i think about it, i'm not really sure why we even have a separate folder tree/jar/et. al. for the non-struts tools. there's all of three useful classes in there, and one of them is already dependent on the view package. i'm seriously thinking we ought to fold them into the view tree/package. i think it'd be nice to cut things down to just VelocityView and VelocityStruts (or whatever you want to call them). can anyone give a really good reason to maintain a separate library just for these tools? after all, they are "view tools." Nathan Bubna [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
