[Webwork-devel] mailing-lists

[Vedovato P. <pao...@pr...>]

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