Menu
▾
▴
webwork-devel — WebWork development
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(316) |
Dec
(117) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(197) |
Feb
(229) |
Mar
(293) |
Apr
(177) |
May
(84) |
Jun
(40) |
Jul
(43) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Victor S. <vsa...@ho...> - 2002-03-01 16:32:29
|
Hi Matt: >Since we have not released a 1.0 I think there is some license to refactor >packages a little more than if 1.0 was already released. The That's ok, and I agree 100%, when it's necessary. refactoring >that makes sense to me is webwork.core and webwork.example. Under >webwork.core, I would propose webwork.core.view to contain taglib, >velocity, >and xslt related stuff. This will make it easier for deployment and further >growth. Agreed... but why the f*** did webwork.action,webwork.config had to be touched? This was not necessary. WebWork has been a mature product for a long time now. Heck, the only reason I still run Windows is because I have apps that I can only run there.... And all the rest of the webwork packaging could have changed, to webwork.timbuktu.taglib, but it wouldn't mean recompilation of just about every Action you had in the planet. WebWork did not come out yesterday, and a lot of people have stuff in production using it (including me), so thanks for giving me extra work :) >Yes, don't need this because we could use Ant to handle this but I >do think it is needed to make it a cleaner separation. > >For the distribution, I think we should have a webwork.war (deploy examples >and test), webwork-taglib.jar, webwork-xslt.jar, webwork-velocity.jar, >webwork-all.jar (all views together), webwork-example.jar. We need the >ability to differentiate releases for view support and examples. > >Here are my opinions what is yours. > Please read this article carefully, http://www.joelonsoftware.com/articles/fog0000000356.html It shows you the differences between perception and reallity. May God help us all... >-Matt > >----- Original Message ----- >From: "Kjetil Paulsen" <kje...@mo...> >To: "Victor Salaman" <vsa...@ho...>; ><web...@li...> >Sent: Friday, March 01, 2002 4:53 AM >Subject: RE: [Webwork-devel] RE: Refactorings... Again > > > > > In my mind I just can't picture what the names mean.... > > common == common to > > all components, but core == needed by all components ... > >common are common stuff to webwork :) >like most of the time you would use one or more of these view technologies >togheter with WW, and also some or all of the classes in the other common >packages > > > So therefore at this > > point I can't > > really tell you where to put it, all I can say is that all > > the configuration > > functionallity should be together. either all in common or > > all in core. > >my reason for putting it common was that XML confiurator uses 3rd party xml >libraries but I think maybe it should be all in core .. > >Matt, what do you say? > > > > > >And also the property files, we introduced > > common.properties, not completly > > >sure yet what goes in here from default.props > > > > > > > hehe, it's your doing, you figure it out... haha > >will do .... > > > > > > .... maybe it's time for me to branch the codebase to another > > project, and > > go back to basics, after all this is open source, and ww has > > a liberal > > license.... maybe I'm just getting old... heck, who knows. hehe > >up to you.. don't see why these changes would make you do that - the >functionality is the same it's just layed out in another way > >/kjetilhp > >_______________________________________________ >Webwork-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webwork-devel > > > > _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx |
|
From: <fbe...@py...> - 2002-03-01 15:52:01
|
My vote would be to do the simplest (keep it as it is right now) for now to get 1.0 out. Configuration process could then be enhanced to be done in a single XML file with cleanly separated sections. Cheers ___________________________ François Beauregard, b.ing. Vice-président Recherche et développement Pyxis Technologies www.pyxis-tech.com T : (450) 681-9094, poste 102 F : (450) 681-5758 fbe...@py... |
|
From: Philipp M. <me...@me...> - 2002-03-01 15:36:03
|
On Fri, Mar 01, 2002 at 09:51:16AM -0500, Jim...@do... wrote: > My opinion is we should have one configuration file for core WebWork > settings, and one configuration per view technology incorporated. > > For example, if I choose to use WebWork-Velocity, I should have 2 > configuration files. I don't like that becauce if I like to use more than one view technology. Therefor I suggest seperating the core webwork settings and the view mapping. The webwork settings should be set via the interface that the servlet spec provides: web.xml and deployment settings. The view mapping should be configurable to be either property file based or database based and so on. That means we need an interface which provides the action name to action class mapping and an action name to view mapping. Should be easy to do IMHO. -billy. -- Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0 eLösungen 89077 Ulm Fax: +49-731-399 499-0 |
|
From: <ma...@sm...> - 2002-03-01 15:15:10
|
Separating out the views allows incremental releases to support separate views. It is not whether they are causing end user problems. I think the separation is important. People can grap one jar for all view support or an individual jar. This will allow the different views to release independently.
The fact that most people are extending ActionSupport will bite people anytime we make a change. It is easier now than later. If we choose not to have the *core* package then that would be possible. I still thing we should have the *example* and a *view* package under webwork somewhere.
Just to clarify, I am proposing dropping the *common* package. I think this is confusing.
If people don't want to do anything and roll back and release as is that is fine too. I think we need people to voice up and Rickard needs to weigh in.
To speak on behalf of Kjetil, he did send out this e-mail below and there was not much feedback. *So*, lets now take time to talk this out and make a good decision before making any further changes. So it seems the next step will be to roll back and deal with refactoring later in the OS integration or deal with it now. It is not my decision I'm just trying to facilitate discussion to reach a concensus.
-Matt
**********************************************
Hi
Questions:
* Strictly speaking, Velocity and Xslt support, are addons to the WW core - IMO. Anyone?
* Should this be moved? (to f.ex src/addon lib/addon)
- this would make container compliance even easier
Someone said something about out of date Velocity, the -dep-1.2-rc3.jar
is in CVS and I guess there are a 1.2 release out there.
* Is there a reason NOT to get the 1.2 release into CVS?
* Should we use the -dep- file or not
- if not we have to include commons from jakarta (I guess ?)
- THIS should at least not be part of the core!
* The documentation states that the later is the way to go - we should be consistent
This would make 3 builds
- core
- core-with-addon
- examples-with-addon
/kjetilhp
>
> My opinion is that we have lost sight of what this projects original goals
> where. WebWork is supposed to be easy to use. Giving the users a
> multitude of deployment options just makes things more complicated than
> they need to be. Quite simply I am unconvinced that Velocity, the Taglibs,
> and XSLT being deployed with the Action engine has ever caused problems
> for the end user.
>
> My advice is that we roll back the recent changes to package structure,
> fix the examples, make sure it deploys on Tomcat, and then release WebWork
> 1.0.
>
> -Maurice
>
>
> > -Matt
> >
> > ----- Original Message -----
> > From: "Kjetil Paulsen" <kje...@mo...>
> > To: "Victor Salaman" <vsa...@ho...>;
> > <web...@li...>
> > Sent: Friday, March 01, 2002 4:53 AM
> > Subject: RE: [Webwork-devel] RE: Refactorings... Again
> >
> >
> >
> >> In my mind I just can't picture what the names mean....
> >> common == common to
> >> all components, but core == needed by all components ...
> >
> > common are common stuff to webwork :)
> > like most of the time you would use one or more of these view technologies
> > togheter with WW, and also some or all of the classes in the other common
> > packages
> >
> >> So therefore at this
> >> point I can't
> >> really tell you where to put it, all I can say is that all
> >> the configuration
> >> functionallity should be together. either all in common or
> >> all in core.
> >
> > my reason for putting it common was that XML confiurator uses 3rd party
> > xml
> > libraries but I think maybe it should be all in core ..
> >
> > Matt, what do you say?
> >
> >>
> >>> And also the property files, we introduced
> >> common.properties, not completly
> >>> sure yet what goes in here from default.props
> >>>
> >>
> >> hehe, it's your doing, you figure it out... haha
> >
> > will do ....
> >
> >
> >>
> >> .... maybe it's time for me to branch the codebase to another
> >> project, and
> >> go back to basics, after all this is open source, and ww has
> >> a liberal
> >> license.... maybe I'm just getting old... heck, who knows. hehe
> >
> > up to you.. don't see why these changes would make you do that - the
> > functionality is the same it's just layed out in another way
> >
> > /kjetilhp
> >
> > _______________________________________________
> > Webwork-devel mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/webwork-devel
> >
> >
> >
> >
> >
> > _______________________________________________
> > Webwork-devel mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/webwork-devel
> >
>
>
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
|
|
From: <Jim...@do...> - 2002-03-01 14:51:27
|
My opinion is we should have one configuration file for core WebWork
settings, and one configuration per view technology incorporated.
For example, if I choose to use WebWork-Velocity, I should have 2
configuration files.
jim
Mike Cannon-Brookes <mi...@at...>
Sent by: web...@li...
03/01/2002 09:15 AM
To: "web...@li..."
<web...@li...>
cc:
Subject: Re: [Webwork-devel] RE: Refactorings... Again
On 1/3/02 8:11 PM, "Kjetil Paulsen" (kje...@mo...) penned the
words:
<lots of crap deleted>
>
> And also the property files, we introduced common.properties, not
completly
> sure yet what goes in here from default.props
PLEASE tell me this does not mean there are more configuration files? WW
already has too many! (webwork.properties, views.properties - which should
go IMHO, actions.xml, log4j config - and now more!)
Is there no way we can aggregate this all into one config file? I see no
reason for views.properties to hang around (especially considering
everyone
needs to refactor their code after this rewrite anyway!) - can we axe that
in favour of actions.xml?
Log4J config is probably hard to get rid of - but I usually have 1 log4j
config per server or application which is good enough.
What does common.properties do? How does this relate to
default.properties?
Why can't we roll it all into webwork.xml? ;)
-mike
_______________________________________________
Webwork-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webwork-devel
|
|
From: <fbe...@py...> - 2002-03-01 14:42:53
|
I recently looked at WebWork and found it great. I played with a few samples and made a few of my own and was very happy. Since it was obvious that 1.0 was almost ready, I decided to wait for the release before I use WebWork on a real project. Therefore, my word is : Please, get this 1.0 out ASAP. Since the refactoring is completed (still properties file issue to resolve), my vote would be to keep it this way and that the community makes an effort to make sure nothing is broken, then release, then ... A release before next friday would be great. Cheers, ___________________________ Francois Beauregard, b.ing. Vice-president Recherche et developpement Pyxis Technologies www.pyxis-tech.com T : (450) 681-9094, poste 102 F : (450) 681-5758 fbe...@py... |
|
From: Maurice P. <Ma...@Vi...> - 2002-03-01 14:28:34
|
Hey, Victor has some very valid points. I in no way got the impression from the mailings on this list that the package structure of WebWork was going to be changed by your refactorings. My impression was that you would modify the build process to distribute cleanly on more app servers and fix the examples. Everyone subclasses off of ActionSupport, so you have broken a lot of code people have out there by moving it. For this reason alone I would have strongly disagreed with the package restructuring. On Friday, March 1, 2002, at 07:00 AM, Matt Baldree wrote: > > Goals? > 1. I think we need to remove examples and test from mainline of code. > 2. I think we should better delineate/separate the view support. > 3. I think we need a distribution that will ensure WW will deploy on all > Servlet 2.3 and JSP 1.2 containers and remove the release coupling of > views. > 4. Release 1.0. Number 4 on your list is what's important. All the other stuff you list could have been goals for 2.0. Victor has been holding back big changes he would like to make so as not to destablize the current tree. I don't see any reason we shouldn't do the same with your goals. > Here are my thoughts on above. > > Since we have not released a 1.0 I think there is some license to refactor > packages a little more than if 1.0 was already released. The refactoring Not true. Some of us were trying to keep the current code stable to make the 1.0 release. If we ever actually released 1.0 we could then begin work on 2.0 during which your goals of separating the Action engine from the view technologies could be done. > > Here are my opinions what is yours. My opinion is that we have lost sight of what this projects original goals where. WebWork is supposed to be easy to use. Giving the users a multitude of deployment options just makes things more complicated than they need to be. Quite simply I am unconvinced that Velocity, the Taglibs, and XSLT being deployed with the Action engine has ever caused problems for the end user. My advice is that we roll back the recent changes to package structure, fix the examples, make sure it deploys on Tomcat, and then release WebWork 1.0. -Maurice > -Matt > > ----- Original Message ----- > From: "Kjetil Paulsen" <kje...@mo...> > To: "Victor Salaman" <vsa...@ho...>; > <web...@li...> > Sent: Friday, March 01, 2002 4:53 AM > Subject: RE: [Webwork-devel] RE: Refactorings... Again > > > >> In my mind I just can't picture what the names mean.... >> common == common to >> all components, but core == needed by all components ... > > common are common stuff to webwork :) > like most of the time you would use one or more of these view technologies > togheter with WW, and also some or all of the classes in the other common > packages > >> So therefore at this >> point I can't >> really tell you where to put it, all I can say is that all >> the configuration >> functionallity should be together. either all in common or >> all in core. > > my reason for putting it common was that XML confiurator uses 3rd party > xml > libraries but I think maybe it should be all in core .. > > Matt, what do you say? > >> >>> And also the property files, we introduced >> common.properties, not completly >>> sure yet what goes in here from default.props >>> >> >> hehe, it's your doing, you figure it out... haha > > will do .... > > >> >> .... maybe it's time for me to branch the codebase to another >> project, and >> go back to basics, after all this is open source, and ww has >> a liberal >> license.... maybe I'm just getting old... heck, who knows. hehe > > up to you.. don't see why these changes would make you do that - the > functionality is the same it's just layed out in another way > > /kjetilhp > > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel > > > > > > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel > |
|
From: Mike Cannon-B. <mi...@at...> - 2002-03-01 14:15:36
|
On 1/3/02 8:11 PM, "Kjetil Paulsen" (kje...@mo...) penned the words: <lots of crap deleted> > > And also the property files, we introduced common.properties, not completly > sure yet what goes in here from default.props PLEASE tell me this does not mean there are more configuration files? WW already has too many! (webwork.properties, views.properties - which should go IMHO, actions.xml, log4j config - and now more!) Is there no way we can aggregate this all into one config file? I see no reason for views.properties to hang around (especially considering everyone needs to refactor their code after this rewrite anyway!) - can we axe that in favour of actions.xml? Log4J config is probably hard to get rid of - but I usually have 1 log4j config per server or application which is good enough. What does common.properties do? How does this relate to default.properties? Why can't we roll it all into webwork.xml? ;) -mike |
|
From: Matt B. <ma...@sm...> - 2002-03-01 13:00:29
|
Guys, A couple of thoughts. I think both parties have valid points. So what I want to do is step back and through out a few thoughts and get a dialogue going. Goals? 1. I think we need to remove examples and test from mainline of code. 2. I think we should better delineate/separate the view support. 3. I think we need a distribution that will ensure WW will deploy on all Servlet 2.3 and JSP 1.2 containers and remove the release coupling of views. 4. Release 1.0. Here are my thoughts on above. Since we have not released a 1.0 I think there is some license to refactor packages a little more than if 1.0 was already released. The refactoring that makes sense to me is webwork.core and webwork.example. Under webwork.core, I would propose webwork.core.view to contain taglib, velocity, and xslt related stuff. This will make it easier for deployment and further growth. Yes, don't need this because we could use Ant to handle this but I do think it is needed to make it a cleaner separation. For the distribution, I think we should have a webwork.war (deploy examples and test), webwork-taglib.jar, webwork-xslt.jar, webwork-velocity.jar, webwork-all.jar (all views together), webwork-example.jar. We need the ability to differentiate releases for view support and examples. Here are my opinions what is yours. -Matt ----- Original Message ----- From: "Kjetil Paulsen" <kje...@mo...> To: "Victor Salaman" <vsa...@ho...>; <web...@li...> Sent: Friday, March 01, 2002 4:53 AM Subject: RE: [Webwork-devel] RE: Refactorings... Again > In my mind I just can't picture what the names mean.... > common == common to > all components, but core == needed by all components ... common are common stuff to webwork :) like most of the time you would use one or more of these view technologies togheter with WW, and also some or all of the classes in the other common packages > So therefore at this > point I can't > really tell you where to put it, all I can say is that all > the configuration > functionallity should be together. either all in common or > all in core. my reason for putting it common was that XML confiurator uses 3rd party xml libraries but I think maybe it should be all in core .. Matt, what do you say? > > >And also the property files, we introduced > common.properties, not completly > >sure yet what goes in here from default.props > > > > hehe, it's your doing, you figure it out... haha will do .... > > .... maybe it's time for me to branch the codebase to another > project, and > go back to basics, after all this is open source, and ww has > a liberal > license.... maybe I'm just getting old... heck, who knows. hehe up to you.. don't see why these changes would make you do that - the functionality is the same it's just layed out in another way /kjetilhp _______________________________________________ Webwork-devel mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/webwork-devel |
|
From: Kjetil P. <kje...@mo...> - 2002-03-01 10:54:06
|
> In my mind I just can't picture what the names mean....=20 > common =3D=3D common to=20 > all components, but core =3D=3D needed by all components ...=20 common are common stuff to webwork :) like most of the time you would use one or more of these view = technologies togheter with WW, and also some or all of the classes in = the other common packages > So therefore at this=20 > point I can't=20 > really tell you where to put it, all I can say is that all=20 > the configuration=20 > functionallity should be together. either all in common or=20 > all in core. my reason for putting it common was that XML confiurator uses 3rd party = xml libraries but I think maybe it should be all in core ..=20 Matt, what do you say? >=20 > >And also the property files, we introduced=20 > common.properties, not completly=20 > >sure yet what goes in here from default.props > > >=20 > hehe, it's your doing, you figure it out... haha will do .... >=20 > .... maybe it's time for me to branch the codebase to another=20 > project, and=20 > go back to basics, after all this is open source, and ww has=20 > a liberal=20 > license.... maybe I'm just getting old... heck, who knows. hehe up to you.. don't see why these changes would make you do that - the = functionality is the same it's just layed out in another way /kjetilhp |
|
From: Vedovato P. <pao...@pr...> - 2002-03-01 09:30:10
|
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 |
|
From: Victor S. <vsa...@ho...> - 2002-03-01 09:25:33
|
>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? > In my mind I just can't picture what the names mean.... common == common to all components, but core == needed by all components ... Maybe my logic is flawed, but it doesn't make sense. So therefore at this point I can't really tell you where to put it, all I can say is that all the configuration functionallity should be together. either all in common or all in core. >And also the property files, we introduced common.properties, not completly >sure yet what goes in here from default.props > hehe, it's your doing, you figure it out... haha .... maybe it's time for me to branch the codebase to another project, and go back to basics, after all this is open source, and ww has a liberal license.... maybe I'm just getting old... heck, who knows. hehe /V _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx |
|
From: Kjetil P. <kje...@mo...> - 2002-03-01 09:11:31
|
> 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
|
|
From: Victor S. <vsa...@ho...> - 2002-03-01 08:15:25
|
>Please don't say that we did not communicate this, I sent numerous mail to >the dev list for input and suggestion on how to make WebWork core more >seperated from the view stuff. Can't see that I got any mail from either of >you that are complaining. The goal of this refactoring is, as said, to >separate the core and the view, and to factor out most of the 3rd party >libs so that WW deploys smoothly on most containers. > 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. >The plan is to have build several JAR archives: >- webwork-core.jar, >- webwork-taglib.jar >- webwork-velocity.jar >- webwork-xslt.jar >- webwork-common.jar >and webwork-examples.jar, > Oh, how nice, maybe can rename the project StrustWork. :) LOL 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? 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. And once upon a time, this was true. Today, WebWork is already complicated enough for the common PHP wannabe Java Web technology coder. The transition of scriptlet fun to -> mvc is enough to scare a lot of fragile minds away. 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. >and distribute two WAR archives one with only the common stuff and >documentation, and one with common + examples. > 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... My only concern here is usability to Joe Bloe who is just starting out using this type of technology. >I've finished the code refactoring now, Matt are going to do extensive >debugging and testing of the web-tier before releasing so everything should >be Ok within a few days. > So, are you positive that there no more movements? Can I refactor my code now without fear? >I know that this was kind of unpolite and disturbed a lot of people - so I >appologize. I tried to get input and feedback, not much came. I suggested >this solution that are finished now to Rickard and he agreed so I went >ahead, with Matt's help since he volunteered. > >If there are many of you that step up to the plate and strogly disagree >with this we can always revert to the structure that was before I started. >Speak now or hold your silence to the 1.0 is released :) > Hey, what's done is done, let's see how it works out... By becoming StrutsWork we might actually become as popular as they are. :) > >FYI, I use IntelliJ, I just didn't disconect it from CVS. > Hmm.. bad boy.. naughty boy :) >/kjetilhp > > > -----Original Message----- > > From: Victor Salaman [mailto:vsa...@ho...] > > Sent: Friday, March 01, 2002 8:34 AM > > To: kje...@us...; > > web...@li... > > Subject: Refactorings... Again > > > > > > Dude, > > > > Make up your mind where you're going to put things finally. > > Do we have some > > sort of design document describing the refactoring, or at > > least some kind of > > beforehand planning? It certainly doesn't look like it. And > > since there was > > no discussion or concensus about this, it is plainly unpolite. > > > > It appears that you're winging it, and package names and > > locations are > > coming out of the blue... > > > > I can't be changing my source every 2 minutes when you decide > > that it'll > > look preetier somehow else, as it certainly doesn't add any > > functionallity > > or ease of use to the common user. > > > > I do have source that breaks every time you say "Refactor". > > > > As a suggestion, I'd also tell you to download IDEA and do > > the refactorings > > on your PC, and when you're satisfied with the result, then > > commit. Having > > an unstable CVS tree, and 1 week refactorings are completely > > unacceptable. > > > > In other words, plan before you commit. > > > > I'm speaking for myself, and not anyone else, but I'm sure > > other people > > concurr with my feelings. > > > > Thanks for your time, > > > > /V > > > > >From: "Kjetil H.Paulsen" <kje...@us...> > > >To: app...@us..., > > >ite...@us..., > > >mer...@us..., > > >sor...@us..., > > >sub...@us..., > > >web...@li... > > >Subject: [Webwork-devel] CVS update: > > >webwork/src/main/webwork/common/view/taglib/iterator > > >Date: Thu, 28 Feb 2002 23:15:14 -0800 > > > > > >Update of > > >/cvsroot/webwork/webwork/src/main/webwork/common/view/taglib/iterator > > >In directory usw-pr-cvs1:/tmp/cvs-serv11976/taglib/iterator > > > > > >Modified Files: > > > AppendIteratorTag.java IteratorGeneratorTag.java > > > MergeIteratorTag.java SortIteratorTag.java > > > SubsetIteratorTag.java > > >Log Message: > > >refactoring > > > > > >_______________________________________________ > > >Webwork-devel mailing list > > >Web...@li... > > >https://lists.sourceforge.net/lists/listinfo/webwork-devel > > > > > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > >_______________________________________________ >Webwork-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webwork-devel _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. |
|
From: Kjetil P. <kje...@mo...> - 2002-03-01 07:56:33
|
Please don't say that we did not communicate this, I sent numerous mail = to the dev list for input and suggestion on how to make WebWork core = more seperated from the view stuff. Can't see that I got any mail from = either of you that are complaining. The goal of this refactoring is, as = said, to separate the core and the view, and to factor out most of the = 3rd party libs so that WW deploys smoothly on most containers. The plan is to have build several JAR archives: - webwork-core.jar,=20 - webwork-taglib.jar - webwork-velocity.jar - webwork-xslt.jar - webwork-common.jar=20 and webwork-examples.jar,=20 and distribute two WAR archives one with only the common stuff and = documentation, and one with common + examples. I've finished the code refactoring now, Matt are going to do extensive = debugging and testing of the web-tier before releasing so everything = should be Ok within a few days.=20 I know that this was kind of unpolite and disturbed a lot of people - so = I appologize. I tried to get input and feedback, not much came. I = suggested this solution that are finished now to Rickard and he agreed = so I went ahead, with Matt's help since he volunteered.=20 If there are many of you that step up to the plate and strogly disagree = with this we can always revert to the structure that was before I = started. Speak now or hold your silence to the 1.0 is released :) FYI, I use IntelliJ, I just didn't disconect it from CVS. /kjetilhp > -----Original Message----- > From: Victor Salaman [mailto:vsa...@ho...] > Sent: Friday, March 01, 2002 8:34 AM > To: kje...@us...;=20 > web...@li... > Subject: Refactorings... Again >=20 >=20 > Dude, >=20 > Make up your mind where you're going to put things finally.=20 > Do we have some=20 > sort of design document describing the refactoring, or at=20 > least some kind of=20 > beforehand planning? It certainly doesn't look like it. And=20 > since there was=20 > no discussion or concensus about this, it is plainly unpolite. >=20 > It appears that you're winging it, and package names and=20 > locations are=20 > coming out of the blue... >=20 > I can't be changing my source every 2 minutes when you decide=20 > that it'll=20 > look preetier somehow else, as it certainly doesn't add any=20 > functionallity=20 > or ease of use to the common user. >=20 > I do have source that breaks every time you say "Refactor". >=20 > As a suggestion, I'd also tell you to download IDEA and do=20 > the refactorings=20 > on your PC, and when you're satisfied with the result, then=20 > commit. Having=20 > an unstable CVS tree, and 1 week refactorings are completely=20 > unacceptable. >=20 > In other words, plan before you commit. >=20 > I'm speaking for myself, and not anyone else, but I'm sure=20 > other people=20 > concurr with my feelings. >=20 > Thanks for your time, >=20 > /V >=20 > >From: "Kjetil H.Paulsen" <kje...@us...> > >To: app...@us...,=20 > >ite...@us..., =20 > >mer...@us...,=20 > >sor...@us...,=20 > >sub...@us..., =20 > >web...@li... > >Subject: [Webwork-devel] CVS update:=20 > >webwork/src/main/webwork/common/view/taglib/iterator > >Date: Thu, 28 Feb 2002 23:15:14 -0800 > > > >Update of=20 > >/cvsroot/webwork/webwork/src/main/webwork/common/view/taglib/iterator > >In directory usw-pr-cvs1:/tmp/cvs-serv11976/taglib/iterator > > > >Modified Files: > > AppendIteratorTag.java IteratorGeneratorTag.java > > MergeIteratorTag.java SortIteratorTag.java > > SubsetIteratorTag.java > >Log Message: > >refactoring > > > >_______________________________________________ > >Webwork-devel mailing list > >Web...@li... > >https://lists.sourceforge.net/lists/listinfo/webwork-devel >=20 >=20 >=20 >=20 > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com >=20 |
|
From: Victor S. <vsa...@ho...> - 2002-03-01 07:34:50
|
Dude, Make up your mind where you're going to put things finally. Do we have some sort of design document describing the refactoring, or at least some kind of beforehand planning? It certainly doesn't look like it. And since there was no discussion or concensus about this, it is plainly unpolite. It appears that you're winging it, and package names and locations are coming out of the blue... I can't be changing my source every 2 minutes when you decide that it'll look preetier somehow else, as it certainly doesn't add any functionallity or ease of use to the common user. I do have source that breaks every time you say "Refactor". As a suggestion, I'd also tell you to download IDEA and do the refactorings on your PC, and when you're satisfied with the result, then commit. Having an unstable CVS tree, and 1 week refactorings are completely unacceptable. In other words, plan before you commit. I'm speaking for myself, and not anyone else, but I'm sure other people concurr with my feelings. Thanks for your time, /V >From: "Kjetil H.Paulsen" <kje...@us...> >To: app...@us..., >ite...@us..., >mer...@us..., >sor...@us..., >sub...@us..., >web...@li... >Subject: [Webwork-devel] CVS update: >webwork/src/main/webwork/common/view/taglib/iterator >Date: Thu, 28 Feb 2002 23:15:14 -0800 > >Update of >/cvsroot/webwork/webwork/src/main/webwork/common/view/taglib/iterator >In directory usw-pr-cvs1:/tmp/cvs-serv11976/taglib/iterator > >Modified Files: > AppendIteratorTag.java IteratorGeneratorTag.java > MergeIteratorTag.java SortIteratorTag.java > SubsetIteratorTag.java >Log Message: >refactoring > >_______________________________________________ >Webwork-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webwork-devel _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com |
|
From: Kjetil H.P. <kje...@us...> - 2002-03-01 07:22:44
|
Update of /cvsroot/webwork/webwork/src/main/webwork/core/config In directory usw-pr-cvs1:/tmp/cvs-serv14954 Modified Files: Configuration.java Log Message: |
|
From: Kjetil H.P. <kje...@us...> - 2002-03-01 07:20:57
|
Update of /cvsroot/webwork/webwork/src/main/webwork/examples/jdom In directory usw-pr-cvs1:/tmp/cvs-serv14215/jdom Modified Files: JDOMTest.java JDOMUrl.java RssSources.java Log Message: refactoring |
|
From: Kjetil H.P. <kje...@us...> - 2002-03-01 07:20:57
|
Update of /cvsroot/webwork/webwork/src/main/webwork/examples/bank In directory usw-pr-cvs1:/tmp/cvs-serv14215/bank Modified Files: Transfer.java Log Message: refactoring |
|
From: Kjetil H.P. <kje...@us...> - 2002-03-01 07:20:57
|
Update of /cvsroot/webwork/webwork/src/main/webwork/examples/helloworld/applet In directory usw-pr-cvs1:/tmp/cvs-serv14215/helloworld/applet Modified Files: HelloApplet.java Log Message: refactoring |
|
From: Kjetil H.P. <kje...@us...> - 2002-03-01 07:20:57
|
Update of /cvsroot/webwork/webwork/src/main/webwork/examples/events In directory usw-pr-cvs1:/tmp/cvs-serv14215/events Modified Files: Login.java LoginCounter.java Logout.java Log Message: refactoring |
|
From: Kjetil H.P. <kje...@us...> - 2002-03-01 07:20:57
|
Update of /cvsroot/webwork/webwork/src/main/webwork/examples/i18n In directory usw-pr-cvs1:/tmp/cvs-serv14215/i18n Modified Files: CDList.java LanguageList.java Shop.java Log Message: refactoring |
|
From: Kjetil H.P. <kje...@us...> - 2002-03-01 07:20:57
|
Update of /cvsroot/webwork/webwork/src/main/webwork/examples/helloworld In directory usw-pr-cvs1:/tmp/cvs-serv14215/helloworld Modified Files: HelloWorld.java Login.java LoginStatus.java Log Message: refactoring |
|
From: Kjetil H.P. <kje...@us...> - 2002-03-01 07:20:56
|
Update of /cvsroot/webwork/webwork/src/main/webwork/examples/userreg In directory usw-pr-cvs1:/tmp/cvs-serv14215/userreg Modified Files: UserRegistration.java Log Message: refactoring |
|
From: Kjetil H.P. <kje...@us...> - 2002-03-01 07:20:56
|
Update of /cvsroot/webwork/webwork/src/main/webwork/examples/log4j In directory usw-pr-cvs1:/tmp/cvs-serv14215/log4j Modified Files: AppenderListing.java CategoryListing.java Log Message: refactoring |
34982 messages has been excluded from this view by a project administrator.
