Menu
▾
▴
webmacro-devel — Discuss development issues related to the core of WebMacro
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(28) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(103) |
Feb
(44) |
Mar
(65) |
Apr
(140) |
May
(72) |
Jun
(233) |
Jul
(466) |
Aug
(51) |
Sep
(2) |
Oct
(17) |
Nov
(1) |
Dec
(7) |
| 2004 |
Jan
(8) |
Feb
(5) |
Mar
(28) |
Apr
(9) |
May
(7) |
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
(24) |
Jun
(7) |
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
(3) |
Dec
(12) |
| 2006 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
(59) |
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(3) |
| 2008 |
Jan
|
Feb
(1) |
Mar
(16) |
Apr
(2) |
May
(2) |
Jun
|
Jul
(11) |
Aug
(3) |
Sep
(9) |
Oct
(9) |
Nov
(44) |
Dec
(34) |
| 2009 |
Jan
(12) |
Feb
(14) |
Mar
(11) |
Apr
(16) |
May
(41) |
Jun
(19) |
Jul
(33) |
Aug
(8) |
Sep
(3) |
Oct
|
Nov
|
Dec
(7) |
| 2010 |
Jan
(8) |
Feb
(50) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Brian G. <br...@qu...> - 2003-06-06 19:05:35
|
> I'm cool with whatever. I personally like the dangling brackets to reduce > the vertical whitespace, but brackets on a new line *are* clearer. So, > whatever, let's just try not to revisit this again next year. Anyone want to wager on the liklihood of not revisiting it next year? |
|
From: Marc P. <ma...@an...> - 2003-06-06 18:47:51
|
On Fri, 6 Jun 2003 14:40:14 -0400, Eric B. Ridge <eb...@tc...> wrote: > Brian is absolutely correct. All of this mess is pure religion. > > Since I get to rule the world, The Church of Eric hereby decrees that all > WebMacro source code must be formatted according the style guidelines set > forth by the Apache Jakarta group. See > http://jakarta.apache.org/turbine/common/code-standards.html for the > guidelines. Amen! Praise be! > For what it's worth, this is NOT my personal style, so I feel your pain. > > I'll try to get all the code updated in CVS before we start moving > packages around... hopefully Sunday. > > eric > > ps, I chose Apache Jakarta thinking that it might encourage Marc to fix > that damn logging bug! *grin* Er, I fixed it and it's committed. Didn't you see the cvs-commit message and stuff about my fouled line terminators? Thanks anyway. :) :) You can all blame me instead of Eric then. If it's any consolation my own style differs from the Sun conventions too - I am going to have to learn to make some changes in a few places, but this is a GOOD THING. Cheers -- Marc Palmer Contract Java Consultant/Developer Currently available for hire! http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: <Kea...@di...> - 2003-06-06 18:30:22
|
I'm cool with whatever. I personally like the dangling brackets to reduce the vertical whitespace, but brackets on a new line *are* clearer. So, whatever, let's just try not to revisit this again next year. Keats > Another approach is just to say f*ck it. if you don't like the way the > file is formatted, reformat it yourself. IDEA does make it easy. > Although it does mess with cvs diffs. My take on things like lexical elements of coding style, like brace placement and how many spaces: Coding style is a religious issue. It will never be decided on the basis of merit, because these things are fundamentally personal preferences that have to do with subjective measures like your visual acuity and propensity to eyestrain, the quality of your short-term memory, the size of your monitor, your program editor of choice, and other things that are not comparable across individuals. People will never agree, because we all have different eyes, monitors, working styles, and preferences. Someone in the group should be elected (I vote Eric) to pick a style, check in an IDEA style sheet, reformat the code ONCE, and be done with this issue. After that, if you don't like the coding style the project chooses, just shut up and deal with it. > > This is why I proposed that we adopt and -existing- code style > > somebody else has already argued about. An excellent proposal. Eric, pick one. |
|
From: Brian G. <br...@qu...> - 2003-06-06 18:07:56
|
> Another approach is just to say f*ck it. if you don't like the way the > file is formatted, reformat it yourself. IDEA does make it easy. > Although it does mess with cvs diffs. My take on things like lexical elements of coding style, like brace placement and how many spaces: Coding style is a religious issue. It will never be decided on the basis of merit, because these things are fundamentally personal preferences that have to do with subjective measures like your visual acuity and propensity to eyestrain, the quality of your short-term memory, the size of your monitor, your program editor of choice, and other things that are not comparable across individuals. People will never agree, because we all have different eyes, monitors, working styles, and preferences. Someone in the group should be elected (I vote Eric) to pick a style, check in an IDEA style sheet, reformat the code ONCE, and be done with this issue. After that, if you don't like the coding style the project chooses, just shut up and deal with it. > > This is why I proposed that we adopt and -existing- code style > > somebody else has already argued about. An excellent proposal. Eric, pick one. |
|
From: Marc P. <ma...@an...> - 2003-06-06 18:01:57
|
On Fri, 6 Jun 2003 13:51:48 -0400, Eric B. Ridge <eb...@tc...> wrote:
> Ya know, Endre might have a point about just using Sun's style
> guidelines. I never thought of it cuz it just makes too much sense.
>
> Another approach is just to say f*ck it. if you don't like the way the
> file is formatted, reformat it yourself. IDEA does make it easy.
> Although it does mess with cvs diffs.
Er, yes just a little bit. I'd -love-- to reformat all of WM with my
favourite code style settings, but I bet 50% of the developers here would
scream at me when they checked it out of CVS!
I think you are right - SUN style, or "Jakarta" style.
My vote is for Jakarta because of the opening "{" on newline. It sounds so
petty but it really improves readability no end, and that is -exactly- why
they did it.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
Currently available for hire!
http://www.anyware.co.uk/marc/
http://www.wangjammers.org
|
|
From: Eric B. R. <eb...@tc...> - 2003-06-06 17:51:56
|
Ya know, Endre might have a point about just using Sun's style=20 guidelines. I never thought of it cuz it just makes too much sense. Another approach is just to say f*ck it. if you don't like the way the=20= file is formatted, reformat it yourself. IDEA does make it easy. =20 Although it does mess with cvs diffs. eric On Friday, June 6, 2003, at 08:26 AM, Marc Palmer wrote: > On Fri, 6 Jun 2003 14:17:33 +0200 (CEST), Endre St=F8lsvik=20 > <web...@st...> wrote: > >> On Wed, 4 Jun 2003 Kea...@di... wrote: >> >> | Actually we went through this exercise a year or so back. =20 >> Unfortunately I >> | don't think we've documented our style guidelines on the Wiki. I=20= >> can try >> | to find the old emails and write up something. >> | >> | Basically we decided on an indent of 3 spaces and no newline before >> >> -3-spaces? You just gotta be kidding, PLEASE??? >> >> I mean, SUN has made a Java coding style, -even-, that says 4. 3 is=20= >> just >> .. really really weird. >> >> But I do agree. I can't code in there, the code -must-be very = readable >> for the brain-based parser I use when reading code to work at all. At=20= >> it >> just output parser-errors when looking at the WM code.. > > Yes. I think 3 is very small too - but I don't want us to spend weeks=20= > arguing over style (again?). > > I personally use 5, but the Sun standard as you say uses 4 and so does=20= > Apache/Jakarta stuff: > > http://jakarta.apache.org/turbine/common/code-standards.html > > I personally also think code is 100% more readable with opening "{" on=20= > a newline, as per the Jakarta standard... but I care more about NOT=20 > spending weeks arguing about this. This is very important when people=20= > are looking at code "afresh". > > This is why I proposed that we adopt and -existing- code style=20 > somebody else has already argued about. > > I reformatted a bunch of my Ignition app code using the 3 spaces and=20= > same- line opening { rule, and it looks awful. Really unreadable, but=20= > that's just what I'm used to I suppose - but it is horrible to see=20 > your own project suddenly become very unreadable :( > > > Marc > --=20 > Marc Palmer > Contract Java Consultant/Developer > Currently available for hire! > http://www.anyware.co.uk/marc/ > http://www.wangjammers.org > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The=20 > best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Marc P. <ma...@an...> - 2003-06-06 12:55:16
|
On Fri, 6 Jun 2003 14:12:33 +0200 (CEST), Endre Stølsvik <web...@st...> wrote: > What about that Wiki page with "wishlists" for 2.0? USE THIS! I have in the past. I've just updated it too. http://www.webmacro.org/NextRelease I've also added http://www.webmacro.org/CodeStyle for when we work this out. -- Marc Palmer Contract Java Consultant/Developer Currently available for hire! http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: <web...@st...> - 2003-06-06 12:37:39
|
On Wed, 4 Jun 2003, Eric B.Ridge wrote: | On Wednesday, June 4, 2003, at 11:55 AM, Lane Sharman wrote: | | > I think Brian did the last re-beautification of wm source. But, before | > we rebeatify it, we need to refactor it, don't we into a coherent set | > of packages and classes and create a new tree? | | I really really really don't like the idea of creating a whole new | tree. It's just one more thing to maintain. | | I think we should | | 1) branch off the HEAD into a branch named something like "WM_1_1_DEAD" | | 2) in the HEAD remove and re-add (losing history on new version) the | limited number of files we're going to move around. | | This way, we can still build old versions by checking out specific | tags, and we can still browse old histories (before the remove/add) by | looking in the Attic. | | And, if somebody ever decides to submit a useful patch (yeah, right!) | against an older version of WM, we'll have the ability to merge those | changes into the HEAD... which will be version 2.0. This -is- the -only- way to do it, so why fuzz?! ;) But really, it is. Endre. |
|
From: Marc P. <ma...@an...> - 2003-06-06 12:28:09
|
On Fri, 6 Jun 2003 14:17:33 +0200 (CEST), Endre Stølsvik <web...@st...> wrote: > On Wed, 4 Jun 2003 Kea...@di... wrote: > > | Actually we went through this exercise a year or so back. > Unfortunately I > | don't think we've documented our style guidelines on the Wiki. I can > try > | to find the old emails and write up something. > | > | Basically we decided on an indent of 3 spaces and no newline before > > -3-spaces? You just gotta be kidding, PLEASE??? > > I mean, SUN has made a Java coding style, -even-, that says 4. 3 is just > .. really really weird. > > But I do agree. I can't code in there, the code -must-be very readable > for the brain-based parser I use when reading code to work at all. At it > just output parser-errors when looking at the WM code.. Yes. I think 3 is very small too - but I don't want us to spend weeks arguing over style (again?). I personally use 5, but the Sun standard as you say uses 4 and so does Apache/Jakarta stuff: http://jakarta.apache.org/turbine/common/code-standards.html I personally also think code is 100% more readable with opening "{" on a newline, as per the Jakarta standard... but I care more about NOT spending weeks arguing about this. This is very important when people are looking at code "afresh". This is why I proposed that we adopt and -existing- code style somebody else has already argued about. I reformatted a bunch of my Ignition app code using the 3 spaces and same- line opening { rule, and it looks awful. Really unreadable, but that's just what I'm used to I suppose - but it is horrible to see your own project suddenly become very unreadable :( Marc -- Marc Palmer Contract Java Consultant/Developer Currently available for hire! http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: <web...@st...> - 2003-06-06 12:17:39
|
On Wed, 4 Jun 2003 Kea...@di... wrote: | Actually we went through this exercise a year or so back. Unfortunately I | don't think we've documented our style guidelines on the Wiki. I can try | to find the old emails and write up something. | | Basically we decided on an indent of 3 spaces and no newline before -3- spaces? You just gotta be kidding, PLEASE??? I mean, SUN has made a Java coding style, -even-, that says 4. 3 is just .. really really weird. But I do agree. I can't code in there, the code -must- be very readable for the brain-based parser I use when reading code to work at all. At it just output parser-errors when looking at the WM code.. Endre |
|
From: <web...@st...> - 2003-06-06 12:12:40
|
On Wed, 4 Jun 2003, Marc Palmer wrote: | However, for me one of the biggest things I would like to see in 2.0 is the | rationalisation of the entire WM package structure, plus a .jar of WM-dev | approved optional helper classes and context tools. | What about that Wiki page with "wishlists" for 2.0? USE THIS! -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ |
|
From: Eric B. R. <eb...@tc...> - 2003-06-04 18:53:44
|
On Wednesday, June 4, 2003, at 01:06 PM, Marc Palmer wrote: > I am also picturing the following changes - some are refactorings, > others are refactor/rename related: > > org.webmacro.optional.helpers.xxxxx > org.webmacro.optional.contexttools.xxxxx > > - for both context tools and for non-context tool / general purpose > classes to put into context, i.e. XML helpers etc. which may all have > context tool wrappers too, but not necessarily. There is stuff from > Ignition that is not Ignition specific and will be useful to WM users. > This should be available in a webmacro-optional.jar along with any > optional context tools that are not part of WM core but are > webmacro-dev "approved". (i.e. this is not /contrib) agreed. > org.webmacro.io > - for FastWriter and any related stuff like IO exceptions. Also think > we should remove reliance on FastWriter if possible - and make code do > "if (writer instanceof FastWriter)..." style stuff. I haven't looked > into it fully but most of the FastWriter features do not seem to be > used by WM code itself so a normal Writer should do for the > interfaces. ehh. FastWriter handles pools of itself along with encoding caches. Plus it can write both byte[] and char[]. Although it extends java.io.Writer, it ain't a Writer no-more. And all of WM internals know and expect FastWriter. Along with your code, my code, and everyone else's code too. Doing what you suggest is a BIG change. However, I'm not saying we shouldn't do it... > org.webmacro.util > - Kill off the unused stuff like IntMap, IntStack etc. agreed! > org.webmacro.cache > - Put all the CacheManager related classes from org.webmacro.resource > in there (I reckon anyway) - leaving only CachingProvider in the > resource package. I have no opinion on this one way or the other. > org.webmacro.engine > - can probably do with some tidying up. The various "Builder" classes > could go into o.w.engine.builders, and we need to "filter out" the > filter stuff that's there. Is it dead/alive or somewhere in between? > Does it belong in contrib/optional now even when fixed. For 2.0 I suppose we can nuke the Filter stuff completely. It is not being used. > org.webmacro.introspection > - Should take all introspection related stuff like MethodWrapper, > OperatorCache etc. out of o.w.engine and any other locations. Later we > can enhance the re-usability of the of the introspection "engine" so > that the cache and other code can be reused. (for example there are > places where Ignition could do with some code sharing here, subject to > a bit of re- engineering of the existing WM operator code. i.e. it > would be nice to be able to ask the operator cache things like > isDynamicPropertyGetter(method) where method is a method possibly > called "get"). Good idea. > org.webmacro.directive > - Kill the old unused/obsolete stuff, and move some out to > o.w.optional.directive if applicable. agreed. What directives should be optional? > > org.webmacro.api > - For WebMacro, Template, Context, Provider, Macro, Log, ContextTool > etc. - separate from the impls and out of the org.webmacro package ehh, I'd say leave these in org.webmacro. They're so core to WM that they should be sitting on top of everything, imho. > > org.webmacro.impl > - For implementations of WebMacro, Template, Context, Provider, Macro, > Log, ContextTool etc. that do no have anywhere else to go (as comments > listed above). well, I dunno about this either. From a user perspective, there's something very handy about writing 1 import statement to get access to everything you need. eric |
|
From: Marc P. <ma...@an...> - 2003-06-04 17:14:03
|
On Wed, 04 Jun 2003 18:06:08 +0100, Marc Palmer <ma...@an...> wrote: > That just from a 5 minute glance at the tree - apologies if any stupids > in there. Just to add, do you see why I am suggesting a new source tree? I reckon that's around 50% of the tree being moved anyway. Why can't we just have a "webmacro2" dir under /cvsroot/webmacro in addition to the current "webmacro"? I don't see why this is such a problem - copying the entire existing tree over to webmacro2 and then doing the refactor. This leaves the 1.1 codebase in a completely stable and usable state while we make changes, and like you said patches for 1.1 are going to be unlikely, and if so few in number so easily rolled in to 2. It might just make it a whole lot easier for us. Of course, no doubt some people will disagree with some or all my package ideas. Marc -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ |
|
From: Marc P. <ma...@an...> - 2003-06-04 17:08:15
|
On Wed, 4 Jun 2003 12:28:52 -0400, Eric B. Ridge <eb...@tc...> wrote: > Yeah, but in different commits. Picking nits now I suppose, but it's not > a good idea to make a whole bunch of disparate changes and commit 'em in > one big batch. Yeah, no problem. > What are your ideas for the new package structure? > > The first thing that comes to my mind is moving the ContextTools into > their own package. org.webmacro.contexttools. > > Perhaps we also want to move all servlet-specific stuff into a base > package that somewhat mirrors the main org.webmacro structure: > org.webmacro.servlet.WebContext > org.webmacro.servlet.WebMacroServlet > org.webmacro.servlet.ServletBroker > org.webmacro.servlet.contexttools.FormTool > org.webmacro.servlet.contexttools.CGITool > org.webmacro.servlet.util.ServletLogTarget > > My thinking here is that we might want to offer a non-servlet download, > and having all the servlet stuff under one base package will make it easy > for ANT to exclude them. Yes all that sounds really good. I am also picturing the following changes - some are refactorings, others are refactor/rename related: org.webmacro.optional.helpers.xxxxx org.webmacro.optional.contexttools.xxxxx - for both context tools and for non-context tool / general purpose classes to put into context, i.e. XML helpers etc. which may all have context tool wrappers too, but not necessarily. There is stuff from Ignition that is not Ignition specific and will be useful to WM users. This should be available in a webmacro-optional.jar along with any optional context tools that are not part of WM core but are webmacro-dev "approved". (i.e. this is not /contrib) org.webmacro.io - for FastWriter and any related stuff like IO exceptions. Also think we should remove reliance on FastWriter if possible - and make code do "if (writer instanceof FastWriter)..." style stuff. I haven't looked into it fully but most of the FastWriter features do not seem to be used by WM code itself so a normal Writer should do for the interfaces. org.webmacro.util - Kill off the unused stuff like IntMap, IntStack etc. org.webmacro.cache - Put all the CacheManager related classes from org.webmacro.resource in there (I reckon anyway) - leaving only CachingProvider in the resource package. org.webmacro.engine - can probably do with some tidying up. The various "Builder" classes could go into o.w.engine.builders, and we need to "filter out" the filter stuff that's there. Is it dead/alive or somewhere in between? Does it belong in contrib/optional now even when fixed. org.webmacro.introspection - Should take all introspection related stuff like MethodWrapper, OperatorCache etc. out of o.w.engine and any other locations. Later we can enhance the re-usability of the of the introspection "engine" so that the cache and other code can be reused. (for example there are places where Ignition could do with some code sharing here, subject to a bit of re- engineering of the existing WM operator code. i.e. it would be nice to be able to ask the operator cache things like isDynamicPropertyGetter(method) where method is a method possibly called "get"). org.webmacro.directive - Kill the old unused/obsolete stuff, and move some out to o.w.optional.directive if applicable. org.webmacro.api - For WebMacro, Template, Context, Provider, Macro, Log, ContextTool etc. - separate from the impls and out of the org.webmacro package org.webmacro.impl - For implementations of WebMacro, Template, Context, Provider, Macro, Log, ContextTool etc. that do no have anywhere else to go (as comments listed above). That just from a 5 minute glance at the tree - apologies if any stupids in there. Marc -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ |
|
From: Eric B. R. <eb...@tc...> - 2003-06-04 16:29:00
|
On Wednesday, June 4, 2003, at 12:13 PM, Marc Palmer wrote: >> But the code style isn't nearly as important, in my mind, as fixing >> the package structure. > > Spot on - but we can do it all at the same time. Beautification is > trivial once you have your style guide. Yeah, but in different commits. Picking nits now I suppose, but it's not a good idea to make a whole bunch of disparate changes and commit 'em in one big batch. What are your ideas for the new package structure? The first thing that comes to my mind is moving the ContextTools into their own package. org.webmacro.contexttools. Perhaps we also want to move all servlet-specific stuff into a base package that somewhat mirrors the main org.webmacro structure: org.webmacro.servlet.WebContext org.webmacro.servlet.WebMacroServlet org.webmacro.servlet.ServletBroker org.webmacro.servlet.contexttools.FormTool org.webmacro.servlet.contexttools.CGITool org.webmacro.servlet.util.ServletLogTarget My thinking here is that we might want to offer a non-servlet download, and having all the servlet stuff under one base package will make it easy for ANT to exclude them. eric |
|
From: Eric B. R. <eb...@tc...> - 2003-06-04 16:21:19
|
On Wednesday, June 4, 2003, at 11:55 AM, Lane Sharman wrote: > I think Brian did the last re-beautification of wm source. But, before > we rebeatify it, we need to refactor it, don't we into a coherent set > of packages and classes and create a new tree? I really really really don't like the idea of creating a whole new tree. It's just one more thing to maintain. I think we should 1) branch off the HEAD into a branch named something like "WM_1_1_DEAD" 2) in the HEAD remove and re-add (losing history on new version) the limited number of files we're going to move around. This way, we can still build old versions by checking out specific tags, and we can still browse old histories (before the remove/add) by looking in the Attic. And, if somebody ever decides to submit a useful patch (yeah, right!) against an older version of WM, we'll have the ability to merge those changes into the HEAD... which will be version 2.0. eric > > -Lane > > Marc Palmer wrote: > >> On Wed, 4 Jun 2003 09:49:49 -0400, <Kea...@di...> wrote: >> >>> Actually we went through this exercise a year or so back. >>> Unfortunately I don't think we've documented our style guidelines on >>> the Wiki. I can try to find the old emails and write up something. >> >> >> OK. How about we also provide the settings for this for IDEs. I can >> provide the IDEA .xml config file for this, for download from the WM >> site. I've just set it up. >> >>> Basically we decided on an indent of 3 spaces and no newline before >>> opening curly-brackets. We also use an underscore prefix for >>> non-public member variables (although this is more of a suggestion >>> than a rule I think). >> >> >> OK done that with IDEA, but there are so many other factors... chosen >> what looks like happens most in WM code to date. >> >>> I'm pretty sure all the code got beautified, but I you see any ugly >>> code, let us know. >> >> >> Just a brief glance... ServletBroker is a little messy 'cos of my new >> changes (knew no style at time so used mine) plus minor style snafus >> in Brian's getBroker method he added in previous rev. >> >> Plus Broker has some pretty horrendous tabbing going on with >> anonymous classes and things. Those are just the two files I looked >> at. There are little bits of strange spacing all over the place. Not >> the end of the world sure, but with a good tool to do all files at >> once... >> >> Why don't we get someone who uses IDEA to reformat the whole tree for >> 2.0 - call it late spring cleaning. IDEA is good at laying out >> anonymous classes and nasty continued lines and things like that. >> IDEA 3.0.4 seems to be even better at this than previous versions. >> >> Just a thought. >> >> > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The > best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Marc P. <ma...@an...> - 2003-06-04 16:16:11
|
On Wed, 4 Jun 2003 11:49:51 -0400, Eric B. Ridge <eb...@tc...> wrote: > Other things we probably need to decide on are things like: > 1) should method argument lists (in the method definition) wrap? IMO, yes, and should be tabbed in 3 chars to coincide with the style. i.e: private void evaluateTemplate(Module module, WebContext webContext, String templateName) throws ResourceException > 2) should the throws clause wrap? Not fussed. > 3) what's the right margin column number where we should force wrapping. IMO 80, but it's not such a big deal these days. People usually have much bigger/higher resolution screens than the old green on black TTY days. > IDEA, at least as far as I can tell, doesn't handle 1 and 2 all that > well. Maybe I just don't know to use it. Actually it handles 1 perfectly well (in 3.x releases certainly), but 2 and 3 do not happen at all. > But the code style isn't nearly as important, in my mind, as fixing the > package structure. Spot on - but we can do it all at the same time. Beautification is trivial once you have your style guide. Marc -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ |
|
From: Lane S. <la...@op...> - 2003-06-04 16:02:16
|
I think Brian did the last re-beautification of wm source. But, before we rebeatify it, we need to refactor it, don't we into a coherent set of packages and classes and create a new tree? -Lane Marc Palmer wrote: > On Wed, 4 Jun 2003 09:49:49 -0400, <Kea...@di...> wrote: > >> Actually we went through this exercise a year or so back. >> Unfortunately I don't think we've documented our style guidelines on >> the Wiki. I can try to find the old emails and write up something. > > > OK. How about we also provide the settings for this for IDEs. I can > provide the IDEA .xml config file for this, for download from the WM > site. I've just set it up. > >> Basically we decided on an indent of 3 spaces and no newline before >> opening curly-brackets. We also use an underscore prefix for >> non-public member variables (although this is more of a suggestion >> than a rule I think). > > > OK done that with IDEA, but there are so many other factors... chosen > what looks like happens most in WM code to date. > >> I'm pretty sure all the code got beautified, but I you see any ugly >> code, let us know. > > > Just a brief glance... ServletBroker is a little messy 'cos of my new > changes (knew no style at time so used mine) plus minor style snafus > in Brian's getBroker method he added in previous rev. > > Plus Broker has some pretty horrendous tabbing going on with anonymous > classes and things. Those are just the two files I looked at. There > are little bits of strange spacing all over the place. Not the end of > the world sure, but with a good tool to do all files at once... > > Why don't we get someone who uses IDEA to reformat the whole tree for > 2.0 - call it late spring cleaning. IDEA is good at laying out > anonymous classes and nasty continued lines and things like that. IDEA > 3.0.4 seems to be even better at this than previous versions. > > Just a thought. > > |
|
From: Eric B. R. <eb...@tc...> - 2003-06-04 15:49:59
|
Other things we probably need to decide on are things like: 1) should method argument lists (in the method definition) wrap? 2) should the throws clause wrap? 3) what's the right margin column number where we should force wrapping. IDEA, at least as far as I can tell, doesn't handle 1 and 2 all that well. Maybe I just don't know to use it. But the code style isn't nearly as important, in my mind, as fixing the package structure. eric On Wednesday, June 4, 2003, at 11:11 AM, Marc Palmer wrote: > On Wed, 4 Jun 2003 09:49:49 -0400, <Kea...@di...> wrote: > >> Actually we went through this exercise a year or so back. >> Unfortunately I don't think we've documented our style guidelines on >> the Wiki. I can try to find the old emails and write up something. > > OK. How about we also provide the settings for this for IDEs. I can > provide the IDEA .xml config file for this, for download from the WM > site. I've just set it up. > >> Basically we decided on an indent of 3 spaces and no newline before >> opening curly-brackets. We also use an underscore prefix for >> non-public member variables (although this is more of a suggestion >> than a rule I think). > > OK done that with IDEA, but there are so many other factors... chosen > what looks like happens most in WM code to date. > >> I'm pretty sure all the code got beautified, but I you see any ugly >> code, let us know. > > Just a brief glance... ServletBroker is a little messy 'cos of my new > changes (knew no style at time so used mine) plus minor style snafus > in Brian's getBroker method he added in previous rev. > > Plus Broker has some pretty horrendous tabbing going on with anonymous > classes and things. Those are just the two files I looked at. There > are little bits of strange spacing all over the place. Not the end of > the world sure, but with a good tool to do all files at once... > > Why don't we get someone who uses IDEA to reformat the whole tree for > 2.0 - call it late spring cleaning. IDEA is good at laying out > anonymous classes and nasty continued lines and things like that. IDEA > 3.0.4 seems to be even better at this than previous versions. > > Just a thought. > > > -- > Marc Palmer > Contract Java Consultant/Developer > > http://www.anyware.co.uk/marc/ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The > best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Marc P. <ma...@an...> - 2003-06-04 15:13:05
|
On Wed, 4 Jun 2003 09:49:49 -0400, <Kea...@di...> wrote: > Actually we went through this exercise a year or so back. Unfortunately > I don't think we've documented our style guidelines on the Wiki. I can > try to find the old emails and write up something. OK. How about we also provide the settings for this for IDEs. I can provide the IDEA .xml config file for this, for download from the WM site. I've just set it up. > Basically we decided on an indent of 3 spaces and no newline before > opening curly-brackets. We also use an underscore prefix for non-public > member variables (although this is more of a suggestion than a rule I > think). OK done that with IDEA, but there are so many other factors... chosen what looks like happens most in WM code to date. > I'm pretty sure all the code got beautified, but I you see any ugly code, > let us know. Just a brief glance... ServletBroker is a little messy 'cos of my new changes (knew no style at time so used mine) plus minor style snafus in Brian's getBroker method he added in previous rev. Plus Broker has some pretty horrendous tabbing going on with anonymous classes and things. Those are just the two files I looked at. There are little bits of strange spacing all over the place. Not the end of the world sure, but with a good tool to do all files at once... Why don't we get someone who uses IDEA to reformat the whole tree for 2.0 - call it late spring cleaning. IDEA is good at laying out anonymous classes and nasty continued lines and things like that. IDEA 3.0.4 seems to be even better at this than previous versions. Just a thought. -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ |
|
From: <Kea...@di...> - 2003-06-04 13:50:03
|
Actually we went through this exercise a year or so back. Unfortunately I
don't think we've documented our style guidelines on the Wiki. I can try
to find the old emails and write up something.
Basically we decided on an indent of 3 spaces and no newline before
opening curly-brackets. We also use an underscore prefix for non-public
member variables (although this is more of a suggestion than a rule I
think).
I'm pretty sure all the code got beautified, but I you see any ugly code,
let us know.
Keats
Marc Palmer <ma...@an...>
Sent by: web...@li...
06/04/2003 06:01 AM
Please respond to marc
To: web...@li...
cc:
Subject: [Webmacro-devel] Another small 2.0 thing
...can we adopt an existing code style, say the Apache code style? A lot
the code looks like hell.
Once we establish the code guidlines - I stronly suggest just by adopting
someone else's scheme instead of arguing about it - it is trivial to have
IDEA (or similar tool) reformat all the source for 2.0 so that everything
is more readable.
Best wishes,
Marc
--
Marc Palmer
Contract Java Consultant/Developer
http://www.anyware.co.uk/marc/
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
|
|
From: Eric B. R. <eb...@tc...> - 2003-06-04 13:38:04
|
On Wednesday, June 4, 2003, at 04:02 AM, Marc Palmer wrote: > On Tue, 03 Jun 2003 22:10:00 -0700, Lane Sharman <la...@op...> > wrote: <snip> > Bear in mind that I hate CVS, it is the spawn of the devil (in terms > of usability with Java in particular), and I may completely screw up > the source tree if IDEA isn't doing the changes for me automatically. > :-) I'll take care of the CVS changes.. Like you said, we just need to figure out what to change... eric > > Best wishes, > Marc > -- > Marc Palmer > Contract Java Consultant/Developer > > http://www.anyware.co.uk/marc/ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The > best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Marc P. <ma...@an...> - 2003-06-04 13:35:51
|
On Wed, 4 Jun 2003 09:24:07 -0400, Eric B. Ridge <eb...@tc...> wrote: > On Wednesday, June 4, 2003, at 04:02 AM, Marc Palmer wrote: > >> On Tue, 03 Jun 2003 22:10:00 -0700, Lane Sharman <la...@op...> >> wrote: > > <snip> > >> Bear in mind that I hate CVS, it is the spawn of the devil (in terms of >> usability with Java in particular), and I may completely screw up the >> source tree if IDEA isn't doing the changes for me automatically. :-) > > I'll take care of the CVS changes.. Like you said, we just need to > figure out what to change... OK... including all the changes to all dependent source files too? Your packin' a nice tool for it I hope! -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ |
|
From: Marc P. <ma...@an...> - 2003-06-04 12:17:31
|
The fix seems to work and is committed - using WeakHashMap in the end for convenience. Unfortunately I checked it in with windows linebreaks - forgive me. I will try checking it out again, forcing to LF only, and put it back. -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ |
|
From: Marc P. <ma...@an...> - 2003-06-04 10:01:48
|
...can we adopt an existing code style, say the Apache code style? A lot the code looks like hell. Once we establish the code guidlines - I stronly suggest just by adopting someone else's scheme instead of arguing about it - it is trivial to have IDEA (or similar tool) reformat all the source for 2.0 so that everything is more readable. Best wishes, Marc -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ |
237 messages has been excluded from this view by a project administrator.
