package structure
Jason Essington
structure a bit baffling.
By looking at the package there is no way to immediately tell what is
intended to be used on the server and what is client side.
I would like to see us adopt a package structure similar to what GWT
already uses
org.gwtcommons.user.client/server/test/public for all of the core
functionality of gwt-commons. just like GWT uses
A user would then simply add <inherits
name="org.gwtcommons.user.User" /> to their gwt.xml file to get all
of the base gwt-commons functionality
This module could certainly inherit other modules in much the same
way that GWT does, but only one inherits line would be required of
the user to get the base functionality
Then other modules that we deem valuable but out of scope of base gwt-
commons could be in packages external to org.gwtcommons.user ...
(maybe remoting, wrap, svg, etc) ...
the thing that I do think is important though is that we maintain the
convention set forth by Google. client code goes in the *.client.*
package, server code goes in the *.server.* package and static code
(html, css, images, etc) goes in a *.public.* folder.
I think that we want the integration of gwt-commons into a gwt
application to be as seemless as possible, which means that we should
make every effort to conform to conventions set forth by GWT itself.
It is their ball so to speak, so lets play by their rules.
This would make the existing gwtcommons package structure look
something like:
org
org.gwtcommons
org.gwtcommons.core
org.gwtcommons.core.client
org.gwtcommons.core.client.io
org.gwtcommons.core.client.lang
org.gwtcommons.core.client.util
org.gwtcommons.remoting
org.gwtcommons.remoting.server
org.gwtcommons.remoting.server.jrpc
org.gwtcommons.remoting.server.spring
org.gwtcommons.user
org.gwtcommons.user.client
org.gwtcommons.user.client.dom
org.gwtcommons.user.client.effects
org.gwtcommons.user.client.mvc
org.gwtcommons.user.client.widget
org.gwtcommons.user.client.widget.base
org.gwtcommons.user.client.widget.gwk
org.gwtcommons.user.client.widget.winforms
Any comments?
-jason
ash
yes, i made evey effort to avoid that. imho 'client' is noise in the
namespace.
if i managed to work out how to bind apache commons lang without change
such that it could be leveraged in gwt clients, would u insist on
creating a sub-distribution, refactoring code and inserting client into
the namespace:
eg. org.apache.commons.client.lang ?
imho 'client' is a convention recommended by the gwt designers to help
the uninitiated bind to artifacts and reduce gwt-compilation issues.
the sooner the gwt team fix up their limited JRE, the sooner this
becomes a non-issue.
rgds ash
http://www.gworks.com.au
Robert Hanson
> yes, i made evey effort to avoid that. imho 'client'
> is noise in the namespace.
I am for using "client". I can see how it would make it a lot easier
for someone new to using the library to navigate the package tree. It
makes it easy to mentally separate what it used on the client and what
is used on the server.
> would u insist on creating a sub-distribution, refactoring
> code and inserting client into the namespace:
> eg. org.apache.commons.client.lang ?
I would definitely recommend not using the package
"org.apache.commons.lang" (or even org.apache) at all since it is
already used by the real commons-lang.
Rob
Jason Essington
On Nov 28, 2006, at 11:44 PM, ash wrote:
>
>> Any comments?
> yes, i made evey effort to avoid that. imho 'client' is noise in the
> namespace.
It may be noise, but it is very important noise. without it, even
veteran GWT developers are left to muddle around trying to figure out
what should and shouldn't be clinet side code.
> if i managed to work out how to bind apache commons lang without
> change
> such that it could be leveraged in gwt clients, would u insist on
> creating a sub-distribution, refactoring code and inserting client
> into
> the namespace:
> eg. org.apache.commons.client.lang ?
This is a different issue entirely, and in fact since gwt-commons is
not apache commons, we shouldn't even be using their namespace. I
have seen instances in the past where developers have forked another
project to implement some sort of compatibility, they prepend the
original namespace with their own, In fact GWT does this with its
java emulation library.
> imho 'client' is a convention recommended by the gwt designers to help
> the uninitiated bind to artifacts and reduce gwt-compilation issues.
That is my point entirely. It creates a markable separation between
client and server code, and is necessary to maintain consistency with
GWT itself.
> the sooner the gwt team fix up their limited JRE, the sooner this
> becomes a non-issue.
The GWT Team will never be able to completely implement the entire
JRE so there will always be limitations on what can be used on the
client and what cannot, and in fact, I see no time in the near future
when it will be reasonable to mix client and server code.
The goal here is to have a package that is as much like GWT as
possible. We shouldn't depart from their conventions just because we
"don't like them". By doing so we just heap an unneeded burden onto
the users.
-jason
Jason Essington
On Nov 29, 2006, at 6:10 AM, Robert Hanson wrote:
>
>>> Any comments?
>> yes, i made evey effort to avoid that. imho 'client'
>> is noise in the namespace.
>
> I am for using "client". I can see how it would make it a lot easier
> for someone new to using the library to navigate the package tree.
It would even help someone like me, a veteran GWT developer. When I
was first examining the tree, I had to wade through the source code
to have a look at the imports to discern what packages were and were
not server packages. This is not something we should expect users to
do, they will want to import the library, and go to work, not spend
days becoming intimately familiar with the source.
-jason
ash
> > would u insist on creating a sub-distribution, refactoring
> > code and inserting client into the namespace:
> > eg. org.apache.commons.client.lang ?
>
> I would definitely recommend not using the package
> "org.apache.commons.lang" (or even org.apache) at all since it is
> already used by the real commons-lang.
commons.lang was an example. it could have been anything. a maths
library, a geometry library that does spatial stuff, regex anything...
there are large amount of assets and investment in assets already out
there unchanged with source code. then a savy gwt engineer comes along
and writes a module descriptor and leverages those assets in their appl
without change.
the point is that i dont think the gwt community needs to continue
living under the delusion that 'client' needs to be in the namespace in
order to use some library that they have been using in their other
non-gwt apps in the past.
> It makes it easy to mentally separate what it used on the client and what is used on the server.
did u do or need the same mental separation under mvc model1 & model 2
architectures?
did ur ole, com, dcom com+, corba, java stored procs, etc do the same
separation in the namespace.
for me the answer is no. 'client' is a gwt idiom.
rgds ash
http://www.gworks.com.au
mP
forum. i would say org.gwtcommons is noise.. it adds two packages where
only one is necessary at the project name level. If we can live with
that then we can surely live with client/server etc which actually
serve some purpose.
ash
> veteran GWT developers are left to muddle around trying to figure out
> what should and shouldn't be clinet side code.
reliance on a convention. certainly there are folks that are passionate
about inverting dependencies and ensuring that binaries are properly
composed prior to distribution. i would use tools (like the
gwt-compiler) to assert such things.
> This is a different issue entirely, and in fact since gwt-commons is
i beleive everything follows the laws of cause and effect. i assert
that the 'client' convention or demarking candidate gwt source is an
effect, caused by the gwtcompiler and gwt-jre.
> have seen instances in the past where developers have forked another
> project to implement some sort of compatibility, they prepend the
> original namespace with their own, In fact GWT does this with its
> java emulation library.
i realise this and am an advocate of it as long as it minimises
violations of:
- liskov substitution principle - require no more, deliver no less
this same technique is used in:
- java2script to emulate a JRE and SWT
- swingwt to emulate swing
- SWTSwing to emulate swt
non of the above oss projects are folks as such. they are solutions for
solving the following motivation:
"minimise duplication/reinvention, maximise leverage"
> That is my point entirely. It creates a markable separation between
> client and server code, and is necessary to maintain consistency with
> GWT itself.
yes, consistency is the _real_ issue. consistency may also help to
perpetuate a delusion.
> The GWT Team will never be able to completely implement the entire
> JRE so there will always be limitations on what can be used on the
probably true, but not due to technical issues, moreso lack of
motivation.
josson smith and arno puder found ways.
> The goal here is to have a package that is as much like GWT as
> possible. We shouldn't depart from their conventions just because we
there u go. these were the things i was trying to solicit from the
start. here we have a principle. a principle that u value to the core,
yet it is not part of my currency.
> "don't like them". By doing so we just heap an unneeded burden onto
> the users.
both gemsv1 and gemsv2 (different designs entirely) used the approach u
describe. please dont think that it is foreign to me.
i have learnt many things from the gwt community. claude helped with
this particular one. ive come to conclude that it is not too different
from other coding conventions or road signs that we use in code. hence,
ive lost the attachment!
like coding conventions/style im not too concerned about what the team
nominates in the end. i personally get greater reward from challenging
your views and helping people release their attachments.
best wishes ash
http://www.gworks.com.ai
Joe Toth
org.gwtcommons is noise, but its the Java standard, so might as well stick with it. You'll have gwtcommons anyway, why not stick org in front and go with the standard. I don't have any compelling opinion either way.
I like *.client because you know right away that those files will be translated to javascript and have to abide by the GWT compiler rules...unless you have 2 separate (maven) modules. Then I think that is sufficient for separation.