RE: [Webwork-devel] RE: Refactorings... Again

[Kjetil P. <kje...@mo...>]

> 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.

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 :-{

>=20
> 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

>=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?

is it hard to understand what webwork-velocity does ..

>=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.

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=20
> jars to deploy=20
> and what not, and tweaking different options, etc... It increases the=20
> learning curve of the frameworks and renders it useless to a=20
> 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=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...

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

>=20
> So, are you positive that there no more movements? Can I=20
> refactor my code=20
> 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?=20

And also the property files, we introduced common.properties, not =
completly sure yet what goes in here from default.props

/kjetilhp