Don Brown wrote:
If we used the 'webwork' name in the package, I think we should abandon
the idea of this being the second major version of Action.
Don,
Java packages are just a technical disposition for avoiding name
collisions. There is no actual necessity to have that there be a
particularly strong correspondence between package (or class) names and
the actual name of the product on the box (or the virtual box in this case.)
Now, there is a convention (that is only loosely followed out there)
that the first parts of the package indicate where it can be found on
the net. (As a practical matter, not a big deal, since google is your
friend...)
But that convention would imply that the thing should start:
org.apache.*
or
org.apache.struts.*
since struts.apache.org is now considered some sort of umbrella, and
besides, the struts.apache.org is the canonical website location, I
guess. The above aspects follow an established convention and make
perfect sense.
But, aside from that, in general, you can rename a java software product
from foo to bar to baz for whatever marketing reasons without renaming
*any* actual java packages.
Well, in short, I think you are reasoning on the basis of a logical
fallacy. Given that java package names do not have the transcendental
implications you attribute to them, maybe you should just let the
webwork people decide on the package naming (after the org.apache.*
part) -- it is that community's work after all.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
In my
opinion, a project needs to have a name, a single name, which one uses
to identify it. If we want to bring WebWork in as a new Struts
subproject, and that is an option, then I'm fine with that. However,
I'm not OK with mixing webwork in with Action in with Struts. We need
to make a decision, then move on.
Don
Niall Pemberton wrote:
+1 to webwork - "org.apache.webwork" if thats allowed, otherwise
"org.apache.struts.webwork".
Niall
On 3/27/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
Hey there,
if webwork is an option as well, I would vote for org.apache.webwork :)
The tag prefix ui: won't be my choice... There are plenty of non-ui tags
within webwork. So this would result in something like: ui:/nonui: and
this would be quite annoying for me...
Same with html: prefix... Yes, some are html tags, but others are not...
So we would have to go the logic:, bean: and html: route...
Too much confusion...
Still my favourites are saf: or a: (and being sometimes lazy, ww: of
course :) )
cheers,
Rainer
PS: Can't we decide on this later if there is no consens now?
Since this is a simple refactoring with subversion it should not hold up
the incubation process for now...
- com.opensymphony.webwork package -> org.apache.struts.action2
- WebWork* classes -> Struts*
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> struts.
- ww: tag prefix -> a:/saf:
+1
I would also be +1 to:
- com.opensymphony.webwork package -> org.apache.struts.webwork or
org.apache.webwork
- ww: tag prefix -> ui:
--
James Mitchell
On Mar 25, 2006, at 5:27 PM, Ted Husted wrote:
STATUS so far
- com.opensymphony.webwork package -> org.apache.struts.ti
- WebWork* classes -> Struts*
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> struts.
- ww: tag prefix -> a:
+1 Don Brown, Martin Cooper (binding)
+1 Frank Zammetti (non-binding)
- com.opensymphony.webwork package -> org.apache.struts.action2
- WebWork* classes -> Struts*
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> struts.
- ww: tag prefix -> a:/saf:
+1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen
(binding)
+0 Toby Jee, Hubert Rabago (binding)
+1 Paul Benedict (non-binding)
If I've left any votes out, or gotten any of the votes wrong, be sure
to chime in!
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
