hi folks concerning the mailing-list and the problem with sourceforge (above all not to be able to search the archives :-( i've setup the mail archive to monitor our two lists:
http://www.mail-archive.com/webwork-user%40lists.sourceforge.net/ http://www.mail-archive.com/webwork-devel%40lists.sourceforge.net/ of course it's monitored only since jan 2002 (the setup date) but there is also the possibility to add all the archived mails by doing this: http://www.mail-archive.com/faq.html#import perhaps sombody has the knowledge and permissions to do it. hope this helps. cheers -paolo > -----Urspr�ngliche Nachricht----- > Von: Kjetil Paulsen [mailto:[EMAIL PROTECTED]] > Gesendet: Freitag, 1. M�rz 2002 10:11 > An: Victor Salaman; [EMAIL PROTECTED] > Betreff: RE: [Webwork-devel] RE: Refactorings... Again > > > > I think sourceforge lists are screwing with our minds. I did > > send an email > > against this refactoring. Anyhow, I do have other emails here > > from other > > people that voted against the refactoring. > > sorry to hear that, I got one or two mailings from people who > came with suggestions. The SF lists are really screwing up > these days, everytime I do a commit it seems like the mailer > tries to mail every source file :-{ > > > > > Oh, how nice, maybe can rename the project StrustWork. :) LOL > > this has been a topic for some time actually, to seperate the > core from the views so that you can have only one of the view > technologies deployed > > > > > I could really care less if we have 1 jar, or 100. I am > > talking for a common > > user, what's easier.. finding out what each jar does or using 1 jar? > > is it hard to understand what webwork-velocity does .. > > > > > I think that maybe we have lost site of perspective what the > > goal of the > > project is. The aim was to have a lightweight and powerful > > framework that > > could be extended to your wildest dreams while not being tied > > to any view > > technology. > > this is what the goal of the refactoring was to have the core > by itself and you can extend it with any view tech you want to use > > > Now if you add the fact, that now you must figure out which > > jars to deploy > > and what not, and tweaking different options, etc... It > increases the > > learning curve of the frameworks and renders it useless to a > > lot of people. > > you don't have to you get one common package that does > everything what the cutrrent distrib has been doing, except > now you have the choice to take things out > > > > The principal thing we should have acquired from Struts, we > > haven't done > > it.. which is to "build skeleton" and an empty jar with all view > > technologies+taglib+etc be in the skeleton. That way I can > > just tell a user, > > "build skeleton" and start making pages! ... instead of > > explaining for 20 > > minutes what each jar does, the different deployment options, etc... > > we can do that, make an ant target that builds a skeleton > with most of the core and the common jars and the directory > structure... feel free > > > > > So, are you positive that there no more movements? Can I > > refactor my code > > now without fear? > > hope so, my only consern now is that > webwork.core.config.Configuration refers to > DefaultConfiguration in common.config and we don't want that, > maybe all config should be in core. Thoughts? > > And also the property files, we introduced common.properties, > not completly sure yet what goes in here from default.props > > /kjetilhp > > _______________________________________________ > Webwork-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/webwork-devel > _______________________________________________ Webwork-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webwork-user
